When we look at a long list of tasks to complete, we sometimes lose focus on deciding which ones really matter with regard to any specific criteria that would give us the intended outcome. The simple answer is to say that everything on the list is urgent and important, but it isn’t always true. Sometimes level of importance changes with time and it is for that reason (or at least one them), that we have separate backlogs for each sprint in an Agile project. There’s a list of tools that we can use in Agile that would allow us to sort it out, however we need to change our mindset first before we go there.
How do we know what needs to get done first?
When we look at all features we would like to build into our product, we tend to get an indefinite sense of their importance. Common thinking will naturally lead everyone to say that everything in that backlog will need to be done. It may be true, but as we know there are factors to consider before giving all items in a list a high priority. The other issue is that most of us think we know what we want, but then are influenced by factors that are not necessarily our own. From a business stance, we may be acting on behalf of another group of stakeholders, so outside influence might be a consideration to some extent. In certain cases, where there is very little known about a product we are about to develop, an event called an Agile Spike used to elaborate and analyze the feasibility of a suggested product.
Can We Determine the Difference Between Urgent and Important?
The first, but often skipped step in prioritizing agile solutions, is to create backlogs with an order based on a fixed set of criteria. Even then, we tend to group items that are urgent and important into the same batch. If we look at the list during agile planning and think in terms of reducing risk, we may be able to get a clearer idea of which items we need to address first. Also keep in mind that risk and value have an inverse relationship, wherein if we reduce risk, we are also increasing value. To think of this in other terms, if we had a usable product that was absolutely risk-free after purchase, we would certainly value it more than it’s risk-prone alternatives.
The second way to look at prioritizing our feature list of items is by looking at potential return on investment (ROI) especially as part of agile release planning. When we get a feature that resolves the majority of risk, but also gives us a monetary return, it should be included as part of a strategic agile product management plan that increases potential for profitability and long-term sustainability. Hence by prioritizing we give ourselves the benefit of continued growth to the business.
Lastly, we can look at what to prioritize from the current market outlook. This would either be in regard to latest or upcoming technologies, purchasing trends, expert insight, demographics, etc. If we anticipate that there are certain events that will take place in the near future, we can give priority to our backlog items.
Recommended Tools:
MoSCoW method, High-Medium-Low, 1-2-3-4-5, Priority-Impact Matrix, Action-Priority Matrix, NPV.
How do we narrow it down?
As always, agile processes are constantly evolving and this is where regular agile courses and agile consulting can add value to your entire organization. There are numerous ways we can prioritize a backlog and structure the thought process. The main point to consider is that we should not base it on a random set of criteria, but rather a more decisive one in which an agile working team can have a fixed set that is used throughout prioritization activities. Your criteria should resonate with overall business goals and targets. The key is to avoid making it overly tedious try to establish the activity as an agile games session (i.e. planning poker), and establish a set of 3 to 4 criteria that everyone agrees on that would facilitate prioritization and make your efforts worthwhile.
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
