Wondering how to improve your sprint planning? I have a game for you. The game has 5 levels. We’ll borrow them from CMMI. Your goal is to find out, what is the highest level you have reached in real life with your scrum planning.
Level 1 – Initial
You’re in the deepest hole of the Scrumbut Valley of Death. Scrumbut means “we’re doing Scrum, but…” So, in fact, you are not really following the process.
Your sprint planning is basically guesstimation, you are wrong more often than you’re right with the estimates.
Level 2 – Managed
Now you’ve reached a local maximum of the Scrumbut Valley called The Summit of False Hope. Things started to improve. You think you got it. You achieved some repeatability, sprint goals are met more often than they’re not, planning is less chaotic, results more consistent.
However, you know deep down, that if you’d taken a month off to travel to Australia, things would deteriorate. It’s you and a couple of key players that keep the lights on. Your sprint planning practices are quite good, but not exactly documented or standardized.
Level 3 – Defined
Finally, your team of heroes has left the Scrumbut area, and entered the fertile land of Standardized Practices.
The key difference between level 2 and 3 is that now the planning process is standardized and the organization owns the processes, not individuals. So, for instance, if one Scrum Master would leave, the organization could replace her without any impact on the planning quality. It’s the organization that owns the know-how, teaches it to people, maintains and updates its standards.
Let me give you a few examples of innovations I’ve seen on top of standard Scrum in teams that were at least on level 3.
1. Catalog of User Stories
You can think of sprint planning as preparing a container full of cargo for transport. Container represents the sprint backlog. User Stories represent sub-containers of a certain size. Your goal is to achieve long-term predictability of planning and to get there, your 2-point stories in sprint 3 should be similar to your 2-point stories in sprint 30, right? Also, your 2-point stories should be around 4 times smaller than your 8-point stories both in sprint 3 and sprint 30. How to achieve such stability? Prepare a catalog of user stories. Take the best examples of 2-point stories, the best of 3-point stories and so on. Then, during planning, you compare your new stories to those from the catalog.
2. Types of User Stories and corresponding Definition of Done
If your team does several categories of work that are very different (say, new features, maintenance, and research), there’s no point in trying to squeeze it into the same framework. The new feature story will have a different DoD than a research story. Create a separate catalog for each of the types.
3. Estimate and measure both points and time
You can do two levels of planning. Planning 1 is strategic, Product Owner must be present, the goal is to ensure you have enough stories to work on, no priority story is missing, stories are sorted by business value. You work on the story level, you can estimate points per story, you can give the PO a rough estimation of which stories will be done in the next sprint.
Planning 2 is done within the team only, you break down each story into details, add subtasks, and estimate it in time. I’ve seen teams assigning tasks to people, and ensuring that the capacity of people meets the assigned estimations. Some would argue it’s against the spirit of agile. I’d say if it works, let it be. In the real world team members aren’t always interchangeable, so if only Steve can do one thing, and Steve will only spend 5 days of the sprint with the team due to something, then I’d say assign Steve with Steve-level work.
Also, many people tend to estimate better when they know it’s them who’ll do the work.
Now that you have both points and time for each story, you can catalog min and max time per each point category and use it as guardrails. If planning 2 revealed some complexities that put certain story beyond the guardrail of its category, it’s either time to reclassify the story or perhaps to rethink the guardrail.
4. Capture actuals
On every daily standup make sure people have reported elapsed time into their tasks. Show everybody your time-based Burndown Chart. Jira supports that nicely. If you capture time-based actuals, your Burndown Chart is useful every day, as it will show you precisely where you should be, where you are, and which stories are behind schedule. If you do a point-based chart, it will be most likely useless, unless you have very fine-grained stories.
Level 4 – Measured
Your team has discovered mathematics. This is huge. You are now able to approach some of the greatest questions of humanity. How long until Friday? Does size matter? How much wood could a woodchuck chuck if a woodchuck could chuck wood?
In other words, how many points could a scrum team burn if a scrum team could burn points? Size (of the story) does matter, and measuring it correctly is a major stepping stone we have thankfully achieved on the previous level. Knowledge of how many days each team member will spend in a sprint until Sprint Review Friday will also come in handy.
Level 4, however, requires much more than that. First, you should collect data on everything you do. Every sprint, every story, every subtask. How much did you estimate and how it really went. Then, build and tune a model. Eventually, use your model to predict the future.
Let’s say your PO came down and gave you a long list of requests from business stakeholders. You sit down with the team, break it down into stories and estimate. How precisely can you tell him when this all could be done? How often do you reclassify a story during planning 2? Let’s say your DoD changes. Can you tell how this will affect your estimations? A high-profile deadline is approaching, management gets anxious, they ask how certain are you about your predictions?
The better your model the better your answers to those questions.
Level 5 – Optimizing
When we have a good model, we can work on optimizing it. There is a lot of methodologies to choose from. Let’s try the Shewhart-Deming cycle, plan-do-check-act. It fits pretty naturally to scrum. A plan is a sprint planning, do is a sprint, a check is a sprint review and act is a retrospective.
Incidentally, nothing tells the story of the team’s maturity like the way retrospective is conducted. Do the team have process improvement goals? What sort of goals are those? Are stats well kept? Do the team demonstrate a measurement culture? Therefore, can their results and estimates be trusted?