How to determine the capacity of story points for a Scrum sprint when velocity is unstable

The ‘sprint-backlog’ is those user stories a development team plans to commit to during a Scrum sprint. And if you are following the Scrum Guide it is up to the development team (and only the development team) to assess what capacity of work can be accomplished over the upcoming sprint.

Typically this means forecasting a set number of ‘story points’ that the team plan to deliver. But how exactly do you decide on a reasonable number of story points for a Scrum sprint?

In the past, I have worked on teams with a very stable delivery and deciding how many story points to bring into the next Scrum sprint was easy. However, I’m currently working with a fairly new team, on a fairly complex project, with a fairly large sprint-backlog where we are constantly building new functionality. Neither the complexity of the problems we are facing, nor our velocity, has stabilised (yet).

In this somewhat unpredictable environment we have implemented a simple process to determine sprint commitments that is working really well for us. Armed with metrics from the last sprints and team wide knowledge of the prioritised backlog, I facilitate a conversation culminating in the team voting on the sprint committal they are happy with. I like to call it democracy and it goes a little something like this:

The Scrum sprint commital process

Set-up a story point commital axis

Several days prior to sprint planning, I draw a numbered axis on our sprint board that covers a wide possible committal range of story point numbers (see image at top of this article). On this scale I add any relevant metrics from our previous sprints (noting any variance between what we committed to, and what we delivered). The context of the previous sprint’s delivery is important because it helps keep the discussion about story points from becoming too vague.

Team members vote

The discussion begins in a stand-up. Team members are asked to vote by adding an arrow and their initials to the board. I facilitate an ongoing discussion to uncover what is behind any variation and encourage everyone to take part. This isn’t a ‘one vote’ process - team members are encouraged to continue to review their vote right up until committal.

Establish the range of story points

The day before sprint planning, I lead a discussion to establish a ‘range’ that captures what everyone in the team are happy working to. Unsurprisingly, this spread appears to be reducing over time - during our most recent voting the variation was only 5 story points (for context - we delivered about 100 story points during the previous sprint).

Once we have a range, everything gets real. Our product owner gets very serious about which user stories are ‘safely’ included within sprint scope, and which could be ‘dropped’ if the team decides to go for the lowest point of the range (often this includes last minute re-prioritisation, some attempts at story splitting to reduce points expenditure and loud discussions about the way forward). Meanwhile the development team members can review the proposed scope to stress-test their comfort level with the commitment.

Committal during sprint planning meeting

The last stage of the process happens during our sprint planning meeting. For our team sprint, planning is essentially a meeting to ensure and facilitate alignment between the various stakeholders, business owners, project management and the development team. During the meeting we present the proposed sprint backlog (including possible cut-off points) and ensure that we are addressing the key business needs and risks (and since we are in constant communication with all the interested parties - we usually are!). We also ensure their comfort level with the proposed committal.

Once we have approval from the wider stakeholders to progress, the team moves into the detailed planning phase where the first thing on the agenda is finalising scope (we affectionately refer to this meeting as ‘Nerd-Planning’). This last stage is done by a round robin where the entire team nominates their personal choice for a cut point. In all honesty - this is a formality and by the time we come into the room, the team have coalesced around a number that everyone is comfortable with. As soon at that happens - any stories over the line are removed from the board and we focus on the who, what, when and how we will develop the solution. In other words - the gun has been fired and we are in sprint!

And there you have it - story point capacity selected by democracy.

Why does this work for determining story point capacity?

There are a number of reasons why I implemented this as a way to decide on committal scope, and numerous benefits from this process that I discovered after the fact. The most notable are:

1. The entire development team takes part in the conversation - this facilitates engagement and commitment to the sprint goal because it is their sprint goal that they have chosen. This enables the kind of self-organisation that empowers successful Scrum teams.
2. The inherent transparency of the process - there aren’t any hidden conversations between team leads culminating in a magic number without input from the team. Team members literally sign up to their committal vote and it is on the board for all to see.
3. The process reduces the impact of extreme views and encourages consensus - In fact, any extreme votes are typically challenged by the team and open (and oft-times very honest) discussions about individual team member’s contribution to team delivery frequently occur as a result. This results in:
4. A very real team engagement with the metrics - I have previously found that sizing metrics can end up being only really relevant to project management. On this team story points are a very real element of our user stories and this means that we have a useful, objective, and very real way to discuss delivery, cycle time, processes and team performance.

In sum – when it comes to story point capacity committal, trust your team to know what they can, and can’t do, and try giving them the opportunity to take control.

You may also be interested in my recent article Scrum Master - The difficulty of wearing two hats.

Hana Pearson-Coats is a Systems Analyst and Scrum Master based in Equinox IT's Wellington office.