 | Backlog Prioritization |
A backlog is not a backlog unless its tasks are prioritized according to which should be built first. It may be tempting to assume that you should simply go in the order of the user workflow. If we’re building a Chinese vocabulary app, why not start with the login, then build the top level menus, and then work down to the sub menus?
Here’s why: some processes are simple and familiar, while others are complex and/or uncertain.
Priority should occur based on the following:
Initial Ordering of Priorities
1.Sequential Necessity
Items that must be completed before work on others can start
2. Risk / Uncertainty
Items which represent new challenges for the development team, i.e., no one has experience from a prior project, and therefore, it is difficult or impossible to estimate the amount of time required to complete the item successfully (if at all, given the budget and scope of the overall project)
3. Business Value
The relative value that the item will bring to the overall product (or the loss in value if it is not built)
Important: the order will flip!
At the beginning of a project, sequential necessity will usually come first. As the project progresses, however, most of the essential sequential items will be built, and any remaining sequential “necessities” probably won’t be as crucial.
Keep in mind that company owners, executives, and marketers will always push for business value. Developers, on the other hand will tend to push for technical stability. This is precisely why the Product Owner role is so important, and why the PO is in charge of prioritizing the backlog. There always will be tension between what is essential to the final product and what is essential to having a well-organized build on the backend. If the business team or the development team were to get their way entirely, you would likely end up with what they consider a “perfect product,” but one that would ultimately fail.
Whenever possible, Agile promotes business value above all else. Therefore, a project is more likely to be optimally successful if/when the above ordering is flipped. This flip should occur as early as possible:
The Flip to Optimal Priorities
1. Business Value
We always want to be focusing on quick, simple releases of our product so that we can get feedback and pivot the project direction as early as possible. Giving users features they can use (and hopefully begin paying for immediately) will help our project’s cash flow (insuring that we can keep building) and prevent us from building unnecessary features. If possible, we want every iteration of our product to include a significant amount of business value, even while working on backend necessities.
2. Risk / Uncertainty
Risk is always to be minimized, but the scale of risk in backlog items should greatly decrease as the build progresses
3.Sequential Necessity
“Necessities” or “dependencies” for the product to function, but not integral to its business value. These may also be key elements to the stability of the product’s back end, but not something that the user would necessarily even be aware of. These items would therefore have little to no bearing on a potential user’s decision to select this product over competing products.