The beginning of any software project is full of unknowns.

While it’s important to have a vision, the initial product backlog is little more than a list of assumptions that must be validated and refined using feedback from customers and users.

Grooming, or refinement, is the process of updating the product backlog based on feedback or changing requirements. For example, a team might remove irrelevant user stories, prioritize user stories, or create new user stories to keep the entire backlog relevant and up-to-date.

Let’s take a look at some best practices for grooming your product backlog to ensure your project’s success.

Best Practice #1: Add It to Your Workflow

Product backlog grooming should be a documented part of the software development workflow.

The process starts with collecting and analyzing feedback from customers and users. This data can be quantitative (e.g. statistical results from an A/B test) or qualitative (e.g. new feature requests from users). Either way, the goal is to identify how to build the right product that fits within the scope of the product roadmap and vision.

The next step is incorporating these insights into the product backlog.

For example, the team may add, remove, or edit various user stories or product workflows. If the feedback invalidates a core assumption, the team may need to adjust the wider product strategy, remove most or all of the backlog content, or even start over with a new backlog.

When the team is ready to start a new sprint, they must determine which new assumptions must be validated and/or what new functionality must be added. Then, the backlog items must be prioritized in a way that meets those goals.

It’s important for each sprint to have a well-defined purpose, and backlog items should be thoughtfully added to the sprint.

The final step is actually pulling the backlog items into the new sprint and verifying that each of them is clear, feasible, and testable from a development standpoint.

In some cases, it might also be necessary to resolve dependencies between various teams working on the same project to ensure that there’s nothing that could hold up development.

Best Practice #2: Make It a Collaborative Effort

Product backlog grooming should be a collaborative effort that includes product owners and cross-functional development team members.

[content_upgrade cu_id="5348"]Download our free short guide to running a product backlog grooming meeting.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]

After hearing about the business requirements, the development team must discuss the technical feasibility and risks, as well as ensure that everyone understands the purpose of each feature and how it should be implemented.

Behavior-driven development (BDD) is a great way to improve this communication by introducing a common language with concrete examples.

By starting with BDD, development teams can ensure that stakeholders and developers are on the same page before writing any code. It’s also high level enough that it can be easily adapted to changing requirements.

There are several components to the BDD process:

• Product owners, developers and testers meet for a discovery meeting where they discuss high-level user stories and come up with concrete examples of functionality.
  
  
• Concrete examples are converted into easy-to-read executable specifications written in Gherkin. These specifications are converted into step definition tests.
  
  
• Developers write the code to make these tests pass, using test-driven development (TDD) to test lower-level functionality, such as methods or functions.
  
  
• The high-level BDD tests become a form of “living documentation” where product owners can verify the status of functionality and easily understand what it accomplishes.

HipTest Living Documentation

At its core, BDD is simply an effective way to communicate requirements between business and technical teams using a common language. Tools like HipTest also add a common web interface that both developers and stakeholders can use to see both Gherkin specifications and living documentation.

Best Practice #3: Spend the Right Amount of Time

It’s easy to spend too little or too much time grooming the product backlog.

[content_upgrade cu_id="5348"]Don’t forget to download our free short guide to running a product backlog grooming meeting.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]

For instance, it’s easy for many developers to rush through these meetings while many stakeholders can quickly sidetrack the process with business concerns.

The Scrum rule is to allocate 10% of each sprint to grooming, which translates to one day for a 2-week sprint or 2 days for a 4-week sprint.

In practice, most experienced development teams spend just a couple of hours per week in a series of short meetings to refine the backlog. Short and frequent meetings can be much more effective than long infrequent meetings since there are more opportunities to address any issues as they arise.

Many Scrum Masters and other product leaders time box user stories to maximize efficiency.

For example, many teams spend about ten minutes per story or use techniques like planning poker to estimate story points even faster. User stories that take longer than ten minutes should be tabled for further discussion since they may be too complex.

The Bottom Line

Product backlog grooming is an essential part of the software development process. Since software is a moving target, it’s important to revisit your assumptions, make any adjustments, and ensure that everyone is on the right track to meet the customer and user’s expectations.

Behavior-Driven development is a great way to improve communication between business and technical teams to ensure that everyone is on the same page. This makes it much easier to groom the product backlog on a regular basis and ensure that everyone is moving towards the right goal.

Sign up for a free trial to see how HipTest can get your product and development teams on the same page through a common web-based interface and easy-to-access living documentation that’s always up-to-date.