How do you calculate how much work to take into a Sprint? While not a part of the official Scrum Guide, Sprint Capacity Planning is a great way to establish how much work the Development Team can do. Here’s how it works.

Sprint Planning – What the Scrum Guide says

The Scrum Guide is a framework for complex product development and while it provides clear detail on its roles, events and artifacts, it deliberately leaves it to the individual to decide how to approach certain requirements. Sprint Planning is a prime example of this.

The Scrum Guide says that, for a Sprint Planning session, you should have knowledge of the Development Team’s capacity and knowledge of their past performance but doesn’t say much more than that. Here’s how I approach the requirement.

My Flavour of Sprint Planning

For every Sprint Planning session, the Product Owner comes armed with the latest, ordered, version of the Product Backlog. They use the Development Team’s current velocity (if known) to gauge, roughly, how many Story Points the team can complete within the next Sprint.

The Product Owner then presents the highest ranked User Stories for the Development Team to consider and, potentially, take in to the Sprint. This continues until the Development Team says that they have enough work for the Sprint. For some teams, this is enough planning. They’ll then proceed to work on the Sprint. For me, I like to get a bit more detailed.

The Availability Table

I like to go to my Sprint Planning sessions armed with an A3 sheet divided into squares that I call the Availability Table. It’s a simple table that lists team members down the left hand side and sprint days along the upper edge. At the start of every session, I ask the Team to place a Sticky note on any day that they’re out of the office.

It takes about two minutes to do this and the completed version can be stuck on the wall and act as a constant reminder of the teams whereabouts during a sprint. It also acts as the perfect start point for calculating the team’s capacity, too.

Calculating Sprint Capacity

The Development Team estimate their tasks in pure hours and so we calculate capacity in hours too. First, we add up all the days that Developers are available. We then multiply that by the number of pure hours in a day (this will differ by team). Finally we multiply that number by 90%. The resulting figure is our Sprint Capacity expressed in hours.

nb: There’s no hard science or mathematics behind this calculation. It’s a calculation that I, and a number of my colleagues, have used repeatedly for some time and it just works. Your mileage may vary but take advantage of Scrums ‘Inspect and Adapt’ cycle to refine it, should you need to do so.

Using Sprint Capacity

For each User Story under consideration for the Sprint, the Development Team break the story down into tasks. As a simple guide, tasks should be broken down until they are no larger than two days worth of work and no smaller than one hour’s worth of work. Don’t forget testing effort required!

Once all the tasks for a story have been identified, take the total figure away from the remaining team capacity. Repeat until you have enough stories for the Sprint.

You may be surprised to find that, at the end of this exercise, the stories you pull in to the next sprint are no different than those you would have pulled in using just the velocity calculation earlier. But don’t be surprised, it happens quite often, especially with mature Sprint teams. So what’s the benefit of the more detailed calculation?

Calculating task capacity in hours means that the Development team carefully think through all of the work they need to actually do. It encourages good analysis and prepares the team well for the upcoming Sprint.

Additionally, the level of detail helps reinforce the belief that the team will be able to deliver. This increases confidence and acts as a morale booster. As any good General will tell you, morale is a force multiplier. A Scrum team with high morale is a happy and efficient Scrum team.