Agile Methods‎ > ‎Agile Discussions‎ > ‎

How do you ensure that a team commits for a sprint?

posted Oct 29, 2009, 10:13 AM by Marcel Baumann   [ updated Jan 30, 2010, 11:13 AM ]
The team is self organizing and tries hard to fulfill their commitments. Before each daily stand-up meeting at 11:00 AM the Scrum master updates the sprint burndown chart based on the completed stories. So the team has a daily feedback if they are on track or a discrepancy is emerging. If yes the product owner, also present at the daily stand-up, is immediately informed. Full transparency of progress is available to all interested persons.

At the end of each sprint the release burndown chart is updated to show the team if the common agreed milestones and releases are still achievable.

At the sprint retrospective the team inspects with the Scrum master the reasons why commitments were reached or not. Three situations exit. First the team has reached all his goals and no measures are needed, the Scrum master asks the team if he can help to improve velocity or if the team is already in flow. Second not all commitments were reached and impediments are identified. The Scrum master has to solve these identified and prioritized impediments in the next sprint with the support of higher management. Third and last commitments were missed but no clear impediments were identified. This means for us the team has over-committed. The Scrum master reflects with the team why this happened and also adapts the velocity of the team for the next sprints. If commitments are missed team members have to provide donuts beginning of next spring.

We were very pleased how fast the team was able to define achievable but still ambitious commitments. After around six sprints the team members committed goals and achieved them in the usual range of 95 to 105 %. The major drivers of the team are the velocity value of the last sprints and poker game for good estimates. To be honest each time the team changed their way of working, such as more sophisticated TDD practices, they needed at least two iterations to reach again the same quality of estimates.

The product owner is well aware of the situation and was always supportive as long as major releases were not in danger.

you can also find me under Scrum alliance profile