From MozillaWiki
< Gaia‎ | SMS
Jump to: navigation, search

Current Velocity: 4

Current Sprint: FxOS-S9

Current Milestone: Gaia/SMS/Scrum/Milestone_Planning/2

Milestone 2 lasts until mid of July.

Previous milestones

Current Sprint: Sprint FxOS-S9

SMS issues handled by the SMS subteam (blocks the sprint bug 1212336)

Bugzilla link

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
1192263 Steve Chung [:steveck] [Messages] We load Inbox before going to the notification conversation when app is run via notification click. 2.5+ No cf_feature-b2g [p=2] FIXED
1197231 Increase in SMS app memory consumption --- No cf_feature-b2g [p=2] WONTFIX
1206727 Julien Wajsberg [:julienw] (PTO -> Jul 24) [Messages][Inbox] Don't reload the conversation node after saving draft --- No cf_feature-b2g [sms-papercuts][p=1] FIXED
1211395 Steve Chung [:steveck] Performance regression in Message 2.5+ No cf_feature-b2g [p=2] FIXED

4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Remaining points and burndown chart

google chart api url for Sprint FxOS-S9

Burndown chart
Remaining points
Start 7
Day 2 7
Day 3 7
Day 4 7
Day 5 7
Day 6 7
Day 7 7
Day 8 7
Day 9
Day 10

Previous sprints


Sprint Planning

Input: we have a list of bugs to use, with a rough priority. Here is a list of queries:


No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

SMS most wanted and papercuts list

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Priority list

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Priority order

Currently, rough priority order is: 1.3+, 1.3t+, 1.4+, Features, 2.0+. We can have a look to the nominations (1.4?, etc) too.

Between 50 and 70% (depending on the moment in the release cycle) of the velocity will be used for these bugs. The rest of the velocity is to be kept for blockers appearing during the sprint.

We take the list of bugs in the order of priority, and estimate them together (see Estimation below). We can also take some technical debt bugs (at least 1 per sprint would be nice), identified by [sms-most-wanted] in the whiteboard

When we reach the available velocity, we stop.

All the taken bugs are blocking a meta bug representing the current sprint.


  • we estimate relatively to other bugs.
  • we can estimate using 1, 2, 3, 5.
  • We never estimate with less than 1
  • bugs that needs more than 5 needs to be made "meta" and we need to file smaller individual bugs. This will need to be done during the planning so it's better if someone can do it ahead of time.
  • Only the developers that feel they can estimate do the estimation. That means it's perfectly fine to not take part to a bug's estimation if you don't feel you can.

Daily Meeting

It happens on IRC and etherpad every weekday at 08:45 GMT. Minutes will be archived in the Sprint page.

Each attendee adds the following information to the etherpad:

  • what he did since the last daily meeting
  • what he'll do until the next daily meeting
  • is he blocked on something

Then he writes "updated the XXXX" on top of its part, to make it clear he finished updating its current status.

Other attendees can comment directly in the etherpad, by specifying the first name in front of their comment.

This is not the place where we unblock things. But this is the place where we know there are things to unblock, and so a follow-up will need to happen.

Then unless somebody has something else to add, the meeting ends.

Comms Daily Meeting

Every developer of the team will attend this daily meeting but only one will speak. He will summarize what happened on our team (including our blockers) to report to other teams.

The developer that speaks can be different at different occurrences. For example, it can be the first one that's asked to speak.


Every sprint must end by a demo of what happened during the sprint.


This is the place where we change rules.

Everybody must think ahead of time to what was good and bad during last sprint. Could be anything, even if it's more an individual thought. You need also to think of any question you have.

During the meeting, everybody dumps this on etherpad, and then we take some time to review them. Ideally, all bad things and questions end up to actions to improve things, and the 3 most important actions (chosen by the team) will need to be done in the next sprint.