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.
One of the most challenging aspects of adopting agile is requirements gathering and definition. The challenge is not because agile has complex methods for describing requirements, rather quite the opposite. Agile methods such as writing a user story on an index card and then relying on conversations between developers, product owners, and users to carry the story through construction might work for simple systems but breaks down when the domain or requirements are complex.
Product owners typically take center stage in driving requirements definition. These product owners, many of whom come from business units (rather than IT), cobble together various methods for capturing and communicating requirements. This is done without the benefit of understanding the difference between structured, object-oriented, test scenario-based, or other industry-standard requirements methodologies and why those methodologies came to exist. At scale, user stories on index card approaches break down, leaving team members and businesses as collateral damage. Please do not misinterpret this as Product Owner bashing – developers are just as susceptible to thinking that they can handle complex problems without the benefit of structure.
Enter the Business Analyst. When a team is responsible for solving a large, complex problem, the business analyst works with the users, product owners and developers to root out key information. For applications through which there are significant data flows, this could mean creating (gasp!) data flow diagrams. For a highly-interactive, event-based system, this could be use case models or sequence diagrams. A good Business Analyst possesses a skill set that many developers and product owners lack: the ability to understand the complexity of requirements and the best way to capture them.
One trap to avoid is to have the Business Analyst become the conduit (a.k.a. bottleneck) through which all communication between the users and developers occurs. This collaboration continues to be important and valuable, and the Business Analyst is involved to ensure important details are surfaced and consistent with the overall application.
- A formal Business Analyst skillset is probably not necessary for simple applications.
- For complex applications, the Business Analyst plays a key role in ensuring that the right software is built.
One of the most fascinating management challenges is determining the best structure for Scrum teams based on the stage of the project. This does not mean the major waterfall phases like Analysis, Design, Construction, etc. When developing software for use by customers (especially niche SAAS products) and there is some level of customization or specific features for each client, there are at least a couple of distinct stages in the project:
- Develop the base product
- Develop client-specific features and convert those clients onto the system as those features are completed
Many agile writings suggest that the way to approach system development is to develop some features and put them in production right away so that clients can start using them immediately. In reality, this does not always work. For example, when an existing system is being replaced, clients cannot be put onto a new system that only has 20% of the functionality of the one being replaced. Of course, this does not preclude some form of testing of that 20% by users within the development organization (e.g. by internal client service reps who are also part of the user base).
Organizing for Base Product Development
Typically the base product development effort focuses on developing the major feature areas. The development teams can be organized along the lines of the features areas as depicted below.
Organizing for Client Conversions and Onboarding
As the base product nears completion and the teams start to work on client-specific features, the portfolio or program manager may start noticing that the client code complete date for one of the feature teams above is much later than the other teams because the bulk of the customization for that client falls on that one team. The net result is client on-boarding dates are further out in the future that delay realization of new revenue from the product. This is a clear sign that the team structures need to change. At this stage, the focus shifts to optimizing staff utilization while retaining the benefits of teams building features or feature slices from top to bottom. This is called Focused Balance. Work is focused as much as possible on one or a few teams to gain the efficiencies that come with understanding and ownership of the epic , but when necessary client-specific epics are spread across the teams to deliver them as soon as possible.
Restructuring the teams
When scheduling and work allocation issues require that multiple teams work on the same epic, the following should be considered when deciding who should be on each team:
- Knowledge about specific feature areas of the system.
- Technical skillsets. Rebalancing may be necessary when certain feature areas from the base development phase emphasized a particular technical skillset.
- Technical leadership – most teams need a technical leader.
Cross-Training and Collaboration
Team members will need to step out of their comfort zones and learn other parts of the system. Product owners, who have become experts in the feature areas that their teams constructed in the initial stages of development, will be overseeing a backlog that contains features and stories that are outside of their current area of expertise. Recognizing and fostering the need for collaboration across the teams is critical to the success of this model. At this stage, the job of the product owner is to connect team members with subject matter experts rather than being the subject matter experts.
- Team structure may need to change to optimize the schedule for client-specific feature development.
- Restructuring and rebalancing evenly distributes system knowledge and technical skills across the teams.
- The Product Owner’s role changes to be less of a subject matter expert for their team and more of a facilitator.
Experienced agile practitioners take for granted that detailed requirements are captured as user test cases. For organizations transitioning to agile, this is one of the more challenging practices for them to adopt. Some product owners or business analysts still view the traditional “requirements document” as the way to capture detailed requirements. Because of their attachment to this traditional form of documentation, many resist replacing them entirely with User Acceptance Test Cases (UATCs). They view UATCs as additional work on top of writing their traditional requirements.
UATCs better convey a sense of how the system is supposed to work by using examples rather than abstract, ambiguous business rules. In a mature agile organization, the end users are best qualified to write the UATCs. This underscores the product owner’s role: they do not need to gather every detailed requirement – their job is to connect the development team with subject matter experts rather than being a conduit between the two.
Working Software over Comprehensive Documentation
Taken to the extreme, only the highest-level details are written down. This can work for small, simple applications. For large, complex applications, this is insufficient and quickly leads to chaos, disappointment, and frustration. The key is not avoiding writing down requirements, it is capturing them ONCE so that they can be used by product owners, developers, users, and testers and be the one living artifact besides the software.
What options do teams have for adopting the practice of capturing requirements as test cases?
1) Developers write UATCs – while some might consider this sacrilege, in reality this is a great way to get started with UATCs and establish collaborative bonds between the development team and the end users. Of course the developers’ initial version of these will usually only reflect what is in the acceptance criteria and what was discussed during grooming, but it provides structure for gathering more details from the users. Users quickly see the value in this approach because the requirements are written in terms that they can understand – system behaviors. They also see the value in working directly with the developers. Product owners like this because it does not add to their workload and they quickly realize the benefits of the enhanced collaboration. One caveat: developers may need coaching about expressing things as tests and expected results since they may also be accustomed to thinking in terms of catch-all business rules rather than tests.
2) Developers and users write UATCs together – given some starting point such as a sketch of a web page, the developers and users talk through the expected behaviors for a user story. This feels time-consuming but it directly involves the users in the process of devising the test cases.
3) Users write UATCs – while this is UATC nirvana, it is important to remember that the developers and users still need to review the UATCs together and in detail. The test cases and end product always benefit from each group’s experience and perspective.
4) Users and testers write automated UATCs – for applications that are able to leverage automated end user testing tools like Fitnesse, users will likely need assistance with the testing toolset, format, etc.
Be pragmatic about who writes the UATCs. Remember the goal: collaboration that leads to deep understanding of expected system behavior.