Scrum Ceremony; Sprint Planning
Sprints are the iterations, within the scrum methodology and this makes that the length of the sprint, dictates the rhythm of your project. In a well organised scrum project you will “feel the rhythm” as a heartbeat sprint after sprint. A healthy consistent sprint plan, will provide a healthy heart rhythm, which results in a successful project.
As described in the Scrum Guide, the sprint plan, is the work to be performed in the Sprint and is planned at the Sprint Planning meeting. This plan is created by the collaborative work of the entire Scrum Team.
A Sprint Planning meeting is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the ceremony is usually shorter. The Scrum Master ensures that the ceremony takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
Sprint Planning answers the following:
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
Work is selected from the Product Backlog and pulled into the Sprint Backlog. Now remember that the work in the Sprint Backlog is not a commitment, it is a forecast. The only container of a Sprint is its time box, not the work planned for the Sprint.
The sprint planning meeting is attended by the product owner, Scrum Master and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies. I would certainly not recommend doing this.
During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
The product owner doesn't have to describe every item being tracked on the product backlog. A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint's worth of product backlog items.
To make an example really simple, suppose a team always finishes five product backlog items. Their product owner should enter the meeting prepared to talk about the top 10 priorities.
There are two defined artefacts that result from a sprint planning meeting:
A sprint goal
A sprint backlog
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are example sprint goals on a basic Web shop application:
Implement basic shopping cart functionality including add, remove, and update quantities.
Develop the checkout process: pay for an order, The sprint goal can be used for quick reporting to those outside the sprint. There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail.
The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.
The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.
An important point to reiterate here is that it's the team that selects how much work they can do in the coming sprint. The product owner does not get to say, "We have four sprints left so you need to do one-fourth of everything I need." We can hope the team does that much (or more), but it's up to the team to determine how much they can do in the sprint.
What I find, makes the sprint planning meetings a lot more effective is to prepare this meetings with the product owner. Create already a first version of the sprint backlog and propose a sprint goal. This will give the team a more focused approach about the work at hand. I also recommend to ask the team to estimate stories in the backlog, already ahead of the sprint planning sessions.
Now we know all about the sprint planning session. During my coaching sessions I got asked the question, how do you plan your sprint planning sessions and make them effective?
Step 1. INTRO & SET THE SCENE
First always set the scene and introduce the meeting. Remind everyone that the purpose of the meeting is to plan the work for the next sprint. Remind everyone of the sprint duration and demo date.
Share the desired meeting outcome:
A sprint goal
A sprint backlog including the sub tasks
Share the planned agenda:
Define the sprint goal
Decide how much to chew off
Decide which stories to do this sprint
Create tasks for stories
Step 2. DEFINE THE SPRINT GOAL
Next step is to come up with a sprint goal: The purpose of having a goal is to be able to select user stories that support the goal, i.e. help you work towards something bigger than just delivering a collection of stories or unrelated features. It’s also really useful to assess at the end of the sprint whether you have been successful or not. Success is achieving the sprint goal, not just delivering all the stories you had planned to get done. Usually I will define a proposed sprint goal together with the product owner in relation to the business value to be delivered. When you are working in a software development project, usually the sprint goal is defined around the delivered features. In our web shop example “Full shopping card functionality”
Generally speaking I think one goal is better but if it is way too small it’s okay to have a dual goal. Just make sure you don’t end up with just a collection of unrelated user stories
Step 3. DECIDE HOW MUCH TO CHEW OFF
If you are using story points or count the number of stories delivered as a measure of velocity it’s a good idea to decide on a target velocity next. Base that decision on looking at a combination of past velocity, people’s availability (any holidays?) and just plain gut feeling.
Make sure you take past data into consideration, not just wishful thinking about how much you feel you “should” get done. This is also the reason why I like to discuss target velocity before choosing stories for the sprint: It is all too easy to get carried away with enthusiasm and optimism.
If you don’t have any data yet, don’t worry. Just go by gut feeling and start collecting data now.
STEP 4. DECIDE WHICH STORIES TO DO IN THIS SPRINT
Take your prepared sprint backlog and discuss for each candidate story what it means, what you’re trying to achieve and what success looks like. Do this for all the stories you think you have prepared together with the product owner into the sprint. Discuss with the team if there is room for additional user stories or if there is too much in (which usually seems to be the case) and take some user stories out. Choosing which stories to consider for your sprint is mainly determined by the sprint goal.
Other considerations are:
What if we can do more than just the stories that support the goal?
You could have a secondary goal (“Fix push notifications and improve motors search”) but make sure these are prioritised against each other. Or you could “fill” with bug fixes, enhancements and smaller, not necessarily related requests. Make sure to communicate that these are less important though than things that support the sprint goal and will get dropped if the goal is in danger.What if there’s stuff we really want to do such as re-paying some technical debt?
I like agreeing on one or two of such items for each sprint. I have found ca. 20% of a sprint’s work dedicated to the team’s wishes to be a good thing.What about high risk items?
It sometimes makes sense to prioritise a risky story higher to just learn, gather knowledge and be able to plan. Early prototypes for hairy features are a good idea.
What it comes down to is to have a discussion between the team with their technical expertise and the Product Owner as the representative of end users and stakeholders and to decide together what you want to do during the next couple of weeks.
Also, make sure not to “fill up” your entire sprint with planned work but to leave some room for unexpected opportunities or complexities.
Step 5. TASK PLANNING
I like planning individual tasks for each user story and to make work visible at a granular level, one tip is for all the disciplines in the team to create subtasks for all the stories. This makes it easier for people to collaborate around user stories and to help each other reach a shared goal.
As an example for the user story “As a customer I want a shopping card, where my order shows up” we identified the following tasks:
If you find it hard to make tasks ask yourself how you would get started. And what you would do next? And then? You’ll find you can come up with quite a lot of useful tasks that need to be done.
Try to keep tasks to less than a full day’s work so that stuff moves through on a daily basis and there is a sense of progress and opportunity for collaboration during the daily stand-up. Also, try to split them in a way so that in theory different people could do different tasks.
Remember that you don’t need to get the tasks right upfront: It’s perfectly fair to add new tasks to a story or to delete tasks that are no longer needed during the sprint.
And don’t assign tasks upfront! It will just make you wait for each other and cheat you for opportunities to collaborate and help each other.
Optional Step. SET UP YOUR VISUAL WORK SPACE
This is could be the outcome of your sprint planning meeting: A visual work space with a list of user stories and associated tasks. This is visual work space is, within the KANBAN methodology used to physically move a story to the next status.
Here’s an example of a KANBAN board:
If you aren’t co-located you can of course achieve the same in Jira or some other tool. I really like the tactile and highly visible nature of the post-it note board though, so if you have the option I’d definitely use one of these.