The Importance of Prioritizing and Sizing Your Backlog for Agile Planning

Prioritized and Sized Backlog

For agile planning to work, you must have a prioritized and sized (estimated) backlog. A prioritized backlog is simply a list of work that needs to get done that is ordered by priority. Essentially, the work at the top of the list is the most important and should be done first. In many cases, customers have a difficult time prioritizing lists of features, however, this makes the prioritized backlog even more important to produce. Another requirement of this backlog is that each of the items must be sized, which is another way of saying that the item should have an estimate. The difference between sizing a backlog item and estimating it, however, is that Agile teams would much rather provide an estimate of the size of an item, using some arbitrary sizing scale than attempt to determine how many hours it will take them to complete the work.

Prioritizing a backlog should be a very simple exercise. Customers should be able to take any two items in the backlog and specify which of the two items is more important to them. The one with higher importance should be at the top of the backlog. This form of prioritization is called binary prioritization and can be used to sort the entire backlog from highest priority to lowest priority items. An alternative to binary prioritization is to use simple prioritization classifications, such as the MoSCoW model, where customers rank each backlog item as Must have, Should have, Could have, and Won’t have. The drawback with priority classification is that often customers simply mark everything as“Must have” or “Should have” priorities.

It turns out that combined with some additional techniques, such as velocity calculations, sizing can be even more accurate and much easier to provide by the team. During backlog sizing, teams are asked to use an arbitrary numbering scale. For example, some teams use the Fibonacci sequence (1,2, 3, 5, 8, 13, …) [minus the first 1 in the scale], some others use the prime number sequence or even simply powers of 2 (1, 2, 4, 8). Some additional teams have very simple scales such as (1, 2, 4, 8, too big). In all cases, however, sizing works in the same way. First a team will agree upon a backlog item that is of “average” size, assigning that item an average number in the scale. Every other item in the backlog will be compared to this average item to see if it is larger or smaller and by what magnitude.

For example, suppose the team chose “Enter Customer Details” as a backlog item that they found to be “average” and assigned the number 5 on the Fibonacci scale. Another backlog item might be “Enable Authentication” and the team considers this backlog entry to be a smaller amount of work than average, in fact about twice as small, and thus assign the number 2 to its size. For another backlog entry, “Encrypt Credit Card Number,” the team considers this to be more than twice as big as the “Enter Customer Details” item, and assigns the size of 13. 

Sizing works well because teams have a much easier job being accurate regarding the size of a backlog item compared with creating an hourly work estimate. Teams can then use this size information to calculate a team’s velocity, which happens to be an extremely accurate measure of predicting future work. Please refer to the Iteration Velocity and Capacity charter for more information.

Uncertainty and Maturity

Not all requirements will be ready when your building commences, so take into account uncertainty and maturity. For example, several items at the top of your prioritized backlog may simply not be ready to implement. These items might be the highest priority, however they may not be completely defined (immature) or may not be valid (uncertain).

If you want to know more about Agile planning, download our free e-book- The Ultimate Agile Planning Handbook. It addresses the following topics:

• Timeboxing
• Optimizing iterations
• Prioritizing and sizing the backlog
• Using uncertainty and maturity to improve prioritization
• Improving predictions using velocity and capacity and more
• Most common challenges related to plannig and how to overcome them

Do you need a tool to manage your agile projects?
If you haven’t tried TeamPulse yet, try it now!