Visualizing an Upstream Refinement Board for Scrum Teams
Originally published July 2021
For those who use Scrum, many like the established five scrum events that take place each sprint (stand up, sprint planning, sprint review, retrospective, and the sprint itself). However, one event not found in the Scrum Guide is the Backlog Refinement Meeting. It’s referenced in the Scrum Guide even though it’s not called out as a specific event:
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items…This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” – 2020 Scrum Guide
I like to think of refinement as the work that takes place “to the left,” or “upstream,” of the Scrum board to help meet the team’s Definition of Ready (DoR). The DoR can be thought of as the criteria that, when met, gives the team confidence the backlog work item is ready to be pulled into a sprint. Unfortunately, teams often find it difficult to track the work needed to achieve the DoR by simply having a refinement meeting once or twice a week. When they do meet, teams will often express frustration not knowing “where they are” in the refinement process, and a significant portion of time can be spent just remembering and regaining context where they last left off. Having an upstream board can visually provide that context so team members know what has been accomplished and what’s left to do.
When teams lose context, they begin to experience anti-patterns of ill-prepared backlog items. This can manifest itself in having work items that:
Really belong upstream as part of refinement. I worked with teams that created “analysis stories” to be worked on in a sprint. Upon further investigation, however, these stories were not value-based work items; instead, they were tasks that represented work to get a user story ready for a sprint.
Are ambiguous or unclear leading to additional refinement in the sprint. A team I once coached would continue discussing and making decisions about the work item during the sprint. What made this problematic, however, was that most discussions involved topics that really should have occurred as part of the DoR before the sprint started.
Take the entire sprint to finish. Additional refinement in a sprint inevitably leads to more time to complete work items. This has some adverse impacts. I worked with teams that consistently finished all stories at the end of the sprint robbing themselves the opportunity to obtain feedback earlier. In addition, it placed additional burden on those performing testing activities since it was occurring only at the end of the sprint.
In addition, with refinement work needing to take place upstream of the downstream sprint work, many teams find it difficult to “balance” team capability between these two streams. The upstream work feels “hidden,” thus giving an incomplete picture of the work the team is responsible for accomplishing.
Unhiding What Is Hidden
To address how to manage and incorporate the upstream work, a good place to start is to recognize that the upstream refinement work and downstream sprint work both represent the overall value stream for a product team. Teams often overlook this subtle yet important fact because emphasis is frequently placed on the downstream mechanics of the scrum events. Recognizing this entire value stream provides a greater context for which the team is responsible. This allows teams to begin addressing the imbalance often felt between the work needed to refine stories (upstream) and the work needed to complete them (downstream).
After recognizing the upstream work is part of the overall value stream, it’s time to make this work visible – that is, to design an upstream refinement board to help address the DoR. And once it meets the DoR, it’s ready to be pulled into a sprint.
Setting It Up
I’ve worked with many teams visualizing their upstream refinement work by means of a refinement board. At a minimum, here are some of the practices I recommend:
Meet with the team and walk through the logical sequence of knowledge gaining activities to meet the DoR. In addition, begin to understand what policy criteria need to be met to move a work item from one activity to the next. Make sure everyone understands agrees to these policies.
Now it’s time to visualize this flow by means of a refinement board (see image). The columns in the upstream board will be a combination of activities and policies discussed above. These steps take place to the left of the sprint board. Oftentimes, the very last column is labeled something like “Ready for Sprint Planning,” implying that the work item has met the DoR.
Consider NOT managing the upstream work on a sprint-by-sprint basis. Even though the work on the Scrum board should be completed at the end of each sprint, the work items on the upstream board do not have to follow the same cadence. Teams should make sure work items needed for an upcoming sprint are ready for that sprint, but that does not necessarily following a sprint cadence is necessary.
Begin to review your upstream board along with your downstream scrum board in your daily standup. Recognize that both boards provide a view of all work for which the team is responsible.
Upstream refinement work can be visualized and managed independent of downstream sprint work even though both make up the overall value stream. Visualizing upstream refinement can help “unhide” this work.
When I work with teams struggling with their refinement, the practices listed above are the minimum I’ll suggest. A team can take this further (and should!) by employing practices such as establishing WIP limits, managing and measuring flow, implementing feedback, etc. But I have found that even beginning with the practices listed above, teams have found vast improvements in their refinement process.
Results and Benefits
After building an upstream refinement board, teams often experience improvements shortly thereafter. Improvement I have observed include:
Less refinement work in the sprint. A common anti-pattern often found in Scrum teams is refining work items in the sprint itself. This is a clear signal that the refinement effort did not meet the DoR. Employing an upstream refinement board can reduce this because the refinement steps are much more clearly defined (and visible) helping ensure the work item is truly ready for the sprint.
More collaborative refinement discussions across the entire value stream. The simple act of visualization allows for better team collaboration and coordination. When work items from both streams are visualized, individuals who tend to work more upstream can coordinate more clearly with those who work more downstream.
Improved focus of value-based work items. Ideally, work items entering a sprint should be value-based (e.g. a user story) and not simply tasks. It’s not that these tasks are not important or do not need to happen. Instead, the question to consider is: should they be happening earlier? Some of these tasks may really belong in upstream refinement work needed to flesh out and define a value-based work item. Recognizing this can significantly reduce (or even eliminate) these tasks from entering a sprint; thus, allowing only value-based work items in a sprint.
For example, I worked with teams that created “analysis stories” to be worked on in a sprint. Upon further investigation, however, these stories were not value-based work items; instead, they were tasks that represented work to get a user story ready for a sprint.
Better visibility of bottlenecks or “stuck” work items. Because backlog refinement can often feel like an unstructured event, teams can struggle with defining how much refinement is enough refinement. When this happens, work items can feel stuck. Visualizing the upstream work and establishing policy criteria can show where on the refinement board a backlog work item resides and how much work is needed to get it to ready.
I’ve worked with many teams that have taken the time to build out their upstream refinement board. It never starts out perfect, of course, but teams have inevitably found it very helpful. It’s not hard to get started either. Meet with your team, discuss what it takes to meet your DoR, and begin to incorporate the board into your day-to-day practices. Good luck!