There are the ‘usual suspects’ in Scrum that every team quickly picks up on. The four ceremonies, of course. Artifacts, too: a Product Backlog, a Sprint Backlog. So, now are we Scrumming? Sure, a little. It’s okay as a start. But without capacity planning… you’re seriously missing a point.
Capacity planning, to be clear, is where each team member looks ahead into the coming Sprint and indicates how much space they’ll actually have to work on stuff for this team. It’s supposed to be part of Sprint Planning but… I’m surprised to see how little it’s actually applied. Even though each professional is only in a given team for a percentage of their time, and as such must juggle responsibilities. Full-time, dedicated Scrum teams are increasingly rare these days, especially in organizations of scale.
A team without capacity planning just selects items from the product backlog until the Product Owner feels it’s something they can present to management. Then the team puts its faith in whichever deity they worship to finish the work on time, or rather… prepares to disappoint.
Why do teams choose to over-commit-and-disappoint rather than to commit and satisfy? One cause: because capacity planning forces team members to be concrete about commitment. Another cause: because capacity planning forces everyone to make real decisions about priority.
Non-committal feels safer?
It feels safer to give neither a firm no nor a confident yes, but rather a non-committal ‘I hope we’ll manage’. But that anti-pattern does stand in the way of real predictability. I’d rather see a team under-commit the first two Sprints, to get a feel for how much strength they might actually draw from capacity planning, and then challenge them to increase their commitment based on confidence rather than peer pressure.
Scrum Masters! Help your teams get comfortable with capacity planning. Challenge the team to show their colours and attach a number to those two or three weeks ahead. After all, what’s the use of planning poker if you don’t load those story points into your capacity? Wait – you are still playing planning poker, aren’t you…?
The game of capacity and load is an essential element in Scrum: the place where Scrum takes Lean process improvement and merges it with Agile product delivery. Getting into it may feel uncomfortably vulnerable, at first, but it is very much worth pursuing that openness and commitment in your team.
And if your co-workers are complaining that stakeholders keep stacking work onto the team… use capacity and load to toughen up your product owner. What they need to say no to some things, is first for you to say yes to others. Not ‘Maybe.’
How are your teams faring in their planning habits? Using Poker? Establishing capacity? Or…?
Boris de Jong is a trainer of SAFe and Scrum and a content specialist at Gladwell Academy.
With a background in the political sciences, in journalism and in theatre, he works to make the abstract aspects of the Agile way of working and the transformation process more tangible and relatable.