Let’s focus on activities that APPEAR to be really important, but are really just hold overs from old-style management techniques that assume software development is actually a defined process as opposed to an empirical one. In a previous post, I focused on the time wasted in release planning. This blog post will focus on my next target: trying to plan detailed capacity for a a Sprint.

Let me lay the ground work here. Our team, we’ll call them Team Hourly, gets together to do Sprint Planning. As many ScrumMasters do, Team Hourly’s ScrumMaster starts the planning meeting by determining the team’s capacity for the next Sprint. The idea is that the team’s capacity can be compared to the team’s previous capacity in order for the team to decide how much work they are willing to commit to in the upcoming Sprint. If the team has less capacity THIS sprint than in the PREVIOUS sprint, they should commit to less than they accomplished in the previous sprint. If they have more capacity in THIS sprint than in the PREVIOUS sprint, they should commit to a little more than the previous sprint accomplished. While this is, arguably, a worthwhile practice (more on this later), our team has, unfortunately, learned a poor example of how to do this. It sounds something like this:

SCRUM MASTER: “Sally, how many hours do you have available in the current Sprint?”

SALLY: “About 20 hours per week, so figure 60 hours for a three week Sprint.”

SCRUM MASTER: “How about you, John?”

JOHN: “75 hours.”

SCRUM MASTER: “OK. Mark?”

MARK: “40 hours.”

This continues as the ScrumMaster circuits through the entire team, adding up hours as he goes. After polling the entire team, he then adds all the hours together and informs the team that they have 600 hours available for the entire Sprint. This is more than the previous Sprint by 50 hours or about 8%. The team then decides to commit to a little more work than the previous Sprint. Here’s the problem with this scenario — what if John isn’t as available as he says? What if he’s more available? What if a number of tasks in the Sprint Backlog are poorly estimated (it happens, right?) or tasks are missed? What if Mark can do the same kind of tasks that Sally can do, but he takes twice as long because he’s new? We could go on and on with these questions, pointing out the obvious — that even though we can plan down to the hour, IT’S REALLY ONLY AN ILLUSION OF PRECISION. The result looks nice, but we have to make too many assumptions about tasks and team member availability for the hour-based capacity to be of any real use. Thankfully, there are two things we can do to make capacity planning easier (and faster) in Sprint Planning.

Option 1: DON’T USE HOURS – using hours looks nice, but it really doesn’t help. So, an alternative is to simply add up days. In other words, ask, “How many days do you have for this Sprint?” You can even reverse the concept and ask the team how many days will they NOT be available and compare the unavailability to the previous Sprint instead. This option is faster because we aren’t asking people to add up hours and it’s less granular, leaving more room for the unexpected to occur during the Sprint (and it WILL occur). But, there’s an even better option:

Option 2: STOP DOING CAPACITY PLANNING – ask yourself…what’s the worst thing that will happen if the team over-commits? What’s the worst thing that can happen if the team under commits? The world isn’t going to end and, believe it or not, your project schedule will continue mostly unaffected by the team’s changed commitment (unless, of course, your project schedule was unrealistic in the first place, in which case you’ve got a big problem regardless what the team gets done). Here’s what you do instead….commit to what the team got done during the previous Sprint. That’s it. Simple. If the team got 25 story points done in the previous Sprint, commit to 25 again. If they can get more done during the Sprint, they’ll load more during the Sprint and commit to more during the next Sprint. If they can’t get as much done this Sprint as during the previous, they’ll return some work to the Product Backlog and get done what is do-able. And, while they’re doing it, they’ll spend less time trying to come up with numbers and commitments and spend more time actually getting work done.