From the course: Agile Requirements Foundations

Level of detail in the backlog

From the course: Agile Requirements Foundations

Level of detail in the backlog

- We have looked at what a healthy backlog looks like, and even with healthy backlogs, teams struggle with knowing the right level of detail for their backlog items. With our backlog, I talked before about the funnel shape backlog and having a top 10, next release, subsequent release, and the rest. All backlog items should be well-written, easy to understand, and be an independent increment of value. The top 10 ranked items should be the backlog items with the most detail, and the furthest out items should have the least amount of detail. Notice in this visual, that the items in the backlog are much smaller the closer they get to the top 10. Slicing the items into smaller increments of value is a key part of the detail question. It's not about adding a bunch of detail to a large backlog item. It's about slicing the items into smaller, more detailed pieces, and having good acceptance criteria for these items. Let's look at our case study example. On the team's backlog, there's an item for selecting payment type, and as this gets prioritized, it gets broken down into more detailed items like Paypal as the first payment type that we provide. And then we'll work on credit card and then gift cards. So, the select payment type item becomes a parent item with these smaller items as children items. And as it gets prioritized, it gets broken down into smaller, more detailed items like the following three Paypal scenarios. First scenario, it's a simple transaction, only one account used, it's the only payment method used, and it results in success. Second, there's an error connecting to the Paypal account. And third, funds are not available in the Paypal account. In this case study exercise file for our online coffee store, I've provided this example with a full breakout of the online payment and beyond the Paypal example. Please review it and see the extent of all the detail. A single backlog item is often broken up into 25 to 50 more detailed items, and then each item can be prioritized, many actually getting left behind as not really needed. With this, the team can more accurately estimate what it'll take to get the work done. The level of detail in the backlog is defined just in time and at the last responsible moment. It's about waiting for something to become a priority before we spend time breaking it down further. The slices of value break items down into smaller pieces which are still meaningful to the user experience. Notice how this backlog detail example did not take the payment type functionality and break it down by the activities and tasks a team does to get all the work done, nor is it broken down by technical component. It's an increment of value to the user. And this is a common issue that teams fall into. If this happens, the teams cannot release or get feedback as often and learn from what they've completed. It's about breaking it down by value from a user point of view so that we can hone in on which pieces are truly important and then pivot to other work when change comes our way. If we tried to break it down by technical component, we're stuck building it all to get value out of it. Smaller increments of value allow the product owner to change priorities and scope and allow the organization to pivot. This allows spending on other areas of focus without waiting for a big piece of functionality to be completed. In this example, we may get the Paypal payments implemented, and then a big change in the market may tell us that the shipping function needs a feature that is more important than implementing other payments types at this time. The team can pivot to working on the new shipping feature, moving these other items in the backlog. As long as the backlog is defined in increments of value, the team can switch priorities without leaving work hanging or leave the priorities in limbo for a longer period of time. Levels of detail in the backlog are the keys to the doorway of change and only doing what's needed just in time. As a business analyst, you play a huge role in making this happen.

Contents