Confirmed users
820
edits
Gaia/SMS/Scrum/2: Difference between revisions
Jump to navigation
Jump to search
→Retrospective
| Line 499: | Line 499: | ||
== Retrospective == | == Retrospective == | ||
===Review of Previous sprint's actions=== | |||
* we need to know when the blocker phases end (especially when will 1.3t+ end?). +1 | |||
** still not this | |||
* have a centralized place for all uptodate visual design material | |||
** should be ok for future features | |||
* daily meeting: use etherpad as a more synthetic way to update the bug status, and keep IRC as discussion backchannel(+1) | |||
** was done and seems to work fine | |||
===What was good in the last sprint=== | |||
* landed a bunch of VR patches +1, we finished the "big things" | |||
* using etherpad as daily (was it good for you too?) | |||
** (Oleg) I like it! | |||
** (Steve) +1 It make IRC cleaner with pure discussion and easier to update on wiki | |||
* (Oleg) I really liked to have f2f conversation with Steve, Vicky (it eliminates a lot of ni?), Jenny and guys that works on Messaging DB | |||
===What was bad in the last sprint=== | |||
* did not complete the sprint; burndown: https://wiki.mozilla.org/Gaia/SMS/Scrum/2#Remaining_points_and_burndown_chart | |||
* a lot of reviews coming from external sources: it's counted in the "efficiency" but this time there was a lot. Should we count the bug we know in the sprint? | |||
* both bugs that was started externally (message bubble VR and subject handling) took more time than expected, to continue it correctly I needed to do almost the same amount of work as it required in the beginning (verify that all requirements are met in the initial patch version and etc.). Ideally guys who started work should be presented at sprint planning (wasn't possible in case of Joan, but Pavel can probably join in the future) | |||
* Maybe we should assign the tasks divide by higher level instead of bugs. There are too many people developed on same or related stuff but blocked by each other +1 | |||
** (julien) yeah this happened a lot during this sprint | |||
** (julien) IMO we at least need to better identify dependencies +1 | |||
* we started working in the bigger bugs only on the second week | |||
* workweek: how did it work for you? | |||
** (Oleg) I really liked to have f2f conversation with Steve, Vicky (it eliminates a lot of ni?), Jenny and guys that works on Messaging DB | |||
** (Steve) It was good for detail discussion, but hurts the productivity... I can't focus on something more than 1 hr :p | |||
** (Steve) WW for the beginning of the cycle would be better, we could have clear goal that what we should do and discussion with visual and UX before developer kick off.(And less pressure on solving bugs) | |||
** (Julien) We see this well on the burndown | |||
** (Julien) so next workweek, we reduce the velocity? Yes, a lot of meetings interrupts, travelling and jet lag also affect performance. | |||
** (Oleg) WW needs more detailed agenda (but it's more about WW itself rather than SMS team), so you can understand what is going to be discussed | |||
** (Julien) instead of having meetings planned today for tomorrow ? Or you mean, know better what will be in one meeting (so, agenda for a meeting, or agenda for the WW ?) | |||
** (Oleg) both, no ad-hoc meetings and more clear agenda (instead of just "DataStore discussion" as every team thinks about different things(Contacts, SMS)) | |||
* another general question: why do we always rush at the end? If we'd say (internally) that our deadline is 1 or 2 weeks before the real deadline, would that work? | |||
** You mean braching ? | |||
** not branching, but have as a goal that every feature needs to be done the sprint before... so that the last sprint is more about details. My thoughts here is that we always rush to finish, but we also always finish, so maybe we go to slowly at the start ? Or maybe it's just because of previous version's blockers and we can't do better ? | |||
** This time with Haida we're less dependent on other people so maybe we can do better. | |||
** Hope so, but we still have some VR stuff for 2.1. The good news is seems we didn't have | |||
many other feature for 2.1, the bad news is we can't confirm that(especially from partner) | |||
** for some partners, Haida is very important, so let's focus on this for next version :) | |||
* not a lot of contributors these days | |||
** (Julien) I have one contributor that sent a comment today \o/ and Gabriele mentors someone on the SMS app too | |||
===Any questions=== | |||
Nothing this time. | |||
===Actions=== | |||
* Reduce velocity during workweeks | |||
* invite all people that work on SMS to daily meetings (this time, we were missing Pavel, Marina) | |||
* better identify that bugs will target the same area (eg: composer bugs); ideally we need to span them on several sprints, so we need to identify well in advance | |||
** note: started with haida: https://etherpad.mozilla.org/sms-haida :) | |||
* workweeks: | |||
** should be at the beginning of the cycle | |||
** more detailed agenda: meetings planned well ahead, better agenda for each meeting | |||
===Grades=== | |||
5 is very good, 1 is very bad. | |||
====Product Performance==== | |||
(Oleg) pp= 3 | |||
(Steve) pp= 3 | |||
(Julien) pp= 2 | |||
We use pp=3 | |||
====Product Quality==== | |||
(Oleg) pq=3 | |||
(Steve) pq= 3 | |||
(Julien) pq= 3 | |||
We use pq=3. | |||
====Commited tasks vs Completed tasks ==== | |||
(Oleg) t= 4 | |||
(Steve) t= 3 | |||
(Julien) t= 2 | |||
We use t=3. | |||
====Code Quality (inverse of Technical Debt)==== | |||
(Oleg) cq= 3 | |||
(Steve) cq= 3 | |||
(Julien) cq= 3 | |||
We use cq=3. | |||
====External contribution from community==== | |||
(Oleg) ec= 0 | |||
(Steve) ec= 0 | |||
(Julien) ec= 1 | |||
We use ec=0. | |||