Category Archives: Grooming
Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.
What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.
Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.
Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.
How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.
For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.
Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.
What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.
A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.
The PO typically runs the grooming meeting.
What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.
What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.
- Backlog grooming is an essential activity. Resist the temptation to skip it.
- Schedule grooming meetings so that they fit In the middle of the weeks of the sprint.
- The entire team should be involved in grooming.
- Regular backlog grooming helps the PO establish a cadence for working on stories.
As organizations adopt agile practices, there are several key skills that differentiate high-performing teams from mediocre teams:
1) Working in short timeboxes
For a team that is accustomed to delivering working code every six or eight months, two or four week long iterations can be unfathomable. But doing this is essential to the success of the project in order to get the benefits of continuous code integration into a testing environment and frequent user feedback. The sprint’s timebox forces the business stakeholders to constantly question the scope of each feature at a micro level and decide when to carve out functionality.
2) Splitting work into small pieces
The most common excuse for teams wanting to plan sprints using large user stories is that it is “more efficient” to do all of the coding work together and test it at the very end or in the next sprint. This perceived efficiency is self-deception. Successful agile teams know that they must put working code in front of their users early and often. Remember the old saying that “users often don’t know their requirements until the software fails to meet them?”
3) Communication and transparency
Old-school silos between IT, Product/Marketing, and business operations groups are an agile anti-pattern. Political games, finger pointing, and one-upmanship are a huge waste of an organization’s resources and energy. A grown-up culture of transparency allows all of these players to collaborate and solve difficult challenges. For the Scrum Master, this means posting project information in high-traffic areas of the office. More importantly, it means being open with stakeholders about the challenges that the team or project is encountering. Team members can feel secure speaking freely about impediments and project risks in a public forum without fear of reprisal. The essential skill here is knowing how to voice issues in a way that does not sugar-coat them but does set the stage for a constructive discussion.
4) Swarming, collaboration, team first
“Your side of the boat might be leaking but my side is fine” attitude just doesn’t cut it anymore. Lone gunmen need not apply. The most effective agile team members will gladly work outside of their skill sets and comfort zones if it helps the team succeed. Agile developers welcome and seek opportunities to discuss functionality with end users to understand their goals and needs. They leverage techniques such as User Acceptance Test Cases to capture and understand detailed requirements.
5) Focus and finish mindset
This is another one of those things that is counter-intuitive at first for people new to agile. Coders are used to getting all the coding tasks done so that they can get all of the stuff to the testers. Understanding that high work in process = low throughput is key. Developers working in lockstep with testers results in higher throughput, even if that means that the developers have to swarm on non-development tasks every now and then.
6) Scope negotiation
Scope negotiation means being relentless both when talking about items in the current sprint or when doing release planning. Sometimes it takes two, three, or four conversations about an item to admit that it is not really needed.
7) Talking about requirements at the right level of detail at the right point in time
Skilled agilists recognize that the conversation that happens in a user story writing workshop is at a much higher level than the conversation about a story right before that story is pulled into a sprint. They also shun detailed requirements until the sprint starts, knowing that a large collection of detailed requirements is inventory that is subject to decay.
8) Automated testing
Refactoring is a fact of life as requirements are progressively elaborated. Effective implementation of test-driven development and automated testing blunts the effort for regression testing as the application evolves.
A mature agile team intuitively knows what a story point means in terms of the relative size of a user story compared to other stories that it has sized in the past, but how does a new team that perhaps even has people who are new to agile get started with story points? As I mentioned in another blog post, Ideal Days is a story point estimation scale that blends size with effort and degrades the backlog sizing process into a drawn-out time estimation exercise. Given that a points scale like the Fibonacci sequence that relates more to size/complexity is preferred, how does a team get started when it does not have a baseline story against which to do relative sizing?
A few things should be in place to set the stage for establishing a baseline story:
- Definition of Done. This should include quality assurance and user testing.
- Sprint length. Should be no longer than two weeks.
- Understanding by the team that high throughput is achieved via low work in process, i.e. having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint.
Once there is a set of stories in the backlog that are small enough to pull into a sprint, the next step is to discuss and assign story points. In asking the team to assign story points for the first time, I usually tell them something like this:
Team, we know that in order to meet our sprint goals we need to get the first story in this sprint coded, unit tested, and into QA by the second or third day of the sprint. Let’s call that a three point story.
With that in mind, the team sizes the first few stories. Some might argue that we are just using Ideal Days. We are not, because executing and supporting the QA and user testing efforts are not included in the goal of getting the story to QA by the second or third day of the sprint. The other reason we are not using Ideal Days is because we only use this method for sizing the first couple of stories in the backlog. After that, all estimations are done relative to those first couple of stories that were sized, by asking whether or not a story feels bigger or smaller than those stories.
- Establish the Defintion of Done, sprint length, and concept of high throughput via low work in process before sizing stories.
- Size stories with the goal of getting the first story into QA within the first few days of the sprint.
Sizing user stories is a key part of understanding the overall effort required to create a product release. Getting started is simple: pick a baseline story and assign a number of Story Points or Ideal Days that it will take to complete the story. Next, look at other stories in the backlog and decide whether or not they are bigger or smaller than the baseline story and by how much. Lather, rinse, repeat.
Developers coming from waterfall teams are accustomed to doing time-based estimates. Junior or intermediate level developers were usually asked to estimate functionality that was well-understood and broken down into small units of work. But in waterfall efforts, sizings done during project inception were probably done using a high-level estimation technique such as function points by a more senior analyst, lead and/or architect. Agile user stories are not necessarily well-defined or split into small stories the first time that they are sized (they will be by the time they are brought into a sprint plan). Because of this legacy of thinking in terms of hours to build, developers often revert to using a time-based estimation technique when trying to size user stories.
Before we go any further, some quick definitions:
Story points: a points scale (possibly using the Fibonacci sequence – 1,2,3,5,8,13,21,etc.) that indicates the size of a story relative to a baseline story.
Ideal days: the number of days of effort that it would take the team to get a story done if the team worked with no interruptions.
Once the team has sized the baseline story, it is ready to start comparing other stories to it and assigning points to them. But along the way, developers may develop an ‘algorithm’ for assigning Story Points. You know they have done this when one of them says, “I think that story will take 8 hours, so it’s a two-pointer.” What is happening is that the developer is doing a time estimate of their effort and reverse-engineering the story points rather than sizing the story relative to other stories. This is when the ScrumMaster needs to remind the team about the goal of sizing stories and why Story Points are a better approach than a time-based estimation approach.
Story Points are for sizing, not for time estimation. This allows teams to:
- Quickly size features and create a release plan without getting bogged down in implementation details. Team members are often very reluctant to provide time estimates unless they have all of the details about a feature. Being agile means that it is okay not to have all of the details up front. Developers typically are more comfortable saying that Feature B is twice as big as Feature A knowing that they won’t be held to a specific time estimate.
- Use Story Points in conjunction with the team’s velocity to make delivery date projections that are not as prone to decay as those using story-level time estimates. Relative sizings based on Story Points are usually fairly stable; estimates based on time can change dramatically as a project unfolds. In conjunction with Story Points, velocity is a reflection the team’s productivity and expertise. This is much easier and more flexible than trying to bake size, effort, productivity, and expertise into one ideal days number for each story.
- Create sizings that include all of the effort to get a story to ‘done’. Story Points include development hours, user interaction design, QA testing, etc.
- Prevent stakeholders from using Ideal Days estimates to calculate unrealistic delivery dates which are then mandated to the team. It is not their call how many hours per day the team spends actually working on user stories. They do not have a sense of how the mix of skills on the team or other factors will impact productivity. It is up to the team to determine how much time it can spend working on stories, and how much time it needs for grooming the backlog, doing production support, etc.
- The team should size the backlog without having deep, detailed requirements conversations.
- Story Points are a way to size features without having to calculate how much time it will take to do the work.
- Story Points are less prone to decay than Ideal Days.