How to Plan Sprints

**By Moye Balogun**

A
crucial way an Agile team can have a productive meeting is by knowing how to
properly plan sprints. Sprint planning is a key part of “the team’s
predictability and transparency” and is the time a team will plan what they
will deliver in a sprint (Rose). Since sprint planning is essentially
organizing what the team will do, knowing how to do it efficiently is imperative.

### **Utilize a Taskboard and Sticky Notes**

Whether
a taskboard takes the form a physical whiteboard or it is virtual through a
software package, it is an essential artifact when planning sprints (Rose). Though
both methods are sufficient, it is best to start off with a physical board so
that the team can acquire a deeper understanding of the tasks through a
hands-on experience (Rose). The format should be in the way demonstrated in the
image above. The headings can vary, but they should basically break down what
the user stories are, what the team needs to do, what the team is currently
doing, and what the team has done. When planning a sprint, each developer will
decide how they feel they can contribute to the story by writing their daily
tasks down on a sticky note (Rose). Tasks should only be a days-worth of work
or else they do not truthfully represent the team’s progress (Rose).

(Image From: https://manifesto.co.uk/agile-concepts-scrum-task-board/)

### **Know When to Plan Sprints**

Sprint
planning is best done directly after a demo since at the end of the sprint, teams
will need to plan for the next two weeks (Rose). Planning officially begins
when “the product owner delivers the user stories they wish to complete”
(Rose). Similar to how a customer would order at a restaurant, the product
owner is ordering what they desire to be delivered in the sprint (Rose).
Furthermore, instead of driving the team to deliver, the product owner should
be there solely to answer questions (Rose). If the product owner goes against
this method, they run the risk of falling into traditional project management
methods (Rose). The team should be the ones deciding how they will deliver
(Rose). The product owner is there to present the stories, the developers
should be the ones tasking (Rose).

### **Avoid a Breakout Blizzard**

The
meeting where sprint planning takes place should not be the first time the team
sees the stories (Rose). The team should have “estimated the stories in an
earlier estimation session” and leave determining how good the stories are for
the sprint planning meeting (Rose). Since converting user stories into daily
tasks in not necessarily an easy process, developers often end up realizing
what the stories actually mean during planning (Rose). Then to simplify the
story they will have to break down to story in smaller pieces or re-estimate
(Rose). This can easily lead to a story breakout blizzard, which can be defined
as “when the team realizes the many of the stories are not ready to be tasked
out” (Rose). This can best be avoided by investing more time in refining the
backlog (Rose). The better a team is at backlog refining, the less time they
will spend talking about stories during sprint planning (Rose). The primary
benefit to this is that more time can be spent deciding how the team will
deliver (Rose).

Consistently
following the methods listed above should ensure the increased efficiency of
any Agile team’s sprint planning.

Works Cited

Rose, Doug. “Planning
Your Sprints.” *Lynda.com - from LinkedIn*, 29 Sept. 2015,
www.lynda.com/Business-Skills-tutorials/Planning-your-sprints/175075/438001-4.html.