What Not To Do During Product Backlog Refinement?

Great Product Backlog management ensures that the cross-functional teams are communicating effectively and maximum productivity is reached. Product Backlog Refinement also ensures that relevant items stay on the Product Backlog, and ambiguity and misunderstanding are eliminated among the members of the team. Product Backlog Refinement is an integral part of any product development and has to be religiously followed by organizations. A great Product Owner always knows how to refine the Product Backlog items and review the items regularly by discussing with some or all of the team members.

We may, however, add details to Level 0 items if we are sure that these items will not change going forward and/or are dependent on higher priority items. If epics need to be roughly estimated, then the t-shirt size estimation technique could be used. Most teams will choose to refine at least once per sprint using a method like Sprint Poker estimation.

It creates a shared understanding within the Scrum Team and the stakeholders around it. The Product Backlog refinement is a continuous process to create actionable Product Backlogs. This competence of the Scrum team is critical to creating trust with the management and stakeholders as it allows for the regularly delivery of valuable Increments. Refinement is a very effective way of risk mitigation in a complex environment.

Product Backlog

Backlog items being discussed by the Parabol team directly in GitHub. Maybe you have a healthy store of track ready to go and you know you won’t run out. Those pieces of track are the correct size, they’re well-defined and there are no imperfections. At each Sprint Planning meeting your team lays down an extra two weeks of track that get you closer to your end destination without compromising velocity. Your conductor already knows where this high-speed train is going because he/she has the trusty product roadmap in hand and has already charted a course. Adding detail helps teams form a better idea of how long a task may take to complete and what resources are needed to complete it.

The idea is to have someone there who can speak to why the item is being requested and how the solution fits into the business process. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. Common items on the definition of ready include acceptance criteria discussed and understood by the team, user story statement , dependencies cleared, and subject matter expert identified. Most people are familiar with the concept of Definition of Done, sometimes abbreviated as DoD.

product backlog refinement is the act of

This daily practice is especially important for the Product Owner, who holds overall responsibility for the backlog. As with all things in agile, reviewing the backlog daily isn’t a strict rule, but a guide. It’s natural to want to schedule backlog refinement at the end of the Sprint just like the other rituals.

How To Conduct Product Backlog Refinement

This helps you to avoid the scenario where the whole backlog refinement meeting is simply people trying to get back up to speed with what each ticket is about. In the spirit of the Scrum Guide, daily sessions build a habit of continuous refinement. It may seem rather daunting to have a backlog refinement session every single day. Estimating the effort of backlog items should always be done during your group discussions, since arriving at an estimate is a negotiation.

product backlog refinement is the act of

But creating a habit of daily micro-refinement, helps ensure all team members know what’s on the backlog and add detail when they have it. If you’re not sure how often to schedule a refinement meeting use this handy decision tree or read more about when refinement meetings should take place. While refinement is a continuous process, it’s important to have a scheduled time where you sit down together as a team and go through the backlog together. You can plan a Backlog refinement meeting whenever you realize that a Backlog needs revision. This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity. Agile Developer’s can fall out of sync sometimes when the objectives and outcomes change frequently just like any large-scale team project.

You can re-order, or you can collaborate with other teams to help resolve the dependency in advance. There are many options, and at the very least, you want the dependencies to be transparent. The goal is to balance gaining enough benefits from the activity while minimizing the potential waste. It never stops because requirements and opportunities never stop changing. Detailing everything up front would create waste and also delay the delivery of value. Developing new User Stories based on newly discovered information such as feedback to the product.

Scrum Training Classes, Workshops, And Events

Others do it continuously, and check in together once per sprint. You can think of the product backlog as the product roadmap expressed in small increments of work. If you need to slow down and add in some extra time for discussion. Choosing a way of refining your backlog is about finding what works for your team. When you’ve built a high Sprint Velocity, a once-per-Sprint refinement session might be the most time effective approach for you. When you are racing to ship at the end of the Sprint and can see your calendar filled with meetings, it can be pretty stressful.

  • This extends the “spread it out” advice to the individual product backlog items.
  • Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.
  • Known architecture, business rules and user-needs are articulated against the Product Backlog items.
  • The goal is to balance gaining enough benefits from the activity while minimizing the potential waste.
  • An Epic has been completed when every user story underneath it has been completed.

The objective of the item – how it will help a customer or user do their jobs. Identifying risks and obstacles for items close to implementation. Without ordering your Product Backlog in descending order of prioritization, you risk working on items that aren’t all that important, and missing important ones.

When refining a single item, don’t spend more than 15 minutes of the refinement session on it. Timebox your refinement of an individual item and come back to it at a future session. Even if you think you’re “done” refining an item, set it on the shelf and come back in the next meeting to be sure. PBIs that we won’t work on for some time should be toward the bottom of the backlog, larger in size, and less detailed.


Still, many teams like to use a meeting to quickly size user stories. An initial sizing for new stories, or a re-sizing for stories that have been refined since they were added. A good cadence of refinement, done right, will keep enough items in the product backlog that the team never runs out of gas.

It’s important to separate the dynamic act of backlog refinement from all team backlog discussions. A well-refined backlog makes the Sprint Planning process a lot easier because there are already well-defined items that can be pulled off the backlog to be built. Following Backlog Refinement and Sprint Planning, they are pulled off the ‘Backlog’ column and into the ‘To Do’ column for the next Sprint. Every backlog item has a user story that explains why it exists. User stories are essentially backlog items creatively expressed in customer-focused language. Items often become smaller as well, as some large backlog items are broken into multiple smaller items that are either more discrete or a more appropriate size.

The Keys To Effective Product Backlog Refinement

Backlog can be defined as a set of user stories which are not present in the current sprint that defines project’s scope context. The stories which are left unattended, may interfere with the functioning of the development team. The Product Backlog Refinement activity is one that many new Scrum teams struggle with. Insufficient PBR often results in long sprint planning meetings and incomplete backlog items at the end of the sprint. This article provides some tips on how to improve backlog refinement, which in the past was called backlog grooming.

Having an organized and detailed backlog helps teams make more accurate estimations of how long a task will take to complete. Refinement helps teams shape-up well-sized, detailed and discrete pieces of work that can be tackled in future Sprints. I usually start the ideation phase by creating a board in Miro and adding pre-made templates or creating my own. With an online whiteboard, even remote team members can actively participate by adding ideas, leaving comments and taking part in discussions. You’ve discussed the Goldilocks questions about refinement benefits with the Scrum Team.

Sharing information and views in this way helps the team arrive at a more accurate estimate that everyone can agree on. Sprint Poker usually takes place during your scheduled refinement meeting, when everyone Product Backlog Refinement is gathered together, in-person or remotely. T-shirt sizing gives teams the opportunity to break L or XL projects down into smaller and more manageable parts that are good candidates for the Sprint.

Every Stakeholder also has the responsibility to attend the Product Backlog Refining sessions. In Scrum Teams, usually, the Scrum Master facilitates the meeting, however, in other companies, a Project Manager fits perfectly for the job. The Product Backlog Refinement is groomed by the Product Owner such that the items on top of the Product Backlog are ready for delivery. Product Backlog Refinement occurs regularly which may be an ongoing activity or can occur regularly. At the lowest level, these PBIs can optionally to be broken down into tasks from a user stories and delivered by the end of a single iteration. In real Scrum, the Product Owner is the one that prioritizes the product backlog.

In the absence of explicit efforts aimed at managing this inflation, this inflation would result in the too well known pathologies of schedule and budget overruns. Backlog refinement is done in the current sprint, for future backlog items, not for those backlog items that are in the current sprint. Participants in the backlog refinement process include the entire development team, appropriate subject matter experts , the product owner or requestor for the item, and possibly the Scrum Master. Do not schedule backlog refinement meeting during the first and last 20% of the Sprint Planning session.

Scrum Framework is one of the frameworks that is widely used in many Agile organizations due to its simplicity and advantages it provides to the organization. Scrum has many principles and values which are integrated during product development and delivery that gives the product a superior quality. Hence, several industries have chosen to implement Agile in their organization through the Scrum Framework. Product backlog grooming often happens two to three days before the end of a sprint. Product Backlog items have the attributes of a description, order, estimate, and value.

ELMO is an acronym for “Enough Let’s Move On” and it helps remind people to avoid boiling the ocean or rehashing the same thing over and over. Some teams even find https://globalcloudteam.com/ it helpful to bring an Elmo doll to their meetings. I also recommend that the facilitator use a timer for backlog refinement, especially at the beginning.