Prioritization and backlog management are two sides of the same coin. As described in the BABOK, an important difference is that backlog management is a more specific case within the broader topic of prioritization.
The BABOK discusses prioritization in terms of business analysis information. Backlog management typically involves tasks or work items. As a practical matter, the criteria on which prioritization is carried out in both cases is the same. Considerations involve value, risk, difficulty of implementation, dependencies, and so on.
It seems to me that prioritization can involve qualities of a design or approach, determining which customers to serve first, and the order in which tasks should be worked on. While backlog items typically involve defined collections of work to be done, they are ultimately driven by the same, more general considerations.
A very important consideration in prioritization involves recognizing and making trade-offs of various kinds. Many types of trade-offs are possible, and all involve the economic way of thinking. Economics, after all, is best defined as the study of making choices under conditions of scarcity, and this involves the recognition that we always live and work under conditions of scarcity. One discussion on trade-offs is embedded in a webinar I gave on What Business Analysts Should Know About Software.
While this specific talk involved software, you can imagine that different trade-offs will be germane to other potential products and services. Considering the iPhone, for example, Apple could not produce them in every possible color. Instead, different color options (moving in a direction from conservative to increasingly bold over time) have been released only slowly, to where there remain only six color options after fifteen years. That is, the designers and managers at Apple had to look at the costs and practicality of producing devices in different colors.
Computing
• execution speed
• response time
• memory usage
• disk usage
• clarity
• modularity
• maintainability
• reusability
• abstraction
• language choice(s)
• protocols
• scalability
• uptime
• security
People and Methods
• developers
• managers
• data collectors
• analysts
• testers
• users
• customers
• speed of development
• reduction of rework
• popularity of languages and tools
• industry trends
• larger societal trends
Cost
• capital vs. ongoing
• fixed vs. variable
• licensing
• hardware
• third-party
• maintenance and support
• upgradability
• modifiability
Another classic discussion of trade-offs involves the Iron Triangle of cost, time, and quality (or features). I have written on this often.
The BABOK describes four different approaches to prioritization in its formal description of the technique:
- Grouping: Assign generic priorities like high, medium, and low, and work through them in order by grouping.
- Ranking: Rank items in a specific, relative, individual order as opposed to a limited number of generic buckets (as above).
- Budgeting and Time Boxing: Prioritize based on resources available. This often involves time or money, but other considerations are possible. This is especially germane when the quantity of the governing resource is fixed. This means you do what you can with what you have.
- Negotiation: Place items or considerations in order based on explicit stakeholder and participant discussion.
Note that decisions on prioritization will sometimes have to be made in the absence of complete information. This is both inevitable and utterly unavoidable. Specific metrics and evaluation criteria should be used when they are available, but when they are not the participants will have to make entrepreneurial judgments on the best way to proceed.
Entrepreneurial judgements should use the best data available, even if it is not perfect. I go into detail about estimation here.
Backlog management involves determining what to do and when to do it. The main current use of the term backlog is probably in the context of Agile projects using Scrum and Kanban techniques as shown in the diagram. However, backlogs can and do occur in every kind of management environment. Statements of work, To-Do lists, punch lists, trouble reports, customer requests, and so on are all examples of backlogs that must be prioritized, managed, and worked off.
Backlog management involves all aspects of how backlog items should be added, tracked, described, prioritized, continually reviewed, worked on, and ultimately removed from the backlog. The purpose of the backlog is to ensure that items are worked on in the order that provides the greatest value first. That said, individual items may not directly provide value themselves, but must be completed to support other items that do.
The BABOK provides the following specific examples of backlog items, but notes that the possibilities are endless.
- use cases
- user stories
- functional requirements
- non-functional requirements
- designs
- customer orders
- risk items
- change requests
- defects
- planned rework
- maintenance
- conducting a presentation
- completing a document
Items in the backlog may exist at different levels of maturity, granularity, and clarity. The items at the top (or front) of the backlog queue should be clear, defined, granular, and complete so they may be worked on with minimal clarification or additional guidance. Less well-defined items may be added to the bottom (or back) of the queue and will need to be revisited, clarified, broken down, and made ready for work as they migrate toward the beginning of the queue. Backlogs can be continuously reprioritized as conditions, needs, and understandings change, and so they should in no way be thought of as FIFO (First-In / First-Out) queues.