The Secrets of the Sprint Planning Meeting Revealed

photo credit: http://www.flickr.com/photos/8512982@N05/1683497974

Why is the Sprint Planning meeting so difficult to get right? Agiliser Russ Lewis reveals secrets of the meeting that the Scrum Guide time-boxes to eight hours and describes in just 704 words.

Remember your first computing module at college? When they explained the difference between a problem and a solution? Or perhaps you went to a fancy university where they talked about the ‘business requirement’ and the ‘solution domain’ – because customers don’t like being described as a problem and the word ‘business’ sounds more, well, business-like.

Just in case you were away that day, or you have forgotten, here’s a trivial reminder. “I feel hungry” is a requirement and “get something to eat” is the solution.

Is Sprint Planning really the same as eating? You ask. Well, no, but I’m writing this whilst waiting for my dinner to arrive, so my goal is very much on eating (which seems a jolly good solution).

The Sprint Planning meeting is really two meetings: Part A, which is devoted to understanding the business problem (requirement or need) and identifying a suitable solution; and Part B in which a work plan is defined for that solution. Or, as Sutherland and Schwaber put it in the 2011 version of the Scrum guide:

• Part A: What can be delivered in the Increment resulting from the upcoming Sprint?
• Part B: How will the work needed to deliver the Increment be achieved?

They re-worded this in the 2013 Scrum Guide to emphasis that Sprint Planning was really a single meeting that needed to cover two topics. The first topic is concerned with selecting the next most important set of functional requirements and the second with the technical specification of those requirements, which would then be developed and delivered during the Sprint.

In “waterfall-speak”, Topic One might be described as within the role of the Business Analysts and Topic Two of those who design and write code. However, this is heresy and I could be excommunicated (again) for saying it. Not least because “there are no job titles in Scrum”. Scrum teams are cross-functional, and that truly is a good thing, even if people do misunderstand what it means.

Unlike Waterfall, everybody in a Scrum team is expected to understand the requirement and the proposed solution, as well as the plan to develop it. Delivering the increment is a Team responsibility, so they must understand it together and define the work tasks together. That’s why the entire Team attends the entire meeting.

Requirements & Solution Identification: Sprint Planning Topic One

Sprint Planning meetings work best when the Backlog has been adequately prepared beforehand. Scrum refers to Product Backlog Increments (PBIs) but most people prefer Stories (or User Stories), which come from Kent Beck’s eXtreme Programming.

A Story is basically a user requirement. It has value (to a specified type of user) and is independent of other Stories (it could be delivered alone). It is also measurable (think SMART). If you have encountered Use Cases before, then a Story is much like a brief Use Case, at least initially.

Product Owner Prioritises the Sprint for Value

The PO’s responsibility now is to prioritise all the stories in the backlog based on their value to the business against the cost of completing them. Then to make the best use of the capacity available in the sprint so the team works only on the most valuable stories.

But there’s another consideration for the PO. It can be more valuable to complete certain stories together, for instance if they form something that is valuable and deployable to the customer, or in the case of technical dependencies, between stories. The selected stories help define the main purpose of the sprint and are grouped together to form the Sprint Goal.

Topic Two (part B of old) has to follow Topic One (Part A). But first, the PO needs the Team’s commitment to complete the story under consideration. And that’s what takes the time during Sprint Planning meeting. The more you discover about a requirement, the more complex it becomes. The estimating process deliberately uncovers the uncertainties contained within the requirement.

The team may play the Planning Poker game to ensure that everyone, no matter how inexperienced, really does know “the story” and “has a voice”.

Work Plan: Sprint Planning Topic Two

Some groups like to proceed directly to the Work Plan with the story they’ve been discussing. Others follow the original A/B meeting formula where all stories for the Sprint are understood, then decomposed into a work plan. In this second topic, the Team’s job is to re-examine each story and clarify the way they are going to work together and with stakeholders to produce the solution to the requirement that has been agreed with the PO.

It’s usual to break this down into individual tasks of work. In a cross-functional team, a task should be clear enough that almost any team member would be able to perform it. Ideally, engaging two members working together. This is another XP practice, called Pair Programming, and it applies to all work not just programming.