28
What Value Sprint Capacity?
How do you measure Sprint Capacity?
In Days?
In Points?
In Hours?
By Function?
Do you differentiate by contractor vs employee?
Do you take into account bathroom breaks and meetings or is that including in the calculation?
A long list of questions, and despite using Sprint Capacities for the better part of 5+ years I've always come to find them an imperfect science that doesn't achieve what project planners and managers are hoping to achieve - a near perfect allocation of time applied to a sprint within a large project.
"I don't pay for your bathroom breaks"
I actually had someone say this to me on a project, when I suggested a capacity per developer of 6 hours a day to account for things like going to the bathroom, having lunch and anything else that pops up during the day.
I was flabbergasted when I heard the response and immediately felt sad for the larger team who had worked this way for years. I kindly responded that I would not be coding in the bathroom but remember this as being the first issue I've seen with the usages of Sprint Capacity.
If we are accounting for these "bio-breaks" - we are down to 6 hours a day of capacity.
Invariably I get asked this question by developers when providing their estimates. If the developers are involved in validating User Stories and filling in the blanks on requirements, chances are they aren't coding all the time. Such is life and if this increases the value of the project, keeps it humming and everyone is on board, then I'm game. But including meetings into estimates? That's one piece I try to stay away from and contributes to the previous discussion as to what is a person's actual capacity on a daily basis. If they are in 2 hours of meetings a day (and we try to cap that), then that leaves them 4 hours of coding a day.
The cap here is important, because it's easy for the developer who is great at disseminating requirements into code getting sucked into more and more meetings and leaving them with only 30 minutes of coding time a day.
Forget about your productivity, it's not enjoyable.
Also, I'm not big on creating custom task types that equate to "attended meeting". Attending meetings should always be productive (another topic) but they are not something we need to record. We have other apps for that.
Points are great for team capacity (i.e., how many user stories can we complete in a sprint). This can also help with optimal allocation of resources (i.e., a complex story might have tasks broken out between two developers based on complexity). However, the problem I find with using points as an allocation of complexity is that it requires someone to focus on the allocation of points and challenging them for their completeness and consistency across user stories (i.e., is a 3 really a 3 or should it be a 1 or a 5? Not accounting for developer skill level in estimation).
In all the above aforementioned issues, here is generally how I apply capacity across 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 then 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).
What do you do for sprint capacity? What do you find works best and was most easily to get your team onboarded to?
I wrote a book about being a Developer and Leading Software Teams - Code Your Way Up - available as an eBook or Paperback on Amazon (CAN and US). Follow me on Twitter @CodeYourWayUp.
28