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 Edit
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 Edit
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 Edit
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.
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.