The Sprint Planning Event: Agreeing Priorities And Planning The Work

The Sprint Planning event happens at the start of every Sprint and is when the Scrum Team plans the work that they will do during the current Sprint.

Who Should Attend?

A Sprint Planning event will include the whole Scrum Team, so the Product Owner, Developers and the Scrum Master (if facilitation is needed, which it typically is). Essentially, the Product Owner and the Developers work out which Product Backlog Items (PBI’s) they will deliver in the Sprint. The Product Owner identifies the highest priority PBI’s for inclusion and the Developers highlight any concerns, raise issues and dependencies that will influence the order and then proceed to plan what they will do and how they will do it.

For the Sprint Planning event to be effective, ready Product Backlog items (PBI’s) are needed. The Scrum Team will likely have spent significant time in advance refining the Product Backlog to add detail to PBI’s, break PBI’s down into small enough independent items with minimal dependencies. The PBI’s will have been sized so the Developers can be confident they can be achieved inside a single Sprint. There should be no major surprises to anyone involved when a PBI is brought into Sprint Planning.

Once the Product Owner has briefed the team on the highest value PBI’s, they will often step back to allow the Developers to plan how they will deliver them. Often the Developers will break the PBI’s down into tasks and estimate the work involved in each. Some teams do not need to go to this level of detail for every PBI if they feel they have a clear enough understanding already. Inspection and adaption over many Sprints will lead Scrum Teams to find the right level of detail to go into in Sprint Planning to make the best use of the time they have to create an effective plan.

The Developers take into account any holidays or disruptions expected during the Sprint, and any other factors that may influence their expected velocity (how much work was completed in earlier Sprints). They use their historical understanding of their velocity to decide how much they believe they can deliver in this Sprint. It is up to the Developers to decide how much they can do in a Sprint, not the Product Owner or Scrum Master.

Once the Developers agree to the work to be done, they add the PBI’s and any other supporting information that has been created (tasks, estimates etc) to their Sprint Backlog. The Developers manage this plan during the Sprint to implement the work they have identified.

How Long Should The Sprint Planning event Be?

The Scrum Guide advises that for a 1-month Sprint the timebox (maximum amount of time to spend) for Sprint Planning is 8 hours. If the Sprint is less than 1 month, it is likely Sprint Planning event will be shorter. The Scrum Guide says no more than this. So it is possible for 2-week Sprints to still have 8 hours of Sprint Planning if the Developers feel they need it and get a useful return from the time invested. Many Scrum Teams use proportional amounts of time, so for a 1-week Sprint, they would timebox their Sprint Planning to 2 hours. Either approach is fine as long as the Scrum team is able to create a useful plan and more often than not deliver the PBI’s that they forecast by the end of the Sprint. If they do not deliver as planned on a regular basis this may be an indicator that more time may be needed for planning (although there may be many other reasons not delivering all the PBI’s forecast during a Sprint).

You will notice that timeboxing – pre-determining a set amount of time allowed for each event – is mandatory in Scrum and common in most Agile approaches; many practitioners are often evangelical about it. From my own personal experience, it’s certainly helpful to make sure you don’t waste time and stay focussed. I find that eventually, a Scrum Team will find the right amount of time to spend in Sprint Planning.

What Should Be The End Result?

The objective of the Sprint Planning event is to end up with an artifact – the Sprint Backlog.

The Sprint Backlog includes a commitment – The Sprint Goal, which is a short description summarising what the team aims to achieve during the Sprint. The Scrum Team will craft the Sprint Goal together. The Sprint Goal is useful in updating stakeholders in what the Scrum Team is working on, without going into the often unnecessary detail for each PBI. It also helps to get the Product Owner to pick related PBI’s for a Sprint so the Developers can work together during the Sprint to achieve a common and shared objective with a valuable and clear outcome. Without this preparation and clarity from the Product Owner, the Sprint Goal can be less valuable and end up being a case of “get this unrelated stuff done” which often gives the Developers less opportunity to truly cooperate and work together.

The Sprint Backlog is the list of PBI’s and (often) tasks, estimates or other things the Scrum Team produced to support the work to be done during the Sprint. It is a forecast of what the Developers believe they can deliver during the Sprint. The Scrum Guide (prior to 2012) used to talk about the Developers committing to delivering all the PBI’s in the Sprint Backlog to meet the Sprint Goal. This has been depreciated for a number of reasons. Firstly just because a Developers commits to something is no guarantee it will all get done. Yes, we want them to give it their best shot, but they should not be punished for failing to meet a commitment if the work they planned turned out to be more complex and take longer than expected. Software development is complex and by its very nature unpredictable. This doesn’t mean we shouldn’t plan, but it does mean that often when we look deeper into the work we need to do when we start delivering it, we find unexpected complexity and additional things to be done. Scrum and agile approaches accept this reality and use empiricism to learn, inspect and adapt as work progresses so that over time a Scrum Team gets better at forecasting and planning what they can achieve during a Sprint.

Once you have a Sprint Goal and a Sprint Backlog, you’re ready to go to continue!

Do You Want To Learn Scrum? Simple Guide To Scrum
Do you want to learn Scrum? can help you. Learn fast, learn slow, learn for free, learn online, learn offline, learn via email, learn via video, learn with others, learn alone. Our Simple Guide To Scrum has something for everyone. Ultimate Scrum Practice Assessments
All our Scrum practice assessments. 20+ assessments and 1500+ questions. The most comprehensive practice materials available to help you with all the assessments.

Simon Kneafsey, my name is Simon Kneafsey and I am a Professional Scrum Trainer with & I am on a mission to simplify Scrum & Agile for 1 million people. I have helped 10,000+ people so far, and I can help you too. Find out more & get in touch.

Share this Post

Comments 1

Leave a Reply

Your email address will not be published.