In my journey as a professional Scrum trainer and Kanban coach, I’ve often encountered a common misconception: the belief that a hierarchy is essential for effective backlog management. Today, I want to share my insights on why this approach can be detrimental and how we can rethink our backlogs to enhance our agility and focus on delivering value.
Understanding the Backlog
At its core, a backlog is simply a list of tasks or items that need to be completed. However, the way we order this list is crucial. Each item should have a distinct position—first, second, third—without any items sharing the same level of importance. This flat structure allows us to prioritise effectively, ensuring that the most critical tasks are addressed first.
The Pitfalls of Hierarchical Structures
Many teams fall into the trap of creating a hierarchical backlog, often breaking down epics into features, which then break down into stories or tasks. While this might seem logical, it introduces several challenges:
Work Breakdown Structure: This hierarchical approach often leads to a focus on breaking down work rather than delivering value. Teams can become so engrossed in managing the structure that they lose sight of the ultimate goal: delivering value to the customer.
Inflexibility: When items are tied to a parent-child relationship, it becomes cumbersome to reorder them based on changing priorities. If I want to elevate the importance of a task, I might inadvertently change its parent, complicating the management process.
Limited Relationships: Most tools enforce a tree structure, which means each item can only have one parent. This limitation makes it difficult to represent items that contribute to multiple features or initiatives, hindering our ability to manage work effectively.
Rethinking Our Approach
So, how can we shift our mindset and practices to avoid these pitfalls? Here are some strategies I’ve found effective:
Embrace a Flat List: Instead of viewing your backlog as a hierarchy, treat it as a flat list. Each item can have additional context—such as tags or links to documentation—without being constrained by a parent-child relationship.
Utilise Tags for Context: In tools like Azure DevOps, you can use tags to provide context for each item. This allows you to filter and view items based on features or projects without losing the flexibility of a flat structure.
Focus on Value, Not Volume: Shift your team’s focus from merely completing tasks to delivering value. This means prioritising items based on their impact on the business rather than their position in a hierarchy.
Visualise Flexibly: Use your tools to create visualisations that make sense for your team. Whether you’re using Azure DevOps, Jira, or even a simple whiteboard, ensure that your backlog reflects the current priorities and context.
Practical Application
Let me illustrate this with a practical example. In Azure DevOps, I often set up my backlog as a flat list, tagging items according to their associated features. This way, I can easily filter and prioritise tasks based on their relevance to ongoing projects. For instance, if I have items related to “Feature One” and “Feature Two,” I can quickly assess which tasks are most critical for the upcoming sprint without being bogged down by a rigid hierarchy.
During sprint planning, my team and I can review this flat backlog, considering various factors such as business priorities, ongoing engineering work, and customer needs. This approach allows us to make informed decisions about what to include in the sprint, ensuring that we remain agile and responsive to change.
Conclusion
Moving away from a hierarchical backlog structure can be challenging, but the benefits are undeniable. By embracing a flat list approach, we can enhance our ability to manage work effectively and focus on delivering value. If you’re struggling with this transition, remember that support is available. My team and I offer consulting, coaching, and mentoring programmes designed to help organisations like yours thrive in an agile environment.
Let’s connect and explore how we can elevate your backlog management practices together.
You can’t order a hierarchy. In this video, I’m going to demonstrate why hierarchies in backlog management inhibit the ability for us to manage them effectively and how we can think about backlog differently. My name is Martin Hinwood. I’m a professional Scrum trainer with Scrum.org, a professional Kanban trainer with Pro Kanban, and I’ve been a Microsoft MVP in DevOps for 15 years. A backlog is just a list of things you’re going to do, but backlogs have some special characteristics. One of those main characteristics is that it’s ordered in some way. You still need to decide how it’s ordered, but your backlog should have an order, i.e., there’s a distinct first item, second item, third item. There are no items in your backlog that have exactly the same level; therefore, it is a flat list of what it is we’re going to do next or what the most important thing is. The order of the backlog informs but does not control the selection of the work that the team is going to work on at any time. There may be other things that come into that story at selection time, not just what of the most important things that are there. There might be other implications in technology, the state of the product, other things that are going on that we need to consider as we move through our product.
So why is hierarchy a problem? The most common thing that you see in teams is, depending on the product they’re using to manage their backlog, they might have epics break down into features, break down into stories or backlog items. They might have features break down into epics, break down into backlog items. You might have any number of other things going on. You might have initiatives that break down into something that break down into the theme. Here is that you’ve got things that break down into other things, i.e., a parent-child relationship. If you have a parent-child relationship in a tool, it’s very difficult to manage it in a way that allows us to use that context without that context inhibiting our ability to do stuff in the tool. So I’m going to show some examples, and this is also not just a tooling issue but a mindset issue as well. If you’re thinking about your work as a parent-child relationship, the tendency, the easy thing that happens is that we end up with a work breakdown structure, which is not effective because ultimately it’s not value-focused, and that’s what we’re trying to achieve. All of agile, whether you’re using a specific agile framework or you’re trying to follow the agile manifesto or you’re thinking about lean and Kanban, any of these things is focusing on the flow of value through your system. So if you’re focused on the flow of value through the system, you need to be focused on the value. If you’re focused on the work breakdown, you tend not to be focused on value; you tend to be focused on delivering more stuff.
So that’s the tendency. But what’s the relationship that makes it difficult in hierarchies? So I’ve created a demo here to show what the problem is. In this example, I’m just going to use Azure DevOps; that’s my tool of choice, that’s my preference, but this could be any tool, including just a mural with backlog items. So here I’ve got three features: feature one, feature two, feature three, and the intent of this tool is that features work at a different level from backlog items, and they inform but do not control the next level down. But the reality is that they do control the next level down because most people use this kind of view to see what’s going on. So you’re looking at features breaking down into backlog items here, and perhaps those backlog items break down into tasks: task one, save that. Oh, I need to close it now. I made two, don’t save that one. So now I’ve got this hierarchy, this work breakdown structure towards this item, and then the tendency is to use this view and to put little progress bars and whatever you want on this view, and you end up with what looks a little bit like a project status report. That’s the tendency when you use these types of views. With huge amounts of discipline on your team, you can certainly avoid this, but I find that that’s not the case for the majority of encounters that I’ve had with teams that are doing this.
The other thing that makes it very difficult is that if I want to make one item more important than another item because I’m looking at this view, I actually tend to only make things important or not important inside of the scope of the feature because I can still drag and drop inside of here and order that hierarchy, same as if you were using just mural and stickies. It has to be under that feature. But if I want to make this item more important or less important than this item here, I want to drag it below this item, and suddenly if I drop this, I now changed the parent-child relationship from feature one to feature two, and this is a feature one element, not a feature two element, and that doesn’t make any sense. So I need to go put that back. So when we manage our work and we’re trying to actively manage what’s going on here, it tends to make it a little bit more difficult to visualize, to engage with the work. What we really want is we want people to turn off the parents and manage the backlog as a backlog, not as a hierarchy. So they’re dragging and dropping things within here, they’re ordering this list, and creating a view that makes sense just for them.
So the main problems with a backlog hierarchy are the first one is the tendency towards ending up with a work breakdown structure. The other tendency is to not order your backlog because it changes that parent-child relationship, and it’s effort to switch between the different views. It’s even more so on stickies on a whiteboard, right? Because you have that fixed view; you can’t pivot that display that you like you can in tools. The last element that is difficult is parent-child relationships are one parent, many children within the context of almost all tooling. It’s a tree structure, and that inhibits our ability to have an item that goes on our backlog that has many parents, a many-to-many relationship. I might have a thing that I put in my backlog that enables five different features, and then that becomes quite an important thing to work on because it enables these five different features or is the first foundation for these five different features, and it’s very difficult to represent that when we have that breakdown structure from epic to feature or high-level item to next-level item to backlog item.
So how can we think differently so that we don’t have this problem? What we want to be able to do when we’re thinking about our product backlog is we want to think about it as a flat list. It always should be a flat list, and each item has additional context. That additional context should be able to be visualised in various ways depending on the tooling that you’re using, whether you’re using a hub, GitLab, Azure DevOps, or Jira. The tooling will allow you to create some of those visualisations, those pivots on the data without actually having a hierarchy, parent-child relationships. That’s the primary way to do that. So I’m going to show you how to do this in Azure DevOps. I have an example set up here. I’m just going to use the same team, and I have a bunch of things in my backlog here. If you ignore that effort column there, I will just remove it because it’s inconsequential for what we’re talking about here.
So one of the things that we’re interested in in this list is going to be a flat list that we’re going to order, but there might be additional things that we want to take care of. So if you remember, we had a bunch of things that had features assigned to them. So what I can do is I can turn on the parents again, and what I’m going to do is I’m going to get rid of those parent relationships, and I’m just going to do a tag ad, and I’m going to cheat, and I’m just going to call it feature one, use feature one, and I’m going to call this one feature two. I’m going to ignore feature three, tag ad. Now tags need to be a little bit more deliberate. You can control both the ability for people to create tags; that’s pre-moderation, or you can use a post-moderation technique. There is a plugin on the store; you can see it’s got 28,000 installs across TFS and Azure DevOps. This allows you to actively post-moderate those tags, so activities like merging tags, filtering tags, managing things you can do to manage those tasks across TFS and Azure DevOps. I’m sure there is the same story in other platforms as well, whether you’re using GitHub, GitLab, or Jira.
So now I have a feature assigned to each work item. I can easily open a work item. I can see that it’s to do with a particular feature or capability. I could even link to that capability as a link to a wiki page, so I could link to an existing item here and just pick a hyperlink and go to a wiki page, some kind of documentation on what this is. But what I ultimately want to be doing is managing this flat list of work items so that I can say that any item is more important than any other item, whether it’s feature one or feature two. I can intermingle all of those things between feature one and feature two to best represent the business order and business priority of my product backlog. So this is not implying that this is the order that we’re going to select items in. This doesn’t mean that the team is going to say, “Well, we think we can do five items in the next 14 days.” These or ten items, these ten items are ready. That’s not how that’s supposed to happen. What a team would do is on each cadence, whether it’s marketing, whether it’s either replenishing the ready queue in Kanban, or they’re doing their sprint planning, they’re going to make a decision on how much work are we going to take in from the priority list versus how much other work do we have. Perhaps there’s some long-running engineering work that’s going on that has to happen behind the scenes that the customer doesn’t really care about in the short term, but in the long term, it’s going to provide them with a huge amount of value. So those items are going to be brought into the sprint, are going to be prioritised in that same way as these other business items. You may even add them to your product backlog. I don’t have any of them in here, although it does seem like that because there are things like reviewing application architecture, but that’s for the product that is referencing.
When I’m looking at this list, I might want to filter and understand what’s going on with certain items. So what I can do is I can hit this filter button here, and one way to filter would be to use the tags that we created. So I can say, “Here’s feature one,” and here’s all the feature two items. And feature one, here’s just the feature two items. I can also look at, for example, all of the risk guardian items. So if I pick risk guardian, which is one of the projects that is represented in here, so I’m using tags to not only represent the features that we might be working on and delivering. Some of those features might go across applications that we’re building, but we’re also able to filter this by the application that we’re building. So I can very clearly see that these are the items that are part of feature two that are part of this application, but these three items down here are not part of feature two for that application. So I’m able to very easily change my filter and say risk guardian and feature two, and I can effectively matrix and filter what I’m looking at to see what I might want to take on into the next sprint.
In Azure DevOps, I might even do a little bit of planning, and there’s my future sprints for this team. I’m just going to do some arbitrary forward forecasting. I’m not using a tool here to do probabilistic forecasting, but I’m just taking a guess, which is very much a bad way to do it. But you can see on this list the actual order of these items on the backlog, and I’m not able to reorder those items because I don’t have that full list of items because we’re filtering. It disables that ability to order, but I can still go in here and move to a certain position within this list. So I can say move to, it’s 25. I want to move it to about eight, move to eight, and then we can go fine-tune that later. But here you’re seeing there’s one item that’s really important for risk guardian here at four, and then these things are a little bit further down the chain. But we’re going to create a sprint plan around risk guardian because it’s been deemed fairly important for the business, and feature two is more important than things that are not feature two. But risk guardian is also important, so I’m creating this filter to see what it is we’re going to take. We can take about 20 things into the sprint, but we only really want to take maybe five things for our sprint goal, which is going to be around feature two and risk guardian. We’re going to create a story around that.
So what I might do is take a little look across these items and say, “Well, this item’s great; we’re going to need to do that. That’s going to come in.” And then we’ve got, “Yeah, that’s not as interesting, that feature one, but it should really be part of this,” even though feature two is currently more important than feature one. And this one, and this one, so that’s three. I need a fourth one. This one’s not as useful yet, but this is much more useful, so we’re going to take that one. And now I can drag these into the next sprint. There we go, they’ve all been assigned to that sprint. You can see that in there, and that’s our plan. We could have done this in sprint planning; we could have done this in refinement, and then we’re going to review it in sprint planning. Like we’re going to take about 20 things into this sprint, but here’s the five that we think are to do with the next goal. We might get more information at the review, but we can adapt this. This is not set in stone; this is just a best guess at this moment in time what we think would be a good idea here for sprint one as we get nearer to sprint one starting.
So there I’ve been able to do that with filtering. So if I remove that filter, you’ll see those sprint one items are not next to each other in the product backlog because we’re using the order of the product backlog to inform but not control the contents of our backlog with a focus on value. And we made the decision about what items we’re going to bring into the sprint based on multiple vectors of information. One was the projects, right? So here I’ve got risk guardian, insight ledger, unity ERP. There are various, maybe we’re integrating into other systems, right? We’ve got various projects that are going on that are managed by other people. We’re delivering the value, and we’ve got a bunch of features, which are a different way of grouping the contents, not based on project. We actually have, there’s another vector in here that we didn’t really talk about, which is the stage of each of those pieces of work. So what’s the main topic of those pieces of work that is independent of feature and independent of project going on within the bounds of our product that we’re delivering here, which looks like an integration tool.
So hopefully, this was a useful view of how we can move away from a hierarchical work breakdown structure towards something that is more flexible, that is more usable, and more effective. If you are struggling to move away from a project-based work breakdown structure for visualising your backlog, we can help you. We have consulting, coaching, and mentor programmes that can help kickstart your company’s ability to manage your work actively and focus on the value that your business needs. Get in touch below.
