How much wood would a wood chuck chuck if a wood chuck could chuck wood?
When planning work for an upcoming planning increment or sprint, capacity is your available bandwidth for the iteration measured in a well-understood standard unit. At Streamline we use three different units depending on the level of granularity of the requirement objects we’re planning. We touched on these units in the entry on estimation.
Practitioners of traditional project management sometimes think that agile processes are informal because they can’t get a formal estimate in hours for a months-long work plan. The PMP and the Agile Project Manager go around like this:
PMP: “How can this development team possibly know whether they can meet the client’s deadline if they don’t dig in and come up with a detailed estimate before starting?”
APM: “Have you ever seen an estimate stand unchanged throughout the duration of a project?”
PMP: “No, of course not. That’s what change management is for.”
APM: “So even if I were to commit my people to producing a detailed estimate now, you agree that it would be wrong?”
PMP: “Certainly not. I expect your people to provide an honest, accurate estimate!”
APM: “They always do, based on what they know today. Tomorrow they’ll realize they misunderstood the impact of some of the requirements. Or the requirements will change. If their initial estimate was based on high-level deliverables, we’ll still meet the deliverables while managing the details underneath.”
PMP: “I still don’t understand why you can’t just give me an estimate in hours…”
APM: “Fine. It’s eight thousand hours.”
PMP: “Thank you.”
The Agile PM knows that eight thousand hours is the typical capacity of her four scrum teams across four sprints, and the project in question has a deadline that’s five sprints out. She could have said “four sprints,” or “five hundred story points,” but the PMP only works in hours. Sometimes you’ve just got to speak your audience’s language.
Planning Increment Capacity
At Planning Increment (PI) Planning, we’re planning features, so we think of capacity in terms of sprints. A planning increment is four sprints long, and we have four scrum teams. So our PI capacity is sixteen sprints. We’re not yet ready to estimate the child stories of the features, and we haven’t even discovered all of them. At this level we estimate features in “ideal sprints” – how many sprints would this work take if it’s the only thing that one team worked on? A feature that’s estimated at four sprints will absorb all of the capacity of one team for the entire iteration.
Such single-treading is not likely to be acceptable – we always need to get some other items done too. We decompose features that are estimated at more than three sprints and push the lower priority functionality to the next planning increment. As often as not, those lower priority parts of the feature will end up being changed or dropped anyway.
Sprint Packaging Capacity
When planning sprint packages, the capacity currency is story points, and we base our assumption about each team’s capacity on their past performance as measured by their velocity. Velocity is the team’s average story point delivery over multiple sprints. When using it to plan capacity, it is imperative to consider any special circumstances for the coming sprint. Is anyone taking an extended vacation? Do we expect any contention for team members’ time – like a new client going live? (In a perfect world, client go-live would never impact the development organization, but our world is not perfect.)
While at PI Planning we’re thinking in terms of the average team, at sprint packaging we know which team we’re working with and we know their actual velocity, which might be below or above average. We’re also using the estimates on the user stories that they provided. Across our organization, sprint packages can vary by ten to fifteen points due mainly to the teams’ variance in their estimation scales. They aren’t supposed to vary, they’re all supposed to be using “Ideal Developer Day” story points. But the reality is that they do vary, and we very consciously never compare velocities across teams.
Sprint Planning Capacity
After sprint kickoff, each team digs in and plans their tasks for the sprint. Before they start decomposing and estimating, they spend a few minutes estimating their capacity. Microsoft Team Foundation Server (TFS) allows each team member to say how many days they’ll be unavailable (if any), and also to specify how many hours a day, on average, they’ll be devoting to the team. We assume six hours out of our eight hour day, allowing the rest of the time for non-team meetings, training, and admin tasks like timesheets and, you know, getting up and walking around. (Before you ask, lunch is not part of the eight hours.) If someone is a manager, or they have other responsibilities (for example, our architects are on both the architecture team and a scrum team, so their scrum team capacity is reduced), their hours per day will be less than six. TFS also knows how long the sprint is, so it calculates the team’s total capacity in hours for the sprint. Then the team estimates their planned tasks. If the planned tasks exceed the available hours – the sprint capacity – they go back to the product owner to renegotiate the package.
PMP: “Thanks for the demonstration. The client is thrilled. I’m amazed that you guys pulled it off without really knowing how much work it would take. I know you made up that estimate of eight thousand hours.”
APM: “Yes, well, sometimes you get lucky.”