Let's start without beating around the bush, what is the backlog? It is a tool for managing requirements / requirements on a product, service or project. To paraphrase the Scrum Guidewhich, by the way, was updated in November 2020, is an open and ordered list of requests to improve or complete the value of something - be it products, services or projects.
The backlog, a prioritized list of requirements for a product or service, is an ideal breakdown mechanism for requirements management when requirements are variable and very dynamic. Unlike other breakdown mechanisms, such as the WBS (Work Breakdown Structure), this one has several particularities that we will discuss below and that are key to its success in the management of adaptive projects and the development of products and services.
What elements go into the Backlog?
The backlog is an open-ended list of items. It can have specific requirements for a project or product, it can include tasks, it can include use cases or user stories, and most importantly, it can contain a combination of all of them.
The backlog can only contain user stories
FALSE, FALSE, ABSOLUTELY FALSE!
This is something that as a consultant and change agent I see all the time. Teams suffering, trying to document each and every one of their requirements and backlog elements as user stories. It's just plain stupid!
Each how to write a request is particular to the nature of the product or service under development. Some "types" of requirements promote autonomous development and others, on the other hand, are more detailed and oriented to the strict fulfillment of some conditions.
The maturity of the team is also an important factor in considering how detailed and in-depth the information is that accompanies the items on this prioritized list.
Why Backlog in English and not use translations?
Personally, I don't like to translate the word backlog, because in Spanish we don't have a single word that represents the same thing. A few years ago, when I was a volunteer in the translation group of the PMI Agile Practice Guidewas one of the most difficult discussions, so here are some of the most popular translations in the context of projects and agility:
- Stack
- Prioritized list
- Pop-up and sorted list
- Pending work list
As you can see, they are broad terms that, in Spanish are difficult to adjust, and just to finish, I leave you an example of why it is so complex to translate the word.
Sprint burndown chart is a visual representation of the sprint backlog remaining work through the days.
It would be something like:
The iteration burndown diagram is a visual representation of the pending work from the prioritized list of pending work of the same iteration over the days.
To avoid these things, we would have to call the backlog different things in each situation. List, prioritized list, stack and there would be no way, for someone who is learning, to understand that sometimes the list, the prioritized list and the requirements list - or however you translate it in the context - are the same instrument.
As you can see, it's not a simple term to translate, and even less so if you use words as out of context as battery – stack [1] I admit that some translations within the management and agility context backlog a battery, scheduling a programming, feedback like feedback, burndown chart a burn diagram, y burnup chart like burn up diagramthey generate in me a deep sting. .
What types of prioritized lists are there?
Before I begin, I want to clarify that, although Scrum is in fashion these days, the backlog is not an exclusive Scrum tool. For example, XP defined very well the backlog a few decades ago. So, let's get started:
1. Product or Service Backlog - Product Backlog
When we talk about Product or Service Backlog we refer to all requests associated with the development, maintenance or operation of a product or service. The product backlog includes, among others, tasks, requirements associated with deliverables, enhancements, change requests, maintenance, and everything worth keeping "on the radar" for a given product or service.
2. Project Backlog
A project backlog is useful in some specific contexts and is not an absolute replacement for other breakdown tools such as the Work Breakdown Structure (WBS). In a variable rangeThe use of the backlog is more efficient and practical than the use of the WBS.
EDT/WBS or Backlog to manage the breakdown?
This can be a long and deep discussion, but here is a list of 3 KEY differences to choose between a WBS or a backlog as a drill-down tool.
- Nature of project scope. If the project is closed in scope and part of the management's job is to keep additional requests in check, the WBS is the right one. If, on the other hand, part of the project is to discover, mature or refine the scope of the product or service under development, then the backlog is unbeatable.
- Not everything is included. One of the hardest things for a project manager to understand is the fact that, backlog items are not necessarily committed for delivery. This is the opposite of the WBS. Everything, and only that, that is within the WBS is part of the scope. In a WBS, the additional is considered gold plating. The backlog is an instrument that offers priorities or order and, therefore, changes or discoveries natural to the development process of the product or service, can displace other features or requests that, in the light of new findings do not have the same priority.
- Beyond the project, the operation. The WBS is a closed tool that attempts to contain the entire scope, and therefore is not useful in environments where there is no defined scope. How could we manage a set of unexpected or unanticipated requests for a team? The WBS is not designed as a dynamic and flexible tool, and although it can receive changes and updates throughout a project, it is not a "dynamic element", as a backlog is.
3. Iteration Backlog - Iteration Backlog ó Sprint Backlog in Scrum
The Iteration Backlog refers to a set of things to do or complete in a period of time. If we talk about ScrumIf we are talking about Scrum, version 2020, the Sprint has a duration between one week and one month. If we talk about Scrum, previous versions or other authors, between two and eight weeks. But in general, the Iteration Backlog is the prioritized list of "things to do" during a fixed period of time.
The Iteration Backlog is not necessarily a subset of the Product Backlog or the Project Backlog. Of course, there should be a relationship between the two when they are used, but part of the iteration planning process is to detail, break down and complete the product/project backlog for the iteration that is starting. And, in this sense, it is possible that the Iteration Backlog has elements that were not included in the Product or Project Backlog.
4. Portfolio Backlog
Consider for a moment that your strategic portfolio - which includes several projects and other components - is a prioritized list. Why not use the backlog at the portfolio level? Prioritizing is an excellent idea to avoid what I have defined as the glutton syndrome - o consider that money is the only factor to consider when including or eliminating an initiative from the portfolio.
In management Portfolio LeanThe Portfolio Backlog is a fundamental tool. It also appears in the Scaled Agile Framework.
5. Program Backlog
When managing complex products or projects, it is possible to have a categorization of the backlog. Similar to what happens with a program and a project, the backlog can be a valuable tool to manage the pending work and priorities on a large scale, among multiple teams - of course, when the scale warrants it, that is, when there are so many people interacting that keeping everything centralized helps and hinders at the same time.
6. Equipment Backlog
If there is a program backlog, then there must be a team backlog. If, for the purposes of the big picture, we unify our "stack", for the purposes of managing a team - almost always agile - we need a reduced, focused version to manage. This is what is known as equipment backlog.
How do you properly manage a prioritized list?
The backlog, as we have already seen, is an instrument related to the work to be done, whether it is associated with the scope of the product or service, or with tasks associated with its development, maintenance and operation. Therefore, the backlog requires a lot of work and effort to keep up to date and not lose value.
In some management models, one person is assigned as the "keeper" of the backlog. In Scrum, this role is known as the Product Owner, or Product Owner. However, and since the backlog as an artifact is not exclusive to Scrum, we find roles associated with the care and maintenance of the backlog.
Roles in charge of creating and managing the prioritized list items
Although this is not an exhaustive list of roles, these are the most popular or common ones.
- Product Manager / Product Manager
- Product Owner / Product Owner
- Customer / Customer
- Customer or Consumer Representative / Customer Proxy
- Requirements Analyst / Business Analyst
- Documenter
- Project Manager* / Project Manager
Is the project manager in charge of the backlog?
It depends. The project director or manager is in charge of managing the project scope and, therefore, if he/she is in charge of managing, in predictive projects, the scope breakdown structure, why wouldn't he/she be in charge of the backlog?
However, in agile projects, where the backlog is used as a scope management tool, the project manager does not appear as a preponderant role. For example, in the management model of Scrum teams This is a clear separation between managing the scope, i.e., focusing on delivering business value, and managing the team. In this way, it provides a balance between wanting to do and being able to do. Likewise, this separation of responsibilities avoids ignoring the needs of the team and its performance in order to pursue and obtain business value.
Although not explicitly assigned, it is common to find project managers in charge of managing the scope - as Product Owners - and who manage or lead the team - similar to what could be understood as the role of the Scrum Master. [2]It is always discussed at length if project manager can exercise the role of Scrum Master. In reality it happens frequently, I personally consider that they are complementary roles and that, with the right skills, they can be exercised by the same person.
Advice for project managers.
The backlog is a dynamic tool that, unlike the WBS, requires much more commitment and dedication. If you enjoy as a project manager, taking charge of the scope, do not hesitate to add to the team a Scrum Master who facilitates and mediates the relationship you have with the team. Avoid being judge and party.
Why do the requirements change?
The backlog is a dynamic and open instrument. This means that elements within the backlog are regularly moved in, out and prioritized. Of course, with certain criteria and structure - which is dependent on the management model or paradigm you are using in your project or with your team.
Consequently, the backlog is ideal in environments where, for example, feedback is critical to define the future of the project (or product). An example of this context is entrepreneurship. Entrepreneurs need new customers and, in order to meet them, they quickly and frequently present their ideas for new products, services and advertising campaigns. If the response is positive, they go deeper into the idea, if the response is negative, they "pivot" and move on.
The backlog accepts and leverages feedback. A good team takes advantage of feedback to improve the capabilities of a product or service under development.
Refinement and keeping the backlog up to date
Let's remember that the backlog is a valuable tool in contexts where the scope of the product, service or project requires a certain dynamism. Managing the backlog is a demanding and very necessary task for the success of the project. It is not only about identifying what needs to be done, but also about structuring, prioritizing and ordering the work to achieve the greatest impact.
One of the activities that has taken more weight in recent years is what used to be known as Backlog Grooming and, for obvious reasons, is now known as Backlog Refinement.[3]The Cambridge Dictionary presents among its definitions of the word groomingone that has gained ground over the years and has become associated with criminal activity. This led to a modification of the term in the Scrum Guide of grooming a refinement. .
In the SAFe Agile at Scale framework, backlog refinement is defined more or less like this: [4]The translation of the backlog refinement is not literal and fits a bit into the context of this article - without changing its essence. To see the original text I invite you to browse the Scaled Agile Framework page.
The backlog should always contain some stories ready for implementation. That is, without major risks, deep uncertainties, or major surprises. Agile teams, by adopting a flow-based approach, try to maintain a certain level of "readiness" in their backlog. They do this by conducting at least one backlog refinement session per iteration or even per week. During this refinement session, higher priority stories are analyzed and an initial understanding of the acceptance criteria is discussed, estimated and established.
Scaled Agile
Tips for maintaining a good backlog
I wish I had a magic formula to share on how to manage and maintain a good backlog. I'd probably be a millionaire, but that doesn't mean we can't leave out some good tips to improve the chances of having a good backlog in our projects or with our teams.
1. Dedication and commitment
Unlike predictive projects, the variable and dynamic nature of the scope requires dedication and commitment to the backlog. In Scrum, for example, the role of Product Owner is full-time. Managing the backlog takes time. Forget the idea of reviewing the backlog from time to time.
Prioritize and empower the person who is the keeper of the backlog. All team members, and even stakeholders, are welcome to propose new elements, changes, and new priorities for the backlog, but only one person should be the one who ultimately accepts, deepens, and prioritizes the backlog - that's why I like the word gatekeeper. If you are doing Scrum, don't hesitate to assign your best available Product Owner full time.
2. Incremental thinking for the elements
The backlog is not just a prioritized list, what good is prioritizing if in order to complete the first priority items I need to complete the lower priority items? This mistake or agile anti-pattern is common in many projects that only care about fragmenting the plan into iterations, but do not go deep enough into how to structure the deliverables and components to allow the delivery of benefits in a continuous way. To avoid this, the INVEST criterion has been defined for backlog elements.
INVEST Criteria
The backlog requires elements that meet the INVEST criterion:
- Independent (I) - elements that are mostly "self-contained" and do not require other elements to demonstrate their value.
- Negotiable (N) - the backlog is not a closed element and, therefore, some elements of the backlog have to be completed and others do not. This means that, at all times, we must be able to negotiate the priorities and the inclusion or not of an element at a given point in the product.
- Valuable (V) - if the backlog is a prioritized list of items, well, the value is what allows us to prioritize it. While there may be low value items in the backlog, keeping them there when we've identified that they are of low value doesn't make much sense.
- Dear (E) - as a backlog item approaches the top of the prioritized list - that is, it is close to being considered for inclusion in the development or production process - it should be estimable. That is, the project or product team should be able to discuss how much effort, how complex, and how risky it is. To achieve this, the element can be detailed - in refinement sessions - or broken down - into smaller components that allow the team to move forward.
- Small (Small) - this criterion applies mostly to Team and Iteration backlogs. Items flow best through the system when they are small - a basic LEAN principle. However, a portfolio backlog does not necessarily have small elements.
- Verifiable (Testable) - in principle, every element of a backlog, as well as the elements of a WBS, must have certain acceptance and/or validation criteria. Otherwise, how can we know that something has been done and that it meets the established objectives.
3. Balance between anticipation and adaptation
The backlog is prioritized. There is a reason for that. Focus on what is most important and valuable for the product, service or project. If there is no focus, there is no point in prioritizing. Therefore, you should avoid at all costs trying to anticipate too much at the beginning of the project, or when the team is just forming. Finding the balance between anticipating with pre-design and adapting is fundamental to make wise use of the time of the business experts and the backlog keeper - i.e., the Product Owner's time.
4. Preliminary prioritization criteria
Much of the problem of prioritizing the backlog lies in the subjectivity of the gatekeeper, or the diverse interests of all the stakeholders - also known in English as stakeholders. A great technique can be to establish a weighted prioritization algorithm, process or mechanism that allows multiple dimensions to be taken into account when prioritizing. Scaled Agile Framework, for example, presents the WSJF as a prioritization exercise for the portfolio backlog.
I want to clarify that establishing prioritization criteria does not seek to eliminate the human factor of prioritization, on the contrary, it is an auxiliary tool that seeks to enhance the discussion and debate around priorities. We cannot always choose the elements of the backlog just because the person requesting it has a bigger office than us. In English, we use the term HIPPO or highest paid person in the office to point out the fact that sometimes there is no criteria and it's just a whim of someone with better pay within the company.
5. Percentage limits and funnels
Well, if the backlog is a dynamic element, and refinement sessions happen with some frequency, it may be a good idea to set limits for the amount of new elements to discuss, or improvements and refactors we iterate or consider during our sessions.
This can sometimes help to maintain focus and avoid an excess of experimentation that, in the end, leaves us with too many things to try and not enough things to add value.
In the same way it is possible to establish rules to exit or "die" within the backlog. For example, elements that never make it up and are always replaced by other "more important" elements.
6. Management tool
Management tools are useful and establish a structure to include, manage, update and plan elements. From post-its and acrylic boards, to advanced management tools in computerized systems.
Far from filling a tool with a lot of information, my recommendation is the consistency of keeping it updated, adjusting priorities, entering new items and discarding those that have been completed or are no longer considered in the plan - most tools automatically do much of this.
Things to avoid
Well, just like any other tool, the backlog has several considerations to avoid misuse or loss of effectiveness in a project, or with a team. These issues are:
- Excessive accumulation. Avoid including everything in the backlog. Although it is a flexible tool, it should also not become a memory chest or a saint alejo's room. It is common for the backlog to become a never-ending wish list.
- Need for detailed information. As I mentioned before, avoid losing the balance between anticipation and adaptation. You need an initial prioritized list to work from, but priorities dictate what the keeper should focus on. Avoid anticipating everything, the backlog is designed for "complex adaptive" contexts where part of the scope of work involves experimentation and feedback.
- Monolithic structure. It prevents backlog items from all depending on each other. This is not a simple task. To avoid it, it is good to develop an entrepreneurial thinking, where the big achievements are the sum of each of the small achievements.
Templates for backlog management
Is there a definitive template for backlog management? Of course there isn't. But that doesn't mean I can't share some very interesting ones. Here is a list of templates:
- Backlog Management Tool
Developed by Sperta Consulting. [5]Sperta Consulting is the company of which I am a partner. It specializes in consulting, coaching and training in team and project management and organizational structure.. This is a tool we use for academic purposes to discuss, above all, the impact of iterations on the progress of a project. Far from being perfect, it helps to establish deep discussions with the exercises we do in our courses.
- Agile Project Plan - Template
Developed by SmartSheet. It is a very comprehensive tool - and therefore, a bit complex.
- Templates for 14 and 30 day Iterations.
Developed by Mitch Lacey and Associates.
I personally don't use templates in my daily work - or it is very very rare, but they are very useful for academic processes. They are easily manipulated and customizable to make a point, a concept or benefits and disadvantages.
In our time, it's more common to use a cloud-based agile team management tool rather than a shared spreadsheet file.
Final Considerations
The backlog is a really powerful tool. A good backlog is key to team agility and incremental development of products and services. It is a great ally of agile projects and an essential part of lean portfolio management.
However, it should not be considered just a to-do list.
Author's comments and notes
Hi Alberto, very good article, it relates the main concepts of the backlog and expands it to portfolio level, which invites me to investigate further on the subject. I have a question and it is the concept of release, is handled equally for all types of backlog?
César, I'm glad you liked the article. About your question, a small reflection. If the goal of prioritizing is to deliver business value in an early and staggered way, it is ideal to use the backlog hand in hand with a release plan. But that doesn't mean that there should always be a release plan. My recommendation is to always have milestones tied to dates and thus have a way to validate progress. When there are no milestones set, it is impossible to measure progress with a tool like a backlog. I'm about to publish another article on metrics that comes to the point. If there is no release, what are you measuring your progress against (especially on projects).
Hello Alberto,
Excellent article, I learned a lot of interesting things reading it! I have a question, which is partially answered in the article, but it would be interesting to have a very precise point of view: in "open source" projects we can often find endless backlogs that get out of control. While this is consistent with a project of variable scope (as is often the case with this type of project), what strategies can administrators/project managers put in place to avoid an out-of-control backlog and at the same time avoid frustration/frustration among collaborators?
Mauricio, excellent question! Indeed, many projects and products suffer from backlogs that look like a wish list. In particular the backlog of FOSS - Free & Open Source Software - seems like an endless list - and that's partly the idea. Open source has as a principle the decentralization of code and, many times, that implies decentralization of priorities. To maintain focus - which, I think, is what generates the most frustration, I recommend:
Conduct regular sessions of roadmapping. They can be quarterly, semi-annual or annual - it all depends on how involved the developer community is.
Assign a central prioritization point - something similar to what happens with the Linux Kernel and the role of Linus Tolvards.
Establish voting mechanisms for the general public to help prioritize new features.
I hope my answer helps you.