Backlog Refinement Recap

Some thoughts on backlog refinement from a recent presentation I gave about the topic. A key point: how you refine your backlog and who you involve is more important than the format you use.

The first week of October, I presented a session at IBADD about backlog refinement. Before the session started, I asked the attendees to write on post it notes what they hoped to learn.

That activity serves a couple of purposes. It gives me insights into how people interpreted the intent of the session, it indicates what questions they have about backlog refinement, and it acts as some just in time success criteria for the session.

It’s a little tricky to change the presentation in the moment to respond to these items, especially since I didn’t take a close look at the items until after the presentation. I think I covered a good number of the items in the session, but I think it’s only fair that I address all of them, which is what I’m doing in this week’s newsletter.

I’ve grouped the post it notes together into themes under the sub headings. The sentences in italics are the actual post it notes people wrote.

Describing backlog items

Tips for writing better stories How to make requirements stand out in acceptance criteria How to translate users needs to user stories without getting too detailed

The purpose of backlog refinement is to build shared understanding among the people creating the solution. Backlog items (aka user stories) certainly play a part in that, but in many cases, the act of figuring out what backlog items there should be and co-creating them is more important than format.

My biggest tip: As early as possible, have a conversation with your product team to get an initial idea of what they would find useful in backlog items. The technique I’ve found helpful to structure that conversation is the definition of ready.

Each team’s definition of ready will inevitably be different, however over the course of almost 20 years working with backlogs, I’ve landed on this prose form that seems to work pretty well.

When you use this discussion to establish an agreement and regularly reflect and adapt, it will go a long way towards establishing a routine where your backlog items carry the right amount of detail. You may not start out there, but you’ll definitely find the sweet spot over time.

I find these days I’m generally working out of some form of backlog management tool (Jira, Azure DevOps, or ClickUp for example) and they all have a free form description field. In that description field I usually have these sections:

Overview

• Provides context for the backlog item

• Should explain why the backlog item is needed

• When pertinent, should also explain who is impacted

• You could use As A, I want, so that here, but you really don’t need to.

Revisions Needed

• Changes driven by backlog item

• Include business rules, data, and processes

• Often includes links to outside artifacts (screen mockups, api Specs, Data Dictionary, process flows)

• Depth of technical information depends on what the team is looking for

Acceptance Criteria

• Conditions that a backlog item must satisfy to be accepted

• Can reference functional or non functional requirements

• Define the boundary of the backlog item

• Focus on business intent

• I like to write acceptance criteria in the form Confirm that…

Examples

• concrete descriptions of the expected behavior of a solution

• uses real-life data

• useful for describing a solution

• provides guidance on ways to validate it.

• Further explains acceptance criteria, when needed

When I use this approach, the requirements tend to be explicitly stated in the Revision Needed section, so the Acceptance Criteria (and Examples)can then provide some helpful guidance for testing purposes.

Participation in backlog refinement

How to encourage real engagement in refinement Better backlog refinement participation How to be a better partner/participant in refinement More communication from team esp Engineers How to build more transparency into user stories to encourage participation

Another tip I have for writing backlog items actually fits better in this section: read the room with respect to how involved your team would like to be in backlog refinement.

In an ideal world, everyone on your team would be ecstatic to take part in backlog refinement.

I’m not sure about you, but I haven’t lived in a real world since I found out that Santa Claus isn’t real (sorry if I ruined that for anyone).

There will inevitably be different levels of interest in taking part in backlog refinement. I’ve found it’s generally not a good idea to force it.

But you you need to make sure the opportunity is there and to invite the people who may be interested to join in.

Involving folks in backlog refinement can take a few different forms depending on the level of interest among your team.

If there’s a great deal of interest, it may make sense to start the co-creation from the beginning. Don’t start crafting your backlog items until the team is together and all able to focus on discussing backlog items.

If there’s less interest, you may find it better for someone to craft an initial draft of backlog items, keeping in mind the idea of one page, one hour. Then, build in a recurring step in your backlog refinement process for members of the team to review those backlog items.

So don’t force things to start out, and then as you continue to work with your team, periodically spend some time during a retrospective to see how well backlog items are serving their need and discuss ways to revise your backlog refinement process.

Be open to the feedback you get during these discussions and seek opportunities to make changes.

All in all, the key to getting better involvement in backlog refinement is to meet the team where they are, and look for ways to help your team feel as though they have a say in how backlog refinement happens so they get the information they need.

Which reminds me of another post it note that I originally had as a separate section.

Do the engineers get to make sure the work items are ready

In a sense. They are the consumers of the backlog items, so they certainly should have input into the types of information that backlog items have. They also should be able to play a part in crafting those backlog items if that helps them build shared understanding of the problem and solution.

But if your team is using a definition of ready as a way to “hold product people accountable” that’s a sign there’s something a little rotten with your team culture. You discuss your definition of ready as a way to build agreement about what information the team needs. It’s not intended to be a written in stone filter that absolutely prohibits items that don’t meet it (often for good reasons) from being included in the team’s work.

Making priority decisions

What can you do about setting priority

How best to prioritize what is refined

As it just so happens, I recently did a lightning talk at Agile + DevOps Days Des Moines about prioritization. Here are the key points from that talk:

• Prioritization is deciding what you will (and will not) do.

• A Priority is the most important action, activity, product, or service your organization does. This is the thing you use to help you make prioritization decisions. By definition, priority is singular, yet many organizations chose to identify multiple priorities.

• To make an effective use of a priority, treat it as a filter, not bucket. If an idea you have does not help you do the priority, don’t do it. It’s not about see where every idea “fits”.

• Prioritization is not sequencing. First decide what few things you’re going to do, then determine what order you’re going to do them in.

• Many teams when working with backlogs are tempted to generate a list of things they could do. That adds a lot of waste. Instead start with what you’re trying to accomplish, and then identify the things that will get you there.

• You probably don’t need a framework to make prioritization decisions. They give a false sense of objectivity and often were created for a context that’s not yours.

• The best way to make priority decisions depends on your context.,

If you’ve been a subscriber to InsideProduct for a while, you most likely saw the series of issues I did on prioritization. If you’re new here and would like to see those, let me know.

Backlog refinement with multiple work streams

Backlog management with multiple streams of work

Remember when I said that we don’t live in an ideal world, this is another symptom of that.

As much as we’d like to avoid it there may be times when your team is responsible for different types of work (new features, production support, removing tech debt, fixing bugs) or have multiple stakeholders with different expectations and requests.

I’ve found capacity allocation as a helpful technique for managing different types of work. Determine how much of your teams capacity they’ll spend on the different types of work. Then you can prioritize which items from each type the team focuses on in the near term.

For the case where you have stakeholders with different, and competing demands, this is a special case of a prioritization issue, and sometimes the way to handle that is to get all the liars in the same room and discuss as a group which requests will help the business achieve it’s top priority.

Backlog refinement process & techniques

Processes, procedures, anything I’m a new BA How to improve the refinement process Effective refinement approaches How to improve our current backlog refinement process Tips, tricks & best practices Creative & new ideas

This was the gist of the presentation, so hopefully I satisfied these points. Here are the tips for effective backlog refinement I shared in the presentation:

• A good backlog has a few items, mostly big. I’ve gone to keeping bigger scope further out items on a roadmap and leaving the backlog to only contain things the team is working on right now, which leads to my next tip.

• Break items down only when you need to. I typically use a Now - Next - Later roadmap, and only break the items in the Now column down to items on the backlog.

• Prioritize on Impact. See above section

• Include multiple perspectives in backlog refinement. Ie - make it easy for your whole team to get involved in backlog refinement if they are so inclined.

• Get your team the information they need.

Estimating

Work estimates

I like to turn discussions about estimates into discussions about budgets. Answer the “how long will it take” question with “how long do you want it to take?” Aka movie phone estimating.

What is the meaning of life?

The meaning of life

42. Trouble is, we’re not sure what the question is.

Thanks for reading

Thanks again for reading InsideProduct.

I hope you found these ideas helpful. If any of them resonate with you or you’d like more info, let me know and I’d be happy to go into them further.

Talk to you next time,

Kent