This article is part of a series on Scrum fundamentals, complete with infographics! Check out the rest of the series: What is a Sprint?, What is the Daily Scrum?, What is a Sprint Review?, and What is a Sprint Retrospective?.

There are quite a few misconceptions and misunderstandings in Agile. For example: “In Agile, there is no documentation,” “An MVP is a complete product,” or “If we are agile, we do not plan.” The latter is born from twisting one of the Agile Manifesto values, which says:

Responding to change over following a plan.

But, if you read just below the values, you will see: “That is, while there is value in the items on the right, we value the items on the left more.” Following a plan has value, but not as much as responding to change. I am not quite sure how this became “no planning”. Agile frameworks actually devote a lot of time and effort to planning – that is, within a context of the guiding principle that everything is flexible (which is what “agile” is).

Scrum meets this premise. While the Scrum Guide offers a means of responding effectively to changes that arise during development, it also places importance on planning by defining it as one of five Scrum Events.

A Guide to the Sprint

We have already seen that the Sprint is “the heartbeat of Scrum, where ideas become value.” To minimize uncertainty and give relevance to value creation, Scrum defines a series of fixed meetings or events that occur at predictable times and whose mechanics are known. Planning is the event that marks the start of the Sprint.

For the increasingly simplified 2020 Scrum Guide, the Planning event serves to “lay out the work to be performed for the Sprint.” The plan that is developed is the result of the entire Scrum team’s collaborative work, not the masterful idea of ​​a single person. The entire team participates actively, and for that reason it is assumed and not imposed.

The Planning event ends with a Sprint Goal, which will guide everyone’s work. It is the goal towards which the efforts are directed, the purpose that guides the team during the Sprint, and the way to convey the added value.

Planning Event Structure

The only guidance on time is that Planning should be, “timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.” While it may be tempting to make an easy rule of thumb between weeks and event hours, it isn’t necessarily a good idea.

Although it is common to hear that Planning is a “very long” meeting, the importance of spending adequate time for planning the work to be carried out throughout the Sprint (by a group of up to 10 people) should not be overlooked. In the worst case, we are talking about dedicating 5% of the total time for a typical Sprint to prepare for it properly. Skimping here leads to flailing blindly at work, to endless daily meetings, and, although it seems contradictory, to losing the ability to adapt by not having an adequate plan by which to guide the team.

3 Planning Topics

The Scrum Guide tells us that there are three main topics to be addressed at the event:

1. Why is this Sprint valuable?
2. What can be Done this Sprint?
3. How will the chosen work get done?

But there is little instruction on how to do it. Traditionally, planning has been divided into two parts:

1. To define the scope of the Sprint from a business point of view
2. To do a detailed analysis from a technical point of view

The structure of the Planning event does not necessarily have to follow this tradition. The important thing is to not lose sight of your objective and end with an answer to each of the three questions posed above. The Guide intentionally leaves a lot of leeway to the team.

Value

The first question is answered with the Sprint Goal. The goal gives a purpose, a unique, shared guiding star that is an intrinsic motivator for the team.

The objective is not necessarily defined in advance, although the Product Owner (or PO) can make an initial proposal of how to add value to the Sprint. Throughout the session, the team will end up answering this question and will be able to solidify the Sprint objective.

Scope

The second topic of, “What can be Done this Sprint?” requires the PO and Developers to jointly select the Product Backlog elements that they want to address during the pending Sprint. If necessary, the elements selected will need to be refined to obtain more information on their nature and implications, and thus fine-tune planning occurs.

The critical question here is, “How many items can be addressed in the Sprint?” There are numerous estimation techniques (such as Weighted Shortest Job First or Planning Poker), but Scrum leaves it up to the team to decide on the most appropriate for them. What I can definitely say, though, is that the experience gained in previous Sprints will help to refine the estimation for the current sprint: #AlwaysLearning.

Plan

The third question requires developing a work plan. To get there, it will be necessary to divide the elements of the Backlog into smaller units, ideally into units that require a day of work or less. Developers, as knowledge experts in this domain, are usually the ones who define how to convert the elements that define the scope into final value.

Scrum Planning Responsibilities

As we have said, the entire team attends the Planning event: Product Owner (PO), Scrum Master (SM), and Developers (so-called, even though their work activities don’t necessarily involve software). In addition, other people who provide subject matter expertise could participate.

The PO has a prominent role since they are the one who suggests the initial proposal of the objective, who contributes the point of view from the business on behalf of the stakeholders, who has the power to prioritize, and who is, ultimately, the person who negotiates the scope and plan with the team.

This requires fluid communication between the PO and Developers in a safe environment that allows for a constructive conversation with freedom to propose alternative proposals and visions.

During planning, it is natural for tension to emerge between the desire to deliver more on the part of PO (business voice) and the reality of the team’s capacity, its context, the unknowns, the history, or the accumulated debt at work. Making the process productive, fluid, and frictionless is in everyone’s hands, but especially in the third attendee’s: the Scrum Master.

The final result of the Planning event is the Sprint Backlog, which contains the selected elements to be translated into value during the Sprint. There are also two less tangible results: the assurance that the Sprint Backlog we will meet the Sprint objective and that the plan will guide the team to reach it.

After Planning, the Sprint itself begins, in which the collaborative work that the team decided on in Planning takes place.

Infographic: What is Scrum Planning?

Download our full infographic use to use as a reference for your own Scrum Planning.

(And, don’t forget about our companion infographics – What is a Sprint?, What is the Daily Scrum?, What is a Sprint Review?, and What is a Sprint Retrospective?.)
Gracias,
– Alonso

Beyond Scrum Planning

Dig in to Scrum in our Agile Fundamentals course. Learn all the terminology, ceremonies, principles, techniques, and day-to-day application of Scrum. (And, earn your ICAgile ICP certification!)

Course Outline