As easy as it would be, Sprint Capacity isn’t all about numbers. The numbers are the foundation to build a capacity but they aren’t the entire story. If you’re being asked to determine your team’s capacity, there are a number of factors you should be considering.
Some factors I consider when looking at how I want to manage a sprint and what I think of when determining the capacity of the team;
- How many stories are allocated to each developer to each sprint and what are they in particular? I.e., a developer could have 3 – 4 user stories a sprint, but they might be pretty easy vs a developer working on a more complex issue who only has one.
- We pull stories back into the sprint. This is key, we all like to think we can get a lot more done than we actually do so getting people to start with the minimum and pull in is a big change. This ensures that we are always hitting for capacity (i.e., what we think we can do). If we get it all done, we move to bugs or pull in additional stories.
- Depending on other items that a developer has on their plate (i.e., projects outside of this sprint or excessive meetings, etc) we adjust based on what workload is on their plate. This can easily change sprint per sprint so I don’t find it useful categorically across the project.
- Historical – what is that developer actually completing? I feel this is a failure in a number of the apps we use. But all these systems, have the velocity and completion rate of a developer. Instead of asking for the capacity, fill in the blanks and look at what they have done in the past and calculate some kind of sliding average (IDEA – I think I’m going to need to try this out).
