How much time should be spent on a planning B writing C completing stages

In the this article Dave West, CEO of Scrum.org, outlines the sprint planning ceremony as it's described at Scrum.org. Scrum.org teaches scrum according to the Scrum Guide, which is considered the official guide for the scrum framework among the agile world. Below Megan Cook of Atlassian shares her perspective on sprint planning in this video:

Prep for sprint planning meeting

Running a great sprint planning event requires a bit of discipline. The product owner must be prepared, combining the lessons from the previous sprint review, stakeholder feedback, and vision for the product, so they set the scene for the sprint. For transparency, the product backlog should be up-to-date and refined to provide clarity. Backlog refinement is an optional event in scrum, because some backlogs don’t need it. However, for most teams, it’s better to get the team together to review and refine the backlog prior to sprint planning.

Pro Tip:

If you have a two-week sprint, run a backlog refinement meeting in the middle of the sprint. It’s great for the team to step back from the sprint and look at what's next. Not only does it help prepare for sprint planning, but also can give a different perspective for the current work.

Setting a time limit for sprint planning

Sprint planning should be constrained no more than two hours for each week of the sprint. So, for example, the sprint planning meeting for a two-week sprint would be no longer than four hours. This is called "timeboxing", or setting a maximum amount of time for the team to accomplish a task, in this case, planning the sprint. The scrum master is responsible for making sure the meeting happens the timebox is understood. If the team is happy before the timebox is finished, then the event is over. A timebox is a maximum time allowed; there is no minimum time allowed.

Pro tip: Focus the first part of sprint planning on the objective of the sprint rather than the details of the backlog. By focusing on the goal rather than the work it is possible to find smart alternatives for how that goal is achieved.

Focus on the outcomes, not the work

During sprint planning it is easy to get ‘bogged down’ in the work focusing on which task should come first, who should do it, and how long will it take. For complex work, the level of information you know at the start can be low, and much of it is based on assumptions. Scrum is an empirical process, meaning that you can’t plan upfront, but rather learn by doing, and then feed that information back into the process.

The sprint goal describes the objective of the sprint at a high level, but the backlog Items can also be written with an outcome in mind. User stories are one great way of describing the work from a customer point of view.  User stories, written like the one below, re-focus defects, issues, and improvements on the outcome the customer is seeking rather than the observed problem.

By adding clear, measurable results to the user story, the outcomes can be clearly measured, and you know when you are done. By getting as much up-front clarity as possible on the work the team is focusing on, everyone gets the transparency needed to get started on the work. For example, leaving things vague is much worse than describing something as a question to be answered during the sprint.

Pro Tip:

Not knowing something is different from being vague. Don’t ignore the unknowns, they are the reality of doing difficult work. But don’t hide them by using vague words. Instead, be clear when you don’t know something and frame the work in terms of gaining an understanding.

Estimates are required but don’t pretend you know more than you do

Sprint planning requires some level of estimation. The team needs to define what can or cannot be done in the sprint:  estimated effort vs capacity. Estimation is often confused with commitments. Estimates are by their very nature forecasts based on the knowledge at hand. Techniques such as story points or t-shirt sizing add value to the process by giving the team a different way of looking at the problem. They are not, however, magical tools that can find out the truth when there is none to be found. The more unknowns, the less likely the estimate will be correct.

Good estimation requires a trust-based environment where information is given freely, and assumptions are discussed in the pursuit of learning and improvement. If estimates are used in a negative, confrontational way after the work is completed, then it’s likely that future estimates will be either be much bigger to ensure they never are wrong again or the time taken to create them will be much longer as the team second guesses itself worrying about the implications of getting them wrong.

Pro Tip

Explore using different estimation techniques such as t-shirt sizing or story points. Different techniques might provide different views of the problem.

Sprint planning best practices

It is easy to get so bogged down in the details of sprint planning you forget that the focus of sprint planning is to build a ‘just enough’ plan for the next sprint. That plan shouldn’t become a monkey for the team’s back, instead, it should focus the team on valuable outcomes, and allow guardrails for self-organization. A good sprint plan motivates everyone by defining an outcome and a clear plan for success. But be careful planning too upfront.  Instead of building the most complete, “every minute of the sprint is accounted for” sprint plan, focus on the goal and build enough of a sprint backlog to get started. Next, ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.

Scrum is a process framework aimed at solving complex problems. Complex problems require an empirical process (learning by doing). Empirical processes are very hard to plan, so don’t kid yourself--you can’t build the perfect plan. Instead, focus on the outcomes and get going. It does not have to be hard, even if the problem you are solving is.

Ready to start? Learn how to use sprints in Jira Software

Share this article

Dave West

Dave West is the product owner and CEO at scrum.org. He is a frequent keynote at major industry conferences and is a widely published author of articles and research reports. He also is the co-author of two books, The Nexus Framework For Scaling Scrum and Head First Object-Oriented Analysis and Design. Reach out to Dave on twitter @DavidJWest

How much time should be spent on planning and revising a document?

What are the 5 stages of writing process?

What are the 3 stages of writing?

What are the 7 stages of writing process?