Improving Sprint Predictability

Software delivery teams often struggle to achieve their sprint goals and ensure predictability consistently. There is no secret formula to overcome this, and eventually, most teams figure out their way over time by experimenting with various approaches. However, some teams are better at doing this than others.

There are a few common approaches that can be useful for most teams to have a great start in improving sprint predictability.

Spikes. This is about isolating uncertainty from work items. For example, if the completion of a work item requires determining the technical approach first, then isolating that part as a separate work item helps to determine the effort required for the actual implementation work item more accurately. Such research work items are commonly referred to as spikes. Also, it’s better to work on the spikes in earlier sprints and then work on the dependent work items in later sprints. If both spikes and dependent work items are in the same sprint, it’s highly unlikely that the team would be able to complete the dependent work items as the volume of work might have changed based on the outcome of the spikes.

Swarming or pairing. Swarming or paring is another approach where instead of each team member stating separate work items, they work in pairs or in small groups to finish one or a few work items first and then move to the next work items. This approach helps in maximising the chance of completing goals. Not all types of work items are suitable for this so the team need to make the right judgement for this.

Swapping work items. Many delivery teams work both on delivering new features as well as supporting the live production system. In this case, it’s not uncommon to get urgent work items to fix production issues. As such work items were not planned during sprint planning, the best approach is to swap out with another work item to accommodate the urgent one.

Removing work items. Finally, another approach to have a better sprint outcome is to remove work items related to one or more sprint goals. Often things might take longer than expected to complete, and a team might discover that there is no way they are going to achieve all the sprint goals. In such a scenario, instead of working on all goals, the team would focus on achieving fewer goals. For example, it’s better to achieve four out of five goals than achieve one or none.

Solid technical practices. Having continuous integration and deployment practices with automated build, tests, and deployment to the development/QA environment is a must to ensure predictability by avoiding any waste during a sprint. This enables the team to get fast feedback and identify any breaking changes as soon as they occur.

Better planning. Based on learning and experience, a delivery team can adapt their sprint planning approaches to improve predictability. Some examples include: planning for fewer goals, not planning for the whole team’s capacity, reserving some capacity for unpredictable work items, working on risky and uncertain work items in earlier sprints etc.

The approaches mentioned above are not the only ways to achieve predictable outcomes from a sprint. Every software delivery team has their unique context, and through regular retrospectives and experimentation, a team can discover its unique approaches to improve sprint predictability.