Current Velocity: 8
Current Sprint: #3
Current Sprint: Sprint #4
SMS issues handled by the SMS subteam (blocks the sprint bug 1028276)
7 Total; 7 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Remaining points and burndown chart
google chart api url for Sprint 4
| Remaining points | |
|---|---|
| Start | 7 |
| Day 2 | 7 |
| Day 3 | 6 |
| Day 4 | 6 |
| Day 5 | 3 |
| Day 6 | 2 |
| Day 7 | 2 |
| Day 8 | 0 |
| Day 9 | 0 |
| Day 10 | 0 |
| End | 0 |
Previous sprints
Rules
Sprint Planning
Input: we have a list of bugs to use, with a rough priority. Here is a list of queries:
blockers
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
nominations
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Features
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
"SMS most wanted" 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.
Estimation
- 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 irc.mozilla.org/#gaia-messaging 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.
Demo
Every sprint must end by a demo of what happened during the sprint.
Retrospective
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 invididual 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 (choosen by the team) will need to be done in the next sprint.