First published in The Agile Zone, 30 April 2013
- 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.
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.
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:
Sprint Planning, Part Two:
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.
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.