Sprint Planning in Practice
First published in The Agile Zone, 30 April 2013
"In preparing for battle I have always found that plans are useless, but planning is indispensable"
- Dwight D. Eisenhower (1890 - 1969)
I once worked as a Scrum Master at a company which was part-way through an agile transition. It was an interesting place...they had decided, as a matter of company policy, to have one-week Sprints. Chances are you're thinking the same thing I did when I started there. Scrum recommends a Sprint length of between two and four weeks, and with good reason. Any longer than a month and the inspect/adapt cycle becomes too attenuated. On the other hand, anything less than a couple of weeks won't give a big enough sweep of prior activity for a team to "inspect and adapt". Not only that, but ultra-short cycles can make the relative overhead of Sprint Planning, Reviews, and Retrospectives too high to be viable.
When I voiced these concerns, it was put to me that the development team was too reactive and that tighter development cycles would permit better control. The One Week Rule had come down as an edict from senior management and I was expected to deal with it. The logic ran like this: if Sprints were good, having more Sprints more often must surely be better.
And so it was that every Monday morning a planning session would be conducted. The Product Owner dutifully turned up with the subset of the Product Backlog he wanted the team to deliver. The team made their estimates and a Sprint Backlog was negotiated, along with a Sprint Goal. By the time planning was over there was a set of agreed user stories, and a commitment to deliver a potentially releasable increment of value.
Scrumban puts the skids on
Now here's the kicker. Like the vast majority of Scrum teams on the planet, this one wasn't just doing project work from the Product Backlog. They were also doing BAU work, including defect fixes and emergency patches. In effect they were doing Scrumban...the sort of compromise I talked about in an earlier post. By the time the team got back to their desks "fast track" work had already rolled in, and the goal and the plan were already defunct.
That's where the client was wrong. If the Sprint Backlog isn't respected, it doesn't matter how short a Sprint is. It never will be anything more than an idealised forecast. Eisenhower, on the other hand, was right. You should always understand the situation you are in and know what your options are. Wise operational adjustments can then be made and you can update your tactical and strategic projections for the future. Even though the product of planning might not survive first contact with the enemy, the act of planning remains invaluable.
So I coached the team to use the Sprint Backlog as a trading space for this unplanned, high-priority work. Nothing came in unless something was moved out of equivalent size. We could then show that even though velocity was being maintained or sometimes improved, product burn-down was poor, and the release train would be affected accordingly. We could predict that this situation would hold for as long as the team was expected to deal with BAU work. Without that information we wouldn't have been able to say where we were. With it, we could engage more fully with our stakeholders and encourage them to make informed decisions. I say that's one up for agile practice, and one up for Ike.
How to plan a Sprint
So then, how do we set about planning for a Sprint Goal that is in continual flux? First of all lets consider Sprint Planning in an ideal world where Scrum is applied properly, and a Sprint Backlog is respected along with a team's commitment to the goal. We'll work backwards from there to reality.
Sprint planning should be a collaborative act involving all team members and the Product Owner, with the Scrum Master acting as a facilitator. It is time-boxed to a maximum of 8 hours for a monthly sprint although this can be reduced to 4 hours if the sprint cycle is two weeks long. The Sprint Planning session should be split into two parts. The first part considers what work should be done, and the second part considers how it should be done. Note that the Product Owner only needs to be present for the first part. He or she can leave for the second part, but they should still be contactable and able to answer any questions that arise from the team.
Sprint Planning, Part One:
The Product Owner presents the work he or she would like done to the team. This work is normally drawn from the highest priority items in the Product Backlog.
The development team and the Product Owner work together on reaching a common understanding of the requirements. This can involve writing user stories and acceptance criteria for each piece of work that is to be delivered.
The team estimate how much effort is required for each piece of work - such as a user story - that the Product Owner wants completing. They'll only accept as much work as they think they can handle within the upcoming Sprint.
A Sprint Goal is agreed which represents the overall outcome of the work. The goal should be an overarching statement of business value, and to which all individual pieces of work will make a contribution.
Sprint Planning, Part Two:
The team figure out how they will actually do the work they committed to in the first part of Sprint Planning. This can involve identifying tasks for each user story.
The team will plan out enough tasks to allow work on the Sprint Goal to start. There's no need to plan out all of the tasks that will need to be done during the Sprint. Task planning should be an ongoing activity for the team and it should be subject to continual revision.
The team will prioritize the Sprint Backlog so that the risk of not meeting the Sprint Goal is minimal. This should take into account any external dependencies that must be resolved before the work can be completed.
If the team have questions about the requirements, then the Product Owner should be contactable and able to answer them before the planning session ends.
Being pragmatic about planning
Now let's look at the compromises that often have to be made in Sprint Planning. An important thing to note is that these compromises don't actually contradict any of the above points. It's more a matter of looking at these best practices through the lens of pragmatism, and figuring out what needs to be done to make them viable.
Decide your budget. When emergencies arise, the team will likely end up being diverted from their Sprint Goal. If you know the total size of the Sprint Backlog then you can trade work in and out of scope accordingly.
Be flexible about the Sprint Goal. Remind stakeholders that the team are not wholly committed to project work...they have to do BAU work as well. Remember to keep stakeholders updated about the risk to the Sprint Goal when diversions happen, especially the Product Owner. Just because others are cavalier about Sprint commitments doesn't mean you should be.
Use the "yesterday's weather" analogy to estimate how much should be planned into a Sprint. Just as the weather today is most likely to resemble the weather yesterday, the rate of value delivered this Sprint is most likely to approximate the velocity of the last one. Remember to adjust the budget for any foreseeable absences.
Plan each work item to be as small as possible. Value can be delivered sooner and with less risk of unfinished work remaining at the end of the Sprint.
Consider setting a Sprint budget based on the number of cards to be actioned, rather than trying to estimate the number of story points each one has. This can encourage the authoring of smaller user stories that are less likely to be blocked or partly completed.
Resist the temptation to estimate each work item in hours or days. This is unreliable when estimates are large, and can encourage micro-managing by stakeholders who can expect every minute to be accounted for. Sprint value is determined by deliverables, not by accountancy.
Some Sprint Planning antipatterns
Planning for impediments to happen. Don't plan for impediments. Either plan to remove them or plan around them. For example, if you know that a user story will be blocked mid-Sprint because of certain dependencies, write smaller stories that describe the value earned at each point in the stream.
Cherry picking. Don't allocate work to team members during planning, or allow them to "cherry pick" certain pieces of work. An agile team should be cross-trained and as the Sprint progresses, the next available team member should action the next highest priority item from the Sprint Backlog. If your team does have skill silos - and the vast majority do - plan to remove those silos instead, for example by pairing members and adjusting the budget accordingly.
Confusing emergency or BAU work with story points delivered. When emergency or BAU work is traded into Sprint scope, it counts as team velocity (since the team was not idle) but it does not count as work done on the project. Don't confuse velocity with burn-down.
Precocious harvesting of points. Don't allow undone work to count for any points delivered in the Sprint. Work is either done or it isn't, as per the Definition of Done. Move the work into the Product Backlog and re-estimate it accordingly.
No Product Owner. If the Product Owner isn't present for a Sprint Planning session, you can't negotiate the business value that will be delivered. Unclear Product Ownership is a contra-indication to Scrum and suggests that a Kanban type model may be more appropriate.
Conclusion
The beginning of a Sprint provides a new opportunity for getting things right. Unfortunately, Sprint Plans tend to be as ephemeral as the morning dew. However this is no reason to feel despondent or cynical about the process of Sprint Planning. A carefully crafted plan captures what was originally hoped for, and provides a point of comparison for where we stand in relation to our ambitions. If nothing else, it provides material for reflection in the next retrospective. That's why planning matters. Agile practice rests on the three legs of transparency, inspection, and adaptation...not on the assertion that the plans themselves are ever likely to last.
