A fundamental scrum team practice is committing to the prioritized work at the start of the sprint and then fully completing it at its conclusion. Strong agile teams complete or exceed their sprint commitments and deliver working software at the end of the sprint. They also measure their velocity and discuss process improvements at retrospective meetings to improve quality, productivity, and other metrics.
But meeting sprint commitments isn’t trivial, and many obstacles can stymie teams. For example:
- Newly formed teams or teams with new members must figure out work styles, collaboration methods, and skill proficiencies. These teams often have unpredictable velocities until they establish a working rhythm.
- Teams working with new technologies may not know how to break down stories and estimate them accurately. Similarly, teams working with knowledge gaps around legacy technologies, the code base, or build and deploy processes may also struggle with their estimations.
- Teams working with challenging product owners and business cultures feel pressure to commit beyond their capabilities.
- At times teams may not fully know their own constraints. There may be holidays, corporate meetings, or other personal priorities that pull people off task.
- If production systems are relatively stable, then agile teams can usually estimate how much of their time gets pulled from development activities to support production incidents. But these are just estimates, and in some situations, agile teams must dedicate significant time to help resolve production issues or investigate root causes.
My experience working with agile teams is that at any given time, they are often dealing with some of these issues. Even when teams are making their commitments and increasing velocity, new demands arise. But some tools and practices help manage unknowns, risks, and external events that challenge teams hitting commitments.
Here are five practices that scrum teams utilize to improve achieving their sprint commitments.
1. Improve team collaboration during scrum meetings
There are a few standard scrum meetings designed to help teams review priorities, make commitments, track work in progress, review results, and discuss process improvements. At each meeting, teams should have different discussions concerning their commitments.
At the sprint planning meeting, agile teams review the intent of user stories and acceptance criteria and finalize story point sizes. Agile teams should avoid committing to stories that they don’t understand and should break complex stories into smaller ones.
During scrum standups, a chief responsibility of scrum masters is to remove impediments and blocks that delay story completion.
Finally, the teams should discuss their commitment successes, misses, and speed bumps during the sprint retrospective meeting. If the team missed its commitment and didn’t finish one or more stories, they should review what drove their commitment and in-sprint decisions and consider improvements for the next sprints.
2. Use spikes to address technical risks
Spikes are user stories designed to validate technical unknowns and risks. When a spike succeeds, the business value delivered is knowledge of how to design or deliver user stories prioritized by the product owner. Because spikes are for conducting research and are often timeboxed, they may fail to achieve the desired outcomes.
Advanced agile teams use spikes to research new technologies, test new technical implementations, or to validate technical assumptions around legacy areas of the code. If they are developing code that has hard, nonfunctional acceptance criteria for performance and reliability, then they may create spikes to implement and test designs. Agile teams can define an entire proof of concept as a series of spikes designed to build up their confidence in technologies and design patterns.
3. Split user stories into smaller, easier ones
When writing user stories, it’s more convenient for product owners or business analysts to draft them with the full capability required for delivering value to the customer or end-user. But agile teams reviewing this same story and breaking down its implementation often recognize that multiple capabilities need engineering to meet the story’s acceptance criteria.
Some teams, recognizing the complexity of a user story, will estimate a high number of story points. Other scrum teams will take a different approach. They will take longer stories and split them into smaller ones whenever small stories still meet the agile principle of delivering business value. This increases the likelihood of completing the smaller stories and gives the team options to split the work up across multiple sprints.
If the team can’t split the user story, then they should invest time to define a task breakdown. The breakdown helps scrum teams develop a shared understanding of the work required, enables them to assign tasks, and opens opportunities to do parts of the job concurrently.
4. Define shallow commitments instead of overpromising
I know many agile teams who feel pressure from their product owners to commit to more stories every sprint. Some agile teams feel they must negotiate their sprint commitments, while others pressure themselves to commit to more stories in the pursuit of increasing velocities, hitting release dates, or addressing technical debt.
There is another option. Some agile teams commit to the number of stories and story points they have high confidence of completing. They then leave several stories in the shallows that they will only take on if they complete the committed stories earlier than forecasted.
I have found this to be a proven tactic when working with demanding product owners because they walk away from the negotiation with at least a partial victory. Also, teams looking to increase their velocity can make shallow commitments without risk of missing their responsibilities on the higher-priority user stories.
5. Swarming to complete the highest priorities
At sprint start, most scrum teams review the committed stories, assign ownership, and delegate tasks to team members. Agile self-organizing teams find efficient ways to assign the work. Some formalize the assignments in tools such as Jira and Azure DevOps, and others use scrum standups to review them.
One natural, reasonable method is to divide and conquer. In this approach, multiple stories are assigned and started at the beginning of the sprint. It works well when user stories have similar priorities, are relatively small, and have few interdependencies.
Another technique for teams working on higher priority, more complex stories is swarming. Instead of splitting the team across multiple stories, the team swarms to complete the highest-priority story first before taking on others. Swarming can boost scrum team productivity and lower the risk of failing to complete the top sprint priorities.
Scrum teams should consider a mix of practices when planning, committing, and completing sprint commitments. Agile teams using these practices first build up their confidence around commitments, then increase their success rates meeting them. Only then do they seek opportunities to increase sprint velocity.