Scrum Events Product Backlog Refinement by Robbin Schuurman The Value Maximizers

Consequently, refinement is about creating alignment among all team members about the Why, the What, the How, and probably even the Who regarding the upcoming work for the Scrum team’s Product Goal. As a result, Product Backlog refinement is a critical success factor as it drastically increases the team’s capability to deliver valuable Increments regularly. The most important part of Product Backlog refinement actually is before you start refining. The most ineffective use of a Scrum Team’s time would be to refine an item that doesn’t contribute to the product vision. For a Product Owner, one of the first steps when a stakeholder has an idea is to find out what this person would like to have and why they need it. A common pitfall is that a stakeholder asks for a solution, the ‘how’, and a Product Owner in all it’s enthusiasm fails to retrieve what they would like to have and why they need it.

A UX Fishbowl consists of two groups and two steps, one group being the stakeholders and one being the Scrum Team. So, it’s all about the future work expressed as Product Backlog items in the Product Backlog.

The Product Owner adds detail to each « Must » and « Should » story, and the Epics containing those stories. There should be sufficient detail to enable the team to size the story. The Product Owner reviews the Product Vision with the team and they update the Product Vision, as needed. Sohrab is a long-standing Certified Scrum Trainer and CEO of the Scrum Academy GmbH based in Cologne.

While the Scrum Guide 2020 dropped the previous guidance on time allocation, it remains a practical rule that the Scrum Team should reserve up to 10% of its time for Product Backlog refinement. Wner does not consider the idea to be valuable, the stakeholder has two options, provide a better business case for the idea or just accept it just wasn’t a good idea to begin with. Our best advice for good Product Backlog refinement is to prevent everything to be discussed in Product Backlog refinement. Small enough, so the items should be small enough to get done within a sprint to comply with the definition of done. Create a graph using all items as nodes and with the dependencies arrows as edges.

How to Install Power BI – Guide to Getting Started

If you were expecting a blueprint for a ‘ready’ item you clearly need to do some homework on agility. When an item is ready depends on many different aspects like experience of the Scrum Team or knowledge about the product. It even differs per item when a Development Team considers it to be ready. This activity takes time and doing this right saves a lot of time in Sprint Planning. If there is no agreement on the size, the Developers engage in a conversation over differences and re-estimated again .

It also matters that the team fully understand what needs doing, why it needs doing, and how to potentially deliver that solution. The description of a product backlog item generally does not change once it is defined. However, at times it may be required to elucidate the PBI by describing it in a more detailed manner. This may be necessary when PBIs having seemingly similar descriptions are to be added in the backlog.

Do you want to create valuable product backlog?

The biggest challenge for the Scrum Master in Product Backlog Refinement is to make sure everyone understands the challenges of refinement. The most important first step in this is to create transparency on all levels and teach where needed. The answer to “who attends/” is “The scrum team decides.” Who are the people needed to be able to move refinement forward on the items being discussed? If you don’t have enough gas before a trip you could end up stranded on the side of the road. Product Backlog Refinement is not for PBIs selected for the current Sprint; it is for items in future Sprints. A good practice is to have at least two Sprints worth of work ready to go in the Product Backlog.

A word of warning, some teams have figured out how to slice items, they tend to slice up beyond the point it being necessary to make an item smaller. This is the time where a Scrum Master of Agile Coach should intervene and explain the team the purpose of slicing. After the point where the blue line crosses the black line, the quality of the discussion will start to deteriorate. When working in complex domains, where empiricism is applied, there are more things unknown than they are known. This means that spending too much time discussing the items at hand, is the same as trying to look in a crystal ball.

In addition to the product owner and the development team, the Scrum master and – especially in the case of strategic refinements – stakeholders take part in the refinement meeting. A good cadence of refinement, done right, will keep enough items in the product backlog that the team never runs out of gas. As a Certified ScrumMaster® or Certified Product Owner®, shoot for always having 1.5 to 2 times the amount of work ready than can be done in a sprint, based on the velocity of your team. Smaller, more specific refinements save time for stakeholders and subject-matter experts.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive.

Timebox des Product Backlog Refinement Meetings:

Creating a Definition of Ready to act like a stage gate (“we have to have all the boxes checked before pulling anything into the Sprint Backlog”) is shooting yourself in the foot. If there is sufficient information available to start working on a certain PBI, and you’re fairly confident you can pull it off in a single Sprint, you’re pretty much good to go. You want PBIs to be small enough that a Development Team can complete more than one in a Sprint.

For the product owner, it will be easy to get the conclusion over the queries, by asking these questions in the early stages. 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.

Estimate anything new to assess potential risks and identify possible spikes to run in the next sprint to increase learning and mitigate the risks. Ague items being brought into Product Backlog refinement and the Development Team getting caught up in discussing any possible solution are signs of refinement gone wrong. Such discussion are consuming the energy of everyone in the meeting, including those involved in the discussion.

Product Backlog Refinement: How to Succeed as a Scrum Team

If everyone agrees on the size and an item doesn’t need to be broken down further, you can proceed to sprint poker to arrive at a more precise estimate and have a more refined discussion. When I work with teams struggling with their refinement, I suggest the practices above as a minimum. A team can take this further (and should!) by employing practices such as establishing WIP limits, managing and measuring flow, and implementing feedback loops. But in my experience, the practices above alone have delivered vast improvements for teams and their refinement processes. Begin to review your upstream board along with your downstream scrum board in your daily standup.

The normal motivation for an overall PBR event is when the group may want to divide related items into two major subsets and have four teams work on one subset, and another four teams work on another subset. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them.

If you can’t come to a resolution or agreement on a specific item or issue, move on and address it at a later stage outside of the backlog refinement meeting. Product owners often forget that the development team speak a very technical language but don’t always speak the business language or understand the business https://globalcloudteam.com/ objectives behind the work that needs doing. As a scrum master, you are going to help them with that communication. In preparation of the Backlog Refinement , the Product Owner should remove user stories that are no longer relevant and create new ones based on the Scrum Team’s discoveries from the previous sprint.

Scrum Events — Product Backlog Refinement

To start, it assures the Product Owner properly conveys the project / product objectives to the Scrum Team that will inform the sprint goal. Further, it ensures the Product Backlog remains populated with user stories that are relevant and detailed. Finally, it defines the “feature set” for the next Sprint Backlog; user stories that are appropriately refined, estimated, prioritized, and meet the Definition of Ready . So, while I encourage scrum teams to refine continuously, I also recommend regularly timed refinement sessions within each sprint. Assigning an estimation is not the same as getting an item in a ready state. Product backlog refinement would be a lot less difficult and time-consuming, if everyone involved agrees that an estimation is by default incorrect.

• Hopefully, this post has provided you with some ways of improving the efficiency and effectiveness of Product Backlog refinement.
• Backlog refinement is about creating shared understanding on what the Product will, and won’t, do and on what it will take to create it.
• Backlog refinement meeting should be considered as the first part of Sprint Planning.
• As a scrum master, you want to be asking questions that help people to understand the nature of the task and why it matters.

That is why refinement is an essential Product Management activity that successful Scrum Teams need to master. You need to invest time with the product owner and help them understand the importance of a healthy backlog. You need to have conversations with them around the backlog items to help clarify their thinking around the item and help them articulate why the item matters to customers.

Product Backlog Anti-Patterns at Portfolio and Product Roadmap Level

You can use planning poker or any other methodology for sizing that the team have agreed best works for them. Do a quick group estimate where each individual presents their estimate and you are good to go. As a scrum master, you may find that the conversation has led to it’s natural conclusion and the next step is to estimate the size of the work involved. A group of talented, creative, and professional individuals collaborating around product items that are incredibly important to customers and product stakeholders. Streamline your workflow, collaborate better with teams and implement best work practices. ProductsFollow scrum framework rightly and get your team on the path of continuous improvements.

When Scrum Teams are asked to guess product needs, customer behavior, and product-market fit, they are often doomed to fail. Organizations can change this by empowering Scrum Teams as problem-solving teams, not feature delivery factories. Refers to these items as reminders of conversations that need to happen in the future.

📺 The Product Backlog Anti-Patterns Webinar

As new discoveries are made over time, include them in the backlog or its product risks becoming obsolete. The Interviewer asks questions that the audience would be expected to ask, like a general description of the product backlog item, expectations, limitations, etc. The Product Owner invites a “celebrity” deep backlog (an end user, subject matter expert, Product Owner, etc.) to the backlog refinement. Someone on the team should be chosen as an “interviewer.” Agree within the team about who will document questions and answers. This extends the “spread it out” advice to the individual product backlog items.