In Scrum, How to Get the Most Value From a Backlog Grooming Meeting

If you're not familiar with Scrum, it's a project management framework under the agile methodology usually used to manage the creation of software. Scrum consists of a group of meetings, called Scrum ceremonies. The required meetings are the Daily Scrum -- usually called the Daily Standup -- Sprint Planning, and the Retrospective.

Backlog Grooming -- also called Backlog Refinement -- is an optional meeting that a Scrum Team can add to their ceremonies if they so choose.

What Happens in the Backlog Grooming Meeting?

This meeting is where the development team has an opportunity to provide technical details and story points for user stories (more on what stories and points are later) or create new user stories for the next Sprint.

For more complicated technical projects, it's often the case that a development team will need to be engaged to provide details on technological approaches, dependencies, and providing some initial architectural design. This engagement happens most often in a Backlog Grooming meeting.

The agenda for this meeting is simple -- you start at the top of the backlog and groom user stories until the meeting is over. (Details on what grooming a user story entails are coming.)

Does Your Team Need This Meeting?

The Backlog Grooming meeting is an optional ceremony of the Scrum process, which means that holding this meeting isn't a foregone conclusion. But how do you know if your team needs this meeting? Answering this question is more art than science, but there are some benchmarks that you can use to help make the decision.

• How advanced is the technology solution that your team is building?

  The reason this is a benchmark is that the simpler your solution, the more likely that a Product Owner -- the member of the Scrum Team responsible for creating and prioritizing the stories -- will be able to write complete requirements into user stories. (Again, more about user stories is coming.)

• How technically knowledgeable is your Product Owner?

  If the Product Owner used to be a software developer, or has a strong knowledge of highly intricate technology solutions, then chances are they can create requirements for user stories for even the most technically demanding set of requirements. If that's not the case, you may need the development team to get involved.

• How much time does the Product Owner have to devote to creating user stories?

  This question must be considered with the answers from the first two benchmarks, but it's still important on its own. If your Product Owner doesn't have the time to devote to creating and defining user stories, it will fall on the Scrum Master to schedule working sessions to make that happen. And guess what? The Backlog Grooming meeting is the perfect forum for doing that.

• Are you regularly running out of time in your Sprint Planning meeting to properly execute the planning?

  In a Sprint Planning meeting, you should have time to do all the same user story grooming that you would do in the Backlog Grooming meeting. Because of this fact, if you're finding that this grooming work in the Sprint Planning is taking up a lot of time, that may be an indicator that you need the Backlog Grooming meeting.

  Also, consider that if you're running out of time in the Sprint Planning meeting, you're probably not able to fully define the user stories so that developers can immediately start working on them. This means the developers are using precious development time seeking definitions on their own.

  Those four benchmarks will quickly help you determine if the grooming meeting is necessary, but make sure that you're involving the team in this decision. You'll need their buy-in to have successful Backlog Grooming meetings. If you're a Scrum Master, you probably know that owning the Scrum process is your bailiwick, but pulling rank is often not effective when you want to get high-quality results from your team. Because of that fact, only do that if you've built a significant amount of trust so that your team can absorb the hit of your unilateral decision.

When to Hold the Backlog Grooming Meeting

So you and your team have decided to have a grooming meeting. Great! That discussion probably ended with when to hold the meeting, or at the very least, you're asking yourself that question.

There's really no perfect answer, though. Though it does seem to be most effective when held in the middle of a Sprint, looking ahead to the next Sprint. By this time, your team has a good idea about where the user stories in the current sprint are going to land. (Will they be complete? Will they carry into the next Sprint? Etc.) They will also have a better idea about what kind of technical considerations to bring to future user stories by that time.

Holding the meeting soon after the start of a Sprint might not give the team time to learn what they need to from the current Sprint's user stories to answer the questions that are needed to properly groom a story.

If you hold the Backlog Grooming meeting late in a Sprint, it might be too close to the planning meeting and take up some of the most critical time for the development team: The last few days of a Sprint.

Despite these facts, there's no hard and fast rule. Schedule the meeting when it's most effective for your team, in your environment.

What is a User Story?

All this talk about user stories -- if you're not familiar with them -- probably has you wondering what they are and how they are used in the Scrum process. Well, wonder no longer.

User stories were created when the team that developed Scrum realized that the way software work had been defined historically wasn't useful for the end user. They thought that describing how a user would actually use a piece of software would be the most effective way to define the work to create it. That format is:

As [A CERTAIN TYPE OF USER] I want to [DO THIS THING] so that I can [ACCOMPLISH THIS RESULT].

A real-world example might be: "As an automotive tech, I want to be able to search the parts list so that I can tell if we have certain parts in stock."

You may have already concluded that a user story doesn't cover specifics, and that's on purpose. It's not designed to be specific, it's designed to communicate a certain outcome for the users of a piece of software. Said in another way: It's meant to tell a user's story.

What Is a Task

After talking about the generalized nature of user stories it's reasonable to assume that the details and specifics necessary to build a software feature still need to be documented, tracked, assigned, and worked on. That's where tasks come in. Once the user story is defined, the development team begins to outline the necessary tasks to complete that user story.

The titles for tasks don't have the same prescriptions as user stories. In fact, tasks can have titles like"Create the backing SQL database." This is an important point because this type of work must be tracked and completed, even though it doesn't fit neatly into the user story format.

Tasks are each given definitions that describe what it means for that task to be done -- also called the Definition of Done -- and as these tasks are created and defined, it begins to bring the effort of the story into view for the developers, who then must put a number to that effort estimation called story points (more on these later).

Epics and How Teams Actually Track Their Work

Sometimes a process is developed by experts who have great ideas about how to better track work but when those processes are implemented, there are still unconsidered aspects of the process that get identified. So, it was almost inevitable that a Scrum team would come across a user story that was too large to be completed in a single sprint. That wasn't until 2004, when a man named Mike Cohn wrote his book, "User Stories Applied for Agile Software Development," that the term "Epic" was coined.

Initially, the concept of an epic was to have a formal definition for those larger stories. For many Scrum teams today, however, epics are used in a much different way.

Many Scrum teams use epics in one of two ways:
1) Epics are used to define large initiatives, sometimes spanning entire quarters or longer, or
2) in place of a user story.

How Do Teams Actually Document Work?

Epics spanning quarters or longer fit with the intention of epics as Eric Cohn defined them, even if they define larger initiatives that he may have envisioned. However, many times epics are used in place of user stories. When this is the case, user stories become synonymous with tasks, and tasks become subtasks.

There are many reasons for this, but it's usually an artifact of the kind of organization or team that switched from the process they had been doing to Scrum. For example, if the organization was/is a support organization, user stories tend to be referred to as tickets.

While it's important to understand the intended definitions, it's also important not to get caught up in those definitions. All that's important to understand is the hierarchy of the Scrum work breakdown structure:

• Epic/Initiative

• Task/Subtask

• User Story/Task/Ticket

• Subtask (if Tasks are used synonymously with subtasks this level is often omitted)

The ways that the use of these terms has changed over the years is the reason that you must consider that there is Scrum on paper, and then there's Scrum in the real world.

Definition of Ready vs. Definition of Done

You have an idea about what the definition of done is now, but there is another related term that should also be considered. That's the definition of ready.

The definition of done describes the aspects of a user story that need to be in place to be considered done. The definition of ready describes the things that need to be in place in a user story to consider it ready for a developer to start working on it.

The risk of holding too strictly to a predefined definition of ready is that a development team can get lost in the details, never starting work for fear of not having defined a story in excruciating enough detail. To help with this, use the following set of items as the requirements for the definition of ready, and it will help to mitigate a team getting caught up in the details before work:

• The user story has a detailed, yet succinct title
• The user story has a definition of done with enough detail that a developer can start working on it
• The user story has points

When grooming user stories, knowing when you're done is as important as knowing when a story is ready for work. Now that you have a clear way to know both, you can differentiate well-defined user stories from poorly defined user stories.

How to Document Technical Considerations

There is a fourth category of the definition of ready that may be important to define but isn't strictly required, and that is the technical considerations. This can define anything from the technology to use, the programming language to write in, or the system architecture that's in place. The point of this category is to make sure that technical considerations that are required for a user story are considered before work starts.

• The Rough Waters of Story Points

After all this, it's time to talk about story points.

Simply put, story points are numbers given to a story to define the effort involved in implementing the story (often using the Fibonacci sequence for points). The important distinction to make is that story points are not a 1:1 replacement for time. While time is an important consideration in assigning story points, it's one of many.

The next thing to consider about story points is that they are not predefined. The reason this is the case is that each story may have different kinds of requirements that are unknown, require different solutions or architecture, or require interaction with different stakeholders. When you take these things into consideration, it becomes more clear why attempting to predefine the story points quickly devolves into a 1:1 replacement for time, as it is the only consistently definable aspect of points.

All this begs the question: How do you define story points?

That's the question that must be answered so that story points can be used, but the answer is as unsatisfying as it is ambiguous. That answer is that the Scrum Developers collectively come to an understanding of how they define story points through pointing exercises over time.

This means that teams (and it's important that the dev team collectively assigns points, and no one else is allowed to tell them what a point is) have to go through a pointing exercise. This is often called planning poker because, historically, it has involved developers sitting around a table and holding up cards with numbers on them.

The more often the team does a planning poker session and then spends a sprint working on user stories and tasks that they've pointed, the more narrowly each team member will define points for stories in the future. Team members will also start defining user stories with the same point numbers more consistently.

You know that the team has settled to a collective understanding on point values when the entire team regularly selects the same number the first time they select points together.

• Story Pointing Sessions

What this all looks like in practice is that a team will talk about a user story, its definition of done, and its technical considerations. Once everyone on the team thinks they understand the effort, each person chooses a number then everyone shows their numbers at the same time. (That's important to avoid premature influence on each person's chosen number.)

If the team doesn't hold up the same number, a conversation ensues where each team member talks about why they chose a particular number. Once the conversation is over, everyone chooses a new number. It continues like this until everyone agrees on the same number.

It's fine if the team starts making some concessions throughout the conversation and comes to an agreement without choosing new cards, but when this happens, make sure that voices in the team are not being silenced by stronger personalities or more forceful people.

Again, it can't be stressed enough that while time is an important consideration when it comes to story points, points are not a direct correlation to time.

• Atypical Pointing

Because story points aren't directly correlated to time, and because they are purposefully designed to be somewhat ambiguous, it's possible to use things other than numbers to define effort.

This could literally be anything from t-shirt sizes (small, medium, large, extra large) to animals (mouse, dog, horse, elephant).

It really doesn't matter what your team decides to use. What matters is that the team is making the decisions.

When Is the Backlog Grooming Meeting Over?

The term time-box is used to describe putting a time limit on a task, and it's a perfect way to describe how to know when the story grooming meeting is over.

Either you've run out of time or run out of stories to groom, whichever comes first.

In either case, that's how you know the meeting is over.

Preparation Is the Key to Success

It's true that this meeting is not required in the Scrum process, and you may find that you don't need it. However, you should only forego this meeting if there are comparable levels of grooming happening in some other forum.

There is a clear difference between trying to accomplish a goal without any preparation and trying to do it after skillful preparation. If you follow the directions that have been outlined above, your team will be well on their way to high performance through levels of preparation that will set you apart from your peers.