One of the first things assembled when we embark on a new project is a list of things to do. Everyone loves a list! Projects often start as a to-do list, jotted down on a piece of paper. For small pieces of work, this may be all you need. As soon as you have more than a trivial set of tasks you’ll need a better system than a simple list and for agile teams, we have Scrum’s product backlog.
In this article, I’ll describe techniques for collecting requests relating to your product and helpful practices for managing that list of requests.
Do you know what you are doing? Do you know why?
Delivery teams are created to help a business realize a part of its vision. If you don’t know the goal you are trying to satisfy and why achieving that goal is important, your team is unlikely to deliberately create the benefits that is hoped for when a project is initiated.
In order for the delivery team to complete a piece of work, many small decisions have to be made to solve the problems encountered along the way. If the delivery team doesn’t have a full understanding of the leadership’s goals and their reasoning, they will find it difficult to achieve a valuable outcome.
Fortunately, Scrum provides an incredibly effective way to manage the requests of our enthusiastic collaborators when building a software product – the product backlog.
The product backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.1
At its core, the product backlog is an ordered list of items that is managed by a person with the ability to understand the business’ needs.
The product backlog is used to:
The term “product backlog” comes from the Agile method, Scrum.
A product backlog contains a list of product backlog items. Scrum doesn’t define what a product backlog item is.
We’ve found that focusing on a product’s capabilities, rather than work tasks, keeps the backlog goal-oriented. When items are goal-oriented they focus on the “what” rather than the “how”. For those familiar with traditional project management, the product backlog is more like the product breakdown structure than a work breakdown structure.
It’s pretty common to have items in the form of:
Over time you may be a bit more sophisticated an add in:
There really are no hard rules on what an item should be called. Keeping all items customer-oriented, rather than couched in terms of the delivery team will keep your backlog focused on making a product that delivers the most amount of business value.
The smallest items, stories, should be a small enough for the team to complete within an iteration. There are no rules for the larger items.
Bill Wake provides us with the INVEST acronym, which says that items should be Independent, Negotiable, Valuable, Estimable, Small and Testable. Mike Cohn has a good article discussing the difference between user stories, epics and themes.
Over time people have worked out ways they like to capture each of these items and we’ll cover that in another article.
The product backlog should be available for anyone to see. Agile principles place a high value on collaboration and transparency. Making the entire list of requests visible will let everyone know what is going on. There shouldn’t be any surprises.
Having the backlog and its activities visible helps uncover unhelpful and disruptive behaviors. A deeper dive into disruptive behaviors will have to wait for another article.
Attempting to store the backlog on a single person’s computer (I’m looking at you, Excel), leads to power struggles and information hiding as the owner of the computer becomes a gatekeeper of the team’s activities.
The backlog must be the single source of requests. It’s important for the source of requests to be centralized because the entire list needs to be ordered.
A single copy is needed because we want to avoid multiple people updating the backlog at the same time, with the consequence that those updates conflict. Resolving conflicting updates can be difficult.
The product backlog is a living artifact and is never complete. At the beginning of its life it will only contain the best understood requests. As the teams learns more about their customers and the marketplace in which the product will operate, the backlog will continue to change for the better.
It’s very normal to identify new items, remove items that are no longer considered valuable and to morph existing items. The product backlog lives for as long as the product lives.
Scrum advocates that the role of Product Owner be assigned. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner gathers input, takes feedback and is lobbied by many people, but it will ultimately make the call on what gets built. They are also solely responsible for the management of the backlog.
The Product Owner is responsible for maximizing the value of the product
In large organizations there may be a project board or a product manager that looks after the direction of the product, with the product owner being the person who works with the team on a day-to-day basis to realize that vision.
In smaller teams, the product owner may be the CEO or product manager working directly with their delivery teams.
Either way, the product owner role is held by a single person. We’ll expand on this in a future article.
A backlog, in its simplest form, is merely a list of items to be worked on. Having well established rules about how work is added, removed and ordered helps the whole team make better decisions about how to change the product.
When initiating a new round of work it is normal to run a workshop to explore what the new round of work will look like. There are user experience, serious gaming and product management communities that have tools and techniques for guiding teams through the market research and envisioning process.
The envisioning process will create artifacts that describe the big pieces of functionality you are going to create, described at a granularity that’s valuable to the company, which is usually very coarse-grained. Some of these artifacts will be broad ranging activities (epics, themes and perhaps new projects or products) and others will be quite detailed functions (stories).
The world changes, the backlog is never finished.
The delivery team needs to accept that items are prepared just-in-time. The backlog contains both items that are thoroughly thought out and items which will require more detail before implementation begins.
As your team works through the backlog you will learn about market opportunities to take advantage of, competitor threats to mitigate and feedback from customers that change the way you imagined the product to work. All of these learnings should trigger your team to adapt the backlog to incorporate your new knowledge. This is part of the fundamental mindset of an agile team. The world changes, the backlog is never finished2.
It is normal to have more ideas captured in your backlog than your company has resources to fulfill. In order not to waste time and money, backlog items should only be expanded enough so that proper planning decisions can be made.
Items at the top of the backlog, the items that are going to be worked on first, should be broken down into stories that are suitable for the delivery team to work on. The further down the backlog you go, the less refined the items should be. As Schwaber and Beedle put it “The lower the priority, the less detail, until you can barely make out the backlog item.”3
As items move to the top of the backlog, either by the items above being delivered or items being reordered, the product owner will refine the requests so that informed planning decisions can be made. Refining the requests entail breaking down the coarse grained epics into many smaller stories, or adding more detail to stories so they are suitable for the delivery team to work on.
The Extreme Programming method advocates that enough detail should be provided in order to make a low risk estimate of how long it would take to build an item. At delivery time the developers should have a face-to-face conversation to get detailed requirements.
Extreme Programming’s just-in-time technique has been very effective and has become the default approach to detailing requirements in agile teams. Your team should work out what works best for them, remembering that many smart people have found documenting less to be more valuable than documenting more.
If the backlog remained as just a list of items we’d have a few major problems. Firstly, it would be difficult to find related items. Secondly it would be hard to get an overview of what we are accomplishing.
If you have lots of items in your backlog it can be a pain to find a story. If you’re displaying your backlog in a physical space then the exact index card you are looking for can be physically hard to find. If you’re using an electronic tool then you may have forgotten where your item is in the backlog or you can’t remember the wording you used to describe an item. So we add information to our product backlog items to classify them in order to make finding these items easier.
Understanding what has been accomplished can act like a compass to help the team focus on what needs to be done.
In large companies, a business case may be put together to create a project to enhance a product. The enhancements within that business case are typically themes of work to achieve a business goal. Typically, each business case theme has a dollar amount allocated which is an estimate of the cost needed to satisfy that theme (or a capped amount the business is prepared to pay to achieve the benefits outlined in the business case).
If, for some reason, money is not being spent in accordance with the initial estimates it is imperative that a conversation with our stakeholders is had to clarify the next steps for the team. The stakeholders may decide that the change in allocation is acceptable and to continue with the project. Alternatively they may decide that the project should be shut down. Either way, the stakeholders need to know the facts in a timely manner so a appropriate decision can be made.
There is a very large caution that must be added when tracking achievements. Do not fall into the trap of confusing cost and business benefit. If you are tracking how much effort it has taken to complete items and using it as a sign of progress then you are using your team’s cost structure as a proxy for project completion instead of measuring the business benefits you are delivering.
Small companies are usually focused on whether the product is achieving its goal and what they can do to realize that goal. They tend to treat past development as a sunk cost.
In general, optimize for business benefit rather than on your cost structure. We’ll explore this further in another article.
A useful way to categorize work is by related functionality. Products, themes, epics and stories are all ways to describe functionality, but each describes them at a different level of detail. If we somehow assign each story as belonging to a theme then we have a very natural way of filtering our backlog. We like to think of this categorization as vertical slices through your product.
Story maps are an alternative way to classify and view backlogs. Story maps emphasizes a user experience oriented view of your product’s design to help ensure you build the entire product all at once rather than just one theme at a time.
It is possible to categorize items in a bunch of other ways too. It can be useful to annotate items with the overall business priority (which is just a time-based categorization), the customer who has requested the item, the user persona the item is targeted at or any other useful data which may help me find this work item in the future.
Mike Cohn coined the term DEEP to summarize the key attributes of a good product backlog. DEEP stands for Detailed Appropriately, Estimated, Emergent and Prioritized.
As we described in the Progressive Enhancement section, backlog items for the upcoming iteration (at the top of the backlog) should have enough detail for the delivery team to start delivering and items further down the backlog should have enough detail to allow them to be planned.
Scrum doesn’t prescribe an estimation technique, Extreme Programming suggests estimating user stories as either 1, 2, or 3 weeks in ideal development time. The common practice in agile teams is to estimate in relative units, usually story points. There are many approaches to estimation that we’ll cover in another article.
Despite the estimation technique used, Product Owners often require items to be estimated before they are ordered. We believe that there are two estimates that should be captured, the cost estimate and the business benefit estimate. The cost estimate represents the amount of effort it will take for the delivery team to complete a backlog item and only the delivery team should add a cost estimate. The business benefit should be supplied by the product owner and is a representation of value returned to the business when the item is complete. The relationship between the cost and the benefit represents the return on investment (ROI). items are usually prioritized by ROI.
Many teams do not create business benefit estimates and instead have the Product Owner use their expert knowledge to calculate the benefit estimate.
We’ve found that making the business benefit explicit helps clarify to the whole team what is valuable and why.
The backlog is a dynamic artifact that changes over time as we’ve detailed in “How does it change over time.”
The Scrum Alliance now prefers the term ordered to prioritized, but people are still using the DEEP term as it sounds better than DEEO.
The backlog is an ordered list which means that every item in the list is part of a sequence with no two items holding the same position. The rule is trying to break the notion that every item in the backlog is “Priority One”. By applying this rule consistently it will coerce product owners into making decisions about the importance of one story relative to another.
It’s common to order the backlog by some combination of return on investment, risk, priority and necessity but ultimately it is up to the product owner to make the trade off decisions.
If you decide to use business benefit in the ordering of your backlog then using techniques such as those outlined in Software by Numbers, kano analysis and innovation games can help provide a systematic way to put a value on your business benefits.
Lean software development approaches advocate using production metrics such as cost of delay to help prioritize work.
Techniques for prioritizing your backlog is a huge area and we’ll cover it in another article.
It’s pretty easy to trip yourself up when managing your backlog. Here are some tips to help avoid common pitfalls.
It becomes tempting to use the backlog as a dumping ground of ideas to appease stakeholders. Some environments are particularly political, and I can’t fully understand the complexities of your work environment, but all I can suggest is that you work out a process to remove items that you are not planning to work on in the foreseeable future. If an item is important it will be suggested again.
The Lean software development movement is very concerned with minimizing waste. Having a backlog with a large amount of items which are not readily actionable would raise questions.
Performing big up-front design when working on a new product is usually going to create a lot of artifacts that won’t be used. Design is very important and I’m not advocating throwing it out. Instead it’s about the level you do design to. Do as much design as it takes to understand the problem and make informed decisions but always strive to keep it as simple as possible.
The Scrum guide suggests you spend no more than 10%4 of your team’s time keeping the backlog in working order. The activity of keeping the backlog neat is called grooming. Grooming your backlog ensures that it always exhibits the DEEP characteristics that make the backlog a pleasure to work with. If you don’t groom the backlog you’ll run into difficulty planning and delivering backlog items.
If you’re dealing with competing interests it can be tempting to set up a backlog for each group to save you the time and effort of bringing those competing interests together. Don’t. Agile, and Scrum in particular, have a knack of exposing organizational issues. When you find them, it gives you the chance to help work it through. If you don’t resolve conflicting requests then the delivery team will be put in the position where they are expected to make the trade off decisions and that will, I guarantee you, get you into a whole bunch of trouble.
We genuinely want to make this the best place to learn about the product backlog. Have we missed something? Should we expand a section? Do you think something is wrong? If you have feedback of any kind we’d love to hear from you.