Photo by Alvaro Reyes on Unsplash

Backlog Refinement and Sprint Planning: Similarities and Differences

Introductory note: You might be wondering why I’m taking the time to describe similarities and differences when it comes to well-known practices like Sprint Planning and Backlog Refinement. I felt the need to write this for both because it was helpful to a specific audience I was working with at the time, and also because this might be helpful to others in the Agile community who are relatively new to such practices.

Note 2: By writing this post, I am not saying that Scrum is the “best” approach for an Agile team. Some teams have realized improvement by using Scrum, not to mention other Agile approaches. There is no substitute for an ongoing process of introspection, experimentation, and improvement.

Similarities

Similarities between Backlog Refinement and Sprint Planning:

• Both seek to ensure that a team has a shared understanding about a particular body of work
• Both seek to engage and involve all attendees in the conversation
• Both are more likely to have successful outcomes if there is an experienced facilitator present, who guides the conversation, without pushing the team in a particular direction (most often, the facilitator is either a Coach or a Scrum Master)
• Both are more likely to have successful outcomes if there is a person present who can act as the “Voice of the Customer” (in Scrum, the Product Owner performs this function)

Differences

Differences between Backlog Refinement and Sprint Planning:

• Sprint Planning is one of the Scrum events, while Backlog Refinement has been referred to in the past as a “Generally Accepted Scrum Practice” (GASP) — meaning that it is a common practice on many Scrum teams. See also the Scrum Guide.
• Sprint Planning focuses on a short time horizon, while Backlog Refinement (can) focus on a longer time horizon: a. Sprint Planning, as the name implies, focuses on work the team intends to do during the upcoming Sprint, that is, the things that will be included in the Sprint Backlog; b. Backlog Refinement seeks to improve understanding of work items in the Product Backlog, some of which may not be worked on right away (it is important to keep in mind that the focus of Backlog Refinement needs to be on work items that are likely to be taken up by a team reasonably soon, for instance, over the next several Sprints)
• Sprint Planning is attended by the entire team, while in some instances, only a subset of team members attend Backlog Refinement
• Sprint Planning always happens on a particular cadence — at the beginning of the Sprint; while Backlog Refinement can happen on a variable cadence (for teams that have Backlog Refinement sessions, there could be one, or more than one, during any given Sprint, the timing of which is agreed to by the attendees)

Sprint Planning Overview

Below is a brief summary of recommended topics for Sprint Planning sessions.

• Sprint Goals. The team agrees on a set of goals that they think can realistically be achieved during the Sprint. (The Sprint Goals should be revisited during and also at the end of the session to confirm the team feels confident that they can be accomplished.)
• Sprint Backlog. The team takes a look at the Sprint Backlog for the Sprint that is about to end, and (as necessary) moves any unfinished work items, either to the next Sprint Backlog (because they plan to complete the remaining work during the new Sprint), or into the Product Backlog (because completion of that work is being deferred until later). The team also agrees on which Items from the Product Backlog they intend to work on during the Sprint, by moving them into the Sprint Backlog (in some cases, they might need to create new user stories during the Sprint Planning session; for teams that have Backlog Refinement sessions, it is less likely they will need to create user stories during Sprint Planning).
• Dependencies and risks. It is helpful to surface dependencies or risks that could have an impact on the work the team is planning to do during the Sprint.
• Assumptions. In many instances, it is helpful to capture any assumptions the team is making about the work they’re planning to do, such as the technical approach to be taken, or when it is expected that a different team, or a person on a different team, is going to handle a particular task.
• Out of Office. If this information is not captured in some other way, such as a shared calendar, it is helpful to capture any dates when a team member expects to be out of office during the Sprint.

Backlog Refinement Overview

Below is a brief summary of recommended topics for Backlog Refinement sessions.

• Backlog Refinement, IF it takes place, is normally around the midpoint of the Sprint.
• During Backlog Refinement, the most important topics include:
  a.) Revisiting the relative priority of upcoming work, and making sure it is clear which work is considered to be highest in priority; b.) Creation of, and/or refinement of, user stories that the team is most likely to work on next. It cannot be emphasize enough that the “work on next” aspect is important. The focus should be on user stories which are considered the highest priority, and which are generally going to be worked on during the next Sprint.

Well-formed user stories

For each user story, it is helpful to strive for a certain set of attributes. Here is a minimalist set:

• Title. The title, also known as the headline, should be very short, ideally starting with a verb, such as “Create login page.”
• Description. It is a common practice to start the Description using this format: As a <role/persona>, I want <feature/function> , so that <desired outcome>. The format is the least important thing to focus on, however. Clarity is key, no matter how it is achieved. It is also common to provide additional details in the Description, making sure there is enough information so that it’s clear what the intent of the user story is, without further conversation about it.
• Acceptance Criteria. Acceptance Criteria provide cues as to when the story is done. It is common to start each Acceptance Criterion with a verb, such as “Test that/verify that … <desired behavior/result>.
• (optional) Size. For teams that estimate the relative size of user stories, they should use the units that are most meaningful to them. As a guideline, a team should never work on a user story that is going to take more than half of a Sprint to complete. It is preferable to work on user stories that are expected to take no more than one or two days to complete.