What is the biggest advantage of Scrum approach in software development? Probably its flexibility that is easily achievable thanks to so-called sprints - short periods of time, each of which aims to result in new product functionality and/or features. Built on this idea of the sprint, it follows that the sprint planning meeting is an invaluable opportunity for a scrum team to ensure that the project is progressing both realistically and as quickly as possible. How do you make sure your sprint planning is as efficient as possible? Read on to find out!
Table of contents
In Scrum development, sprint planning is key
The secret of Scrum’s success lies in its incremental nature, with the project broken down into a series of short ‘sprints’, each resulting in a fresh iteration of the product, or increment.
Lengths vary, but at Boldare we usually work with sprints that are no longer than two weeks. It’s not a secret golden ratio, but this amount of time makes planning quite efficient - it’s just enough to keep the team focused, and it allows us to deliver a working piece of software at the end of the period.
Scrum, just like most other frameworks or methodologies, is only as good as its planning process. A well-planned sprint allows the development team to work and focus together on the same goal and deliver an increment that drives the whole project forward.
This guide to sprint planning covers goals, key features, and outcomes, giving you all the basic elements of a perfect sprint planning session.
What is sprint planning?
A Scrum sprint is effectively a mini-project within the overall product development process, designed to achieve identified tasks and produce specified product features. As such, an efficient sprint has agreed goals and objectives and is planned by the scrum team together, deciding on the items from the overall product backlog that they will tackle in the sprint ahead.
Sprint planning usually takes the form of a team meeting held prior to the sprint and breaks down into two basic halves: deciding what to do, and then agreeing how to do it.
Key questions for efficient sprint planning
Who should attend a sprint planning meeting?
In short, the whole scrum team, though the individual roles do vary.
Faced with the product backlog of tasks, the development team decides what elements should be tackled in the upcoming sprint. This includes discussion of the relative priorities of backlog items and the product owner has a role in clarifying those priorities and other details from the client perspective.
However, the decision (and therefore ownership) regarding what to include in the sprint, including setting the sprint goal and how to achieve it, lies with the team members. The scrum master’s role in all this is to facilitate the process, avoiding unnecessary side-tracks and guiding the team toward clarity going forward.
How long should your planning meeting be?
As a rough rule, for a two-week sprint, expect the planning meeting to take approximately four hours. Assuming that the project is under way, the team understands its various roles, and you have a clear product backlog to work from, that should break down into around two hours to go through the backlog and choose tasks and stories to work on, and then two hours to agree how these goals will be achieved.
Why are outcomes and sprint goals important?
If the idea of sprint planning is to map out and organize the work for the sprint, and agree a realistic scope, then then the scrum team must end up with:
- An agreed list of backlog stories and tasks that they are committed to working on.
- A clear ‘definition of done’ for each item.
- An overall sprint goal to give the sprint some cohesiveness, pulling it all together (in other words, how will you define the sprint as a whole as ‘done’?)
Why is it so important to define ‘done’? Projects can get confusing (or confused) as extra tasks or interesting alternatives occur during the sprint. The sprint planning meeting is an opportunity for some clear thinking by the scrum team and the definition of done is a way of preserving that clarity for when you need it later on. As extras crop up, you can decide whether they are appropriate for this sprint by asking, will working on this get us closer to ‘done’ or not?
How to choose the most suitable sprint goal?
Setting an engaging and beneficial sprint goal can be problematic. Here are some pro tips that will help you to understand how to create a meaningful sprint goal:
- Tasks to be delivered as a sprint goal are supposed to either contribute business value or help users solve a problem.
- Sprint goals should be ambitious (to motivate the team), but achievable.
- Make sure that the sprint goal is measurable and has a clear and understandable definition of done.
- All team members should share the same vision of how to achieve the goal.
- The sprint goal should involve as many team members as possible.
What happens if the sprint goal won’t be reached?
This is the kind of thing that should be picked up in your daily Scrum meetings – regular, transparent checks on team progress act as an early warning system if your sprint goal is in jeopardy. When that happens, there are two basic alternatives:
- The sprint goal is no longer relevant – New information or data has come to light, or perhaps the project has pivoted and is now focused in a different direction, and in these circumstances, the sprint should be cancelled (after all, it’s taking you down an irrelevant path) and, assuming the project is continuing, a new sprint planned.
- The sprint goal remains relevant but cannot be done within the time available – In this case, the work being done in the sprint is still necessary so continue the sprint. However, afterwards, the sprint review and sprint retrospective meetings should be used to establish why the sprint goal was unachievable and how the next sprint can avoid the same fate.
If you work with a remote team, you can use our tool, Sprint Retrospective Tool, to conduct your retrospectives.
What is the role of scrum master?
The role of scrum master is to support the team, help them with process-related issues and keep the planning meeting inside the time-box. It’s also very important, to know that the scrum master is not solely responsible for planning outcomes - they are the shared responsibility of the scrum team.
The scrum master role is crucial, especially if you’re working with an inexperienced development team that tends to mix different accountabilities. Likewise, if you plan to work with an external, outsourced software company, make sure that your dedicated dev team will have the support of an experienced scrum master.
What are the planning mistakes to avoid?
Knowledge comes with experience, but that doesn’t mean that you learn only by making mistakes. Here are some common mistakes we’ve observed (and survived) so you don’t have to:
- Making the sprint too long - The further you look into the future, the more blurry it appears. Keep the sprint adjusted to the size of the backlog, team availability, and scope of the works to keep it realistic.
- Taking on too much - this is one of the most common issues. To make planning meaningful, each team member has to be realistic about their own commitments. Team members should only commit to tasks they’re able to deliver - sometimes that means saying “No” to some of the tasks in the backlog.
- Not being honest - The whole team has to be honest about their capacity and capabilities. Make sure that team members don’t adopt a ‘wishful thinking’ attitude and encourage them to communicate if they need help or simply don’t know how to proceed with a task.
- Not working according to the Scrum - While many organizations may say that they use Scrum, in practice this is not always the case. Scrum is not just a general set of rules and different types of tools. The most important element for success is experience in using Scrum - it’s an extremely practical method.
Planning before you plan – are you well-groomed?
For a sprint planning meeting, as with most project events, the old proverb preparation prevents poor performance applies. Leaving aside the obvious ‘housekeeping’ issues of finding a suitable venue and date, arranging any necessary equipment (whiteboards, sharpies and sticky notes, or maybe an online planning tool coupled with video-conferencing software for a remote scrum team) and booking the catering, etc. possibly the key preparation activity is grooming the product backlog.
What does ‘grooming’ mean in this sense? Also known as backlog refinement, the principle is that if the backlog is going to be the backbone of your sprint planning, you want it to be in good shape. Grooming is the process of checking through the backlog beforehand, ensuring that it’s up to date and that each item is prioritized (with input from the product owner), has any necessary user stories (and no unnecessary stories) and has an accurate (as it can be with current data) time estimate.
Ideally, grooming takes place before the sprint planning session so that any information gaps or lack of detail or input can be rectified in advance. Thus leaving your scrum team able to focus on planning during the sprint planning meeting.
Sprint planning – a simple agenda
Nobody likes meetings that are too long. To keep your sprint planning efficient, there are two essentials:
- a groomed backlog with prepared and well-described tasks (regardless of the tool you use to manage those tasks);
- a simple agenda to keep the meeting running smoothly.
We mentioned earlier that a sprint planning meeting consists of two halves:
Scope of the sprint
Here, the development team work through an up to date backlog which has been prioritized according to all the available information, with the aim of selecting those user stories and items that will be addressed in the sprint. Scope activity should include:
- Agreeing the sprint goal as a basic guide for the sprint’s focus.
- Factoring in the team’s availability (including considering vacations, public holidays, or other events that limit the time available).
- Deciding which backlog items will achieve the sprint goal AND can be done within the sprint period given the team’s available capacity.
Plan of the sprint
With clarity on the sprint’s destination, it’s time to discuss the route – how, exactly, do you plan to arrive at that destination?
This discussion by the team of the detail of how they will deliver the identified backlog items will include any dependencies between items, and also the probability and likely consequences of any project (or sprint) risks.
Obviously, this is just an example - sprint planning varies according to the Scrum framework or tools that are used, and also on the company culture and other factors.
Summary
Sprint planning is arguably one of the most essential activities in the Scrum framework. To use another planning proverb: Fail to plan, plan to fail. Involving the whole scrum team, looking in detail at the next stage of the project, ensures a degree of commitment to the sprint’s agreed tasks (and, by extension, the whole project). By first focusing on the what, and then the how, a Scrum sprint planning meeting should result in an agreed sprint goal, a selection of user stories and tasks from the product backlog, and an accurate (as possible with current data) forecast of what the team will be doing during the sprint.
Share this article:
