dzone.

com

https://dzone.com/articles/sprint-planning-practice

Sprint Planning in Practice

"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 reestimate 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.