Introduction
One cornerstone of scrum is the team sprint commitment. A team must make their sprint commitment in order for the business to have faith in the team and agile process, to allow predictability of dates, and for a team truly to perform as a team vs. a set of individuals.
I want to explore some of the reasons why teams don’t make their commitments and what the teams can do to avoid missing their commitments in each case.
Taking Team Sprint Commitment Seriously
Teams new to scrum sometimes do not understand the seriousness of the sprint commitment. They sometimes view a sprint commitment as a goal or plan which it is absolutely not.
- A plan is something we intend to do based on current information
- A goal is something we aspire to do
- A commitment is something we will do
When a team makes commitment they are saying no matter what happens (a team member gets sick, a story is larger than was estimated, etc.) …
the team will do whatever it takes (work nights and/or weekends, find alternate solutions that reduce dev and test time, have team members do activities they are not as familiar with like testing scripts) …
in order to meet the stories with the scope agreed upon when the sprint commitment was made.
A team should only to commit to those stories they are willing to do whatever it takes to meet. It should never be a thought of as a goal, it should be what they will do. The team can always add additional stories after meeting their commitment if they still have time in a sprint.
No one other than the team can make the sprint commitment, and all team members are accountable to make sure all aspects of the commitment are completed to the company’s best practices and standards. If any one story or task is not done to that quality, it is a poor reflection on the entire team.
Recommendation: Say What You Will Do, and Do It
Teams Taking on Additional Stories Before The Committed Stories are Done
Teams will sometimes fall into the trap of starting additional stories beyond the team commitment before the committed stories are fully complete (done-done). They then find that they don’t have the time to finish an aspect of committed stories (often testing) because they spent their time elsewhere.
Teams should always ensure that they can make a sprint commitment before adding any additional stories and it should be a team decision to add another story not a single team member decision.
In the rare occasion, that a product owner feels compelled to break (terminate/cancel) a sprint by asking the team to work on additional scope before the team commitment is completed in a sprint, then the commitment is also broken and has to be recommitted based on the change of scope.
Recommendation: Don’t add to sprint until team is positive sprint commitment will be met.
Teams Not Factoring in Enough Time For Testing
Teams sometimes get caught up in the how they will develop solutions for the stories in the sprint and don’t focus enough on how they will validate their solutions met the need. The development of the stories may be done, the testing has not been sufficient to meet the done-done criteria.
Recommendation: Work on a test plan at the beginning of sprint. Only take on stories if you know you can get to done-done criteria on all of them.
Teams Making Assumptions
Unfortunately there are times where the team does not flush out stories completely to discover the entire scope. Sometimes the Product Owner or the developers make assumptions that stories include scope that is not explicitly spelled out. Common areas where this can occur are assumptions around logging, reporting, and regulatory compliance. Be sure to explore these areas during story creation and make sure to document explicitly any assumptions that are revealed during discussion.
Recommendation: Don’t make assumptions, ask for clarification.
Teams Reliance on External Resources
There are times when a team does not have control of all the resources they will depend on for completing their sprint commitment. Some examples:
- They are relying on a design element from an external design team or a Database Architect to be available to review some schema changes required in the sprint.
- They are relying on a common continuous integration platform or release management for integration and deployment.
Ideally the team would get commitment from the external personnel to dates that ensure they will have their part ready for when the team needs it. While the team should try to push for this as much as possible there will be times where that isn’t practical. The team then has to factor in the risk when making their commitment … for example assuming that some of the external resources may be late so leaving some extra room at end of sprint to accommodate.
If teams are depending on a technology solution (ex. continuous integration platform) that is causing the team to sometime miss sprint commitments, then the team should consider working with their Product Owner to dedicate some time to fixing it. (Sharpen the saw instead of continuing to cut with a dull blade.)
Recommendation: Reduce Dependence on External Resources where possible. Where not, factor in the risk when making a sprint commitment.
Teams not Self Policing
When not every member of the team is performing at the same high level it can be a large hit to morale both for the individual not performing and the team as a whole. Teams need to recognize they stand or fall as a team. While a team member’s manager may have insights into individuals performance inside the team, the rest of the organization will only be looking at the team’s overall contribution.
Teams need to do what it takes to help all team members be effective. Team members need to be willing to ask each other how they can help them be more effective. They need to honestly communicate with their manager when they feel a team member needs some help or guidance or when a team member is not a correct fit for the team.
Recommendation: Be willing to address performance issues within team.
Conclusion
One of the most painful things to see is a team consistently missing their sprint commitment. Morale of the team becomes low and the business owners faith in the team diminishes. If a team does miss a commitment the important thing is to learn from that experience and apply that knowledge when making the next sprint commitment so it will be met.