5 Steps to Effective Sprint Planning

 

The Agile Manifesto has four values. A crucial one is that we value "responding to change over following a plan". This statement could well be misconstrued as meaning if you had a choice between change and planning, then go with change and forget about the planning. However, this could not be further from the truth.

Planning does occur in Scrum projects, just like in Waterfall. In fact, there is generally more planning done in Scrum simply due to the iterative nature of the work. There are planning/feedback sessions at the beginning, during, and end of each Sprint. When you add these sessions up, the total time spent is quite often more than what occurs during the upfront planning process so indicative of predictive lifecycles.

There are various levels to planning Scrum projects such as Project-level planning, Release-level planning and Sprint-level planning. Today we take a closer look at Sprint planning.

At the beginning of every Sprint, we set aside a planning session of no more than 4 hours per 2-week Sprint. The Scrum Master makes sure that the Scrum Team is present, and usually through the Product Owner's assistance with stakeholders, ensure they too attend the meeting. So, assuming that everyone who should be at the meeting is at the meeting, we can go ahead with our 5 steps to effective Sprint Planning.

1. Bring the Update
Before you even begin Sprint planning, there are two important items that you need to have. The first is the latest Product Increment, and the second is the updated Product Backlog. You must be sure that the Product Backlog was refined during the previous Sprint because Sprint Planning is not the place for Backlog Refinement, although some Scrum Teams still follow bad practices because they left it too late. Any user stories (or items) that were added, deleted, split, reprioritized or risk adjusted in the previous grooming session should have been updated in the Product Backlog.

2. Discuss, Negotiate, Decide
This is where an engaging discussion takes place regarding the remaining items in the Product Backlog. The Product Owner will have their own agenda (maximize value for the customer), while the Development Team take that into consideration along with their known capacity and begin to select the stories for the current Sprint.

3. Sprint Goal
Every team needs a goal right? Scrum Teams are no different. They develop a shared understanding of why they are going to performing the items selected for this Sprint. I like to think of the Sprint Goal as a contract of commitment within the team, for the team, and by the team.

4. Sprint Backlog
Once the Development Team decide what stories to include in the upcoming Sprint, this becomes part of the Sprint Backlog. It is a sub-section of the Product Backlog, not a separate document. It is important to remember that only the Development Team owns the Sprint Backlog. Not even the Product Owner can change it. The other part of the Sprint Backlog is the plan on how to get the work done by the end of the Sprint. This is one of the most important parts of Sprint Planning, because it will determine if the Sprint Goal can be met, and if the Definition of Done will be realized. Negotiation takes place again, and this stage can become quite heated, because the members of the Scrum Team may have very different views what "Done" means. Therefore, the Definition of Done is perhaps the single most crucial element during this meeting. Without a clear understanding and agreement of the DoD, the Sprint is more than likely gong to fail at the Sprint Review gate.

5. Process Improvement
At some point we need to factor in the improvement initiatives agreed upon during the previous Sprint Retrospective. These improvements, while not as crucial as the product increment perhaps, are still an important part of the Sprint, and in my view should be included in the Sprint Goal. While the details of the process improvement may have already been decided during the last retrospective, the Sprint Planning meeting provides a great opportunity to quickly summarize what continuous improvement initiatives the Scrum Team will strive to achieve during this Sprint.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!