Scrum Commitment-Based Sprint Planning
So your team has their backlog of User Stories groomed, they meet the team’s Definition of Ready, they are in a prioritized order, and they are sized via Planning Poker, Triangulation, Blink Estimates, or White Elephant, take your pick (more info on those sizing methods at the end of this post…),
And they are about to dive into planning the next iteration. How much work can the team commit to with confidence?
Capacity Based Commitment
While a team’s historical Story Point velocity allows for a sanity check (as well as a forecast of how long parts of the backlog will likely take to deliver,) I recommend that shu-level teams approach their sprint planning using capacity-based commitment – which requires estimating hours of effort.
Here’s how it works:
- The team determines their total plannable hours for the iteration (See: What’s Our Capacity, Really?)
- They pull the highest priority item from the top of their backlog
- Team determines the major tasks, the big to-do’s to complete that story – We target detailing ~2/3 worth of “all the tasks to get to done.“ Why 2/3 and not 100%? Muda. We have found that writing up 2/3 will account for at least 80% of the dev time for the story. Spending more time is typically wasteful – teams create subtasks that end up not being needed as they worked thru the “Big stuff” first, and remaining “little things” can be sub-tasked out “just in time” during the sprint. (BTW, we are digging the Create Multiple Sub-Tasks add-in for JIRA).
- Team estimates the effort in hours to complete those tasks. Some amount of discussion is necessary and appropriate. However, spending too much time is often wasted effort. The point is not absolute precision but reasonableness.
- Deduct the total task-effort hours from the bucket of plannable hours.
- Rinse and repeat steps 2 thru 5 until the total is at or just below the team’s capacity. (If they’ve been having trouble hitting their commitments, more than “just below” :))
Estimating the Known and the Unknown
If the team has recently completed similar tasks, estimating durations in hours in step 4 will be very straightforward. That’s a big “IF” – and alas, the reality is rarely ever so neat and tidy.
More often the tasks involve doing something the team has never done before. How then to predict the amount of effort involved to get a story to Done?
Accuracy? Precision? Guaranty?
First: know that all estimates are a guess. No promises or guarantees are expressed or implied. It is a prediction based on what is know at a given time. Precision must not be assumed nor expected where it cannot exist. And missing an estimate is not in any way dishonorable or a violation of the “Clean Coder Code of Conduct.” As professionals, we simply strive to continually improve our estimation abilities. Estimates are just that:
Scrum Estimating and the Magic of Pi
When estimating “new territory” – My teams have found π to be both important and magic…
π : Unknown Task, Known Team
When estimating a new task with lots of unknowns, and the work will be completed by an established team: multiply effort-hours by π.
Why? Simple, engineers are optimistic and often think that it’s a straight line from “here” to Done. In reality, most of the time they’ll go all the way around the circle once… and as you know the circumference of circle = π * D.
π^2 : Unknown Task, New Team
When estimating a new task, with lots of uncertainty, and working with a relatively new team – multiply by π^2.
Why? We aren’t going to take the diameter, and we probably won’t even be lucky enough to wander the circumference. (Just don’t try squaring the circle…:)
They’ll probably be off by π on how fast they’ll make progress, and off by π on how much work they’ll end up doing. Hence, π^2
What’s Our Capacity, Really?
Rounding Out our Pi Magic: √π
Teams see the √π come into play when they are estimating total plannable hours in a sprint. No one has 40 available dev-hours in a week. Time is used for sprint review, retro, and planning. There are code reviews for teammates, consultations with other teams, high-level discussions that ensure things are on the right course, and breaks to eat Chocolate Bacon Coffee Stout Cheesecake. In reality, the capacity planning bucket is much less than 40 hours per person per week.
How much less? Take 40 and divide it by √π – you get: 22.5 – or on average 4.5 hours of heads down time each day – (before you deduct vacations, training sessions, pager duty, etc.) Don’t believe in magic? Track your time over a sprint or two… Here’s a short list of time tracking tools to consider:
The One-Two Combination
While capacity-based sprint commitment may be new to teams used to velocity-based planning, in my experience, the combination of the two, along with the application of the magic of π allows teams to press the “start sprint” button with a high level of confidence.
What are your teams doing? Is π the right factor? I’d like to hear from you….
