27 Product Backlog and Refinement Anti-Patterns

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.

A 20/20 vision of the order of the Product Backlog is created, which shows what is important to stakeholders. To encourage stakeholders to collaborate, the price of some items should be high enough that no one stakeholder can buy them alone. With the total amount of money, it should only be possible to buy half the items.

What does the backlog refining activity consist of?

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.

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.

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.

If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Remember, a backlog refinement meeting is not a one way communication from the product owner to the development team around what needs doing and when it needs to be completed by.

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 .

Who should carry out the refinement activity?

Make sure everyone understands that Product Backlog order is not final until a PBI has been accepted into a sprint. In your everyday practice, you might also know Product Backlog Refinement as just “Refinement” or “Backlog Grooming”. Beware that these, and other similar, names are all only used in your everyday practice.

In Scrum, scope is estimated in relative units of measure such as Story Points. There is a tremendous transfer of knowledge as the PO gives the team more and more context about customers, business model, etc. through the Refinement. In this article, we will show you exactly what Product Backlog Refinement means, what you should pay attention to and why refinement is so important. Agile Leader Agile Leader Journey Learn more about agile leadership and find out how to take your company to the next level.

Follow the 15/5 Rule of Discussion

But please, promise me that you’ll continue to invest the time to do proper refinement in order to make your product thrive. You’ve discussed the Goldilocks questions about refinement benefits with the Scrum Team. (Sprint Retrospectives are a great opportunity to regularly have these conversations.) Now it’s time for the Scrum Team to decide how to adapt their process for Product Backlog refinement. There is a reason these are open questions and not simple yes/ no questions. The resulting graph provides insights that enable the Scrum Team to eliminate dependencies.

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.

Always have various skill sets represented in the conversations from analysis, development, and testing, etc. to avoid misunderstandings and ensure everyone is on the same page in terms of the work ahead. There should be no major surprises in sprint planning as most items being planned should already be familiar to the team via the refinement activities. A well-maintained backlog will prevent sprint planning meetings from lasting an unnecessarily long time. Product backlog refinement is sometimes called product backlog grooming, and we will use those terms interchangeably in the article. Consider NOT managing the upstream work on a sprint-by-sprint basis.

Tips for Improving Product Backlog Refinement

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. Often, Scrum Teams come together once per Sprint, or once per week to have their “Refinement Meeting”. The Product Owner shares what Product Backlog items need to be refined and the whole team discusses them. After the discussion , the planning poker cards are drawn to give an estimation to the PBI .

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.

This sounds incredibly valuable and any developer would like to spend time on this over working on some legacy application. However, when the reasons behind the solution are unclear it will most likely end up somewhere hidden in the app store. Asking direct questions like ‘what capacity will that backlog item require? ’ allows the team to talk through what is required to successfully deliver the backlog item. 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.

• According to this sprint goal, the PO prioritizes the product backlog and selects the most important product backlog items or writes new ones.
• Different products and different teams will have unique needs in terms of frequency, techniques, and level of detail.
• 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.
• That is not tactics but part of operations, positioning the Scrum team for success.
• The result is an estimated Product Backlog in relation to a reference item.

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 and Refinement Anti-Patterns

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 amount of time allocated will depend on the state of the product backlog. In the early days, developers will likely need to dedicate a lot of time for refinement. As the product backlog takes shape, it will have fine grained items towards the top (not more than a 1 or 2 sprints’ worth) and more coarse-grained items towards the middle and bottom. At this point, developers can dedicate less and less time to refinement. The amount of time will never go down to 0 but will likely settle around 10% to 15% to maintain the product backlog in this shape and regularly prep for the next sprint.

Backlog refinement is not an event in single-team Scrum

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 deep backlog 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.

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.

The meeting builds momentum and the team walk away feeling as if the meeting and conversations were productive, valuable, and actionable. Teach the team the value of having those short, crisp conversations that are focused on the issue at hand. It’s better to have a short, focused and timeboxed conversation about an item than it is to have a long, meandering conversation that potentially leads nowhere. Ideally, you want to https://globalcloudteam.com/ move through several sizing estimates and get clear on how the backlog should be refined and prioritized. In my experience, if you can’t size something within 3 attempts in a single meeting its best to put it to one side and move on. You want a healthy environment where people can bring up any issues they have or ask questions to gain greater clarity and this is where you are teaching the team to have those conversations.