Today, You probably know Scrum is the most general framework for maintaining complex products. You might also have the weekly procedure to attend a meeting called "Product Backlog Refinement." Here you want to define the new work items for the next sprints.
If you have those regular weekly "meetings," you might also encounter the situation that you had nothing to say, and you were staring at some backlog or board where your teammates discuss work items.
This scenario is often the case when having Product Backlog Refinement events in Scrum. Doing it the wrong way can be lengthy and inefficient. But using the right tools, e.g., Azure DevOps, for the event and structuring it the right way, you can refine your items more efficiently and create well-defined work items.
For that, I want to look at:
Scrum is a well-known framework, and I don't want to talk about the theory today. If you need more background information or are entirely new to Scrum, you can check out the Scrum Guide web page.
If you check out the Scrum Guide, you won't read anything about a backlog refinement event. There are five Scrum events:
And that's it! But how is it possible that we often have different backlog refinement events?
To work on a new product backlog item, you essentially need to create a complete and well-defined work item. Everyone in the Scrum team is supposed to work on the work item and know the topic.
As the Scrum Guide states it:
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
But often, stakeholders dump new items into the backlog without a proper description. Thus, you need to refine the items to understand a specific work item inside the team clearly. But how do you make this well-defined product?
Since Jeff Sutherland and Ken Schwaber introduced the framework, many teams interpreted their version of Scrum or a slight variation. What stands out is that many Scrum teams create a dedicated event where the whole team gets together and starts refining new backlog items. Therefore you avoid refining a product backlog item in the Sprint Planning, which would inflate the event.
In general, creating a dedicated backlog refinement event to clarify items is not a bad idea per se, but there is a particular issue here. Especially for big projects, not everybody has complete knowledge about every part of a system. Therefore you often see people sitting passively in this refinement "meeting" and contributing nothing.
Scum is supposed to be lightweight, and it should not overload the Scrum team with too many meetings. You want to focus on your work and not on endless meetings. So what can we do to trim the backlog refinement so it is helpful for everyone?
One approach is to see the refinement of product backlog items as an ongoing process where only experts come together and refine specific items. The refinement can also be in a dedicated event, but this time not everyone is attending.
Items don't have to be ready after one refinement meeting. Because it's an ongoing process, you can refine work items multiple times until they are considered "ready" for development.
This approach has the advantage that it is not a static meeting where everyone needs to attend. And in the end, you can refine items throughout multiple events.
No matter how you structure your backlog refinement. The primary question is, how do I visualize it effectively? This is where Azure DevOps comes into play.
Azure DevOps is a Service provided by Microsoft that brings DevOps and Application Lifecycle Management (ALM) together to keep it short. It provides boards and a backlog to map the Scrum artifacts (product backlog, sprint backlog, and product increment) into the tool.
It supports version controlling for your code and a complete CI/CD integration. Azure DevOps provides the possibility to progress your work from start to end. If you want to know more about Azure DevOps and go into detail, you can check out their docs at the Azure DevOps documentation.
Now the question is: How can we bring both worlds together? How can you use a backlog board in Azure DevOps to visualize the status and the progress during and at a refinement meeting?
Azure DevOps provides a backlog page to list all your items, with the most important ones at the top to map the Scrum product backlog.
The Azure DevOps backlog helps you to get a rough overview of all the items and their current status. But you often want to be more granular. Here the Backlog Board comes into play.
With the help of columns, you can give your backlog higher granularity and better track the current progress.
When creating a project, the default board configuration consists of 4 columns:
Of course, the Azure DevOps Boards are highly customizable, and you can add as many columns as you want. So I have added two new columns:
Why that, you may ask? When going into a refinement event, it is helpful to see what product backlog items need refinement. And if the work items are refined and ready for development, we also need a specific column.
But now, you may ask yourself, what does the "Approved" column do? Couldn't we use the "Approved" column for the refined items?
Technically, you can do whatever you want. There are no strict "rules" here. You can customize and move the columns how you like. My experience from former projects showed me that it is helpful to have a dedicated "Approved" column before the actual refinement. The Product Owner can use this additional column to sort out items before they even get into the refinement process. The "Approved" column (you can actually call it whatever you want) also has the advantage for the dev team to deal with this during the refinement event.
So what should you focus on during the refinement event?
As mentioned earlier, you want to deliver value with your product. Therefore, you want to have a well-defined product backlog item with clear boundaries that give your product more value.
So during the refinement event, you leverage Azure DevOps backlog items to fulfill this prerequisite.
Product Backlog Items in Azure DevOps provide vital areas to define a clear scope of the work that you need to do when taking on this item.
As shown in the image above, I want to focus on four key areas:
The description can be in the form of user stories, but this is not a must. There is no single truth to that, and it depends on the team. But the description must give the team a clear understanding of what it is.
The acceptance criteria are mandatory. There is no way around it. Acceptance criteria should clearly state when an item is considered "Done".
Poorly defined acceptance criteria (like the one in the item ;)) can lead to difficulties during the development of the item, which slows down your progress.
A team needs to estimate the effort of an item. I won't go into details about how to measure the effort of an work item. But during a refinement event, the team needs to find common ground about the effort it requires to finish a specific backlog item.
Additionally, Azure DevOps provides valuable fields like a priority, business value, or value area to provide more information and higher further granularity.
If you and your team filled the areas with sufficient information so that everyone has a clear and measurable understanding of an item, you could move the item to the "Ready" column.
But what if you have a lot of items in the "Refinement" column? What if we cannot finish refining one or more items during one event?
Here you can again leverage the power of Azure DevOps. Inside the backlog board options, you can split one column into the Doing and Done sub-column. It gives you more flexibility and higher granularity when tracking the current progress of your refinement work.
As mentioned in the beginning, there is no single truth when using the Scrum framework. When combining Scrum with Azure DevOps, this is even more true. You can leverage the high customization options in Azure DevOps and perfectly tune your refinement process inside the service so that your refinement events become more efficient and refreshing instead of boring weekly meetings.
For that, you should:
I'm curious to see what you think about this? How do you structure your backlog refinement event? How does it look like, and how do you use services or tools like Azure DevOps to increase your efficiency?
