In the modern world struck by volatility, uncertainty, complexity, and ambiguity we are still pushed to estimate our work accurately. Some say estimating is stressful and counter-productive. Some say it's essential for tracking the team's progress. There is an alternative parallel universe way of working, forcing you to refine and split your work to decrease the feedback loops.

Categorising and prioritising planned work by uncertainty is a practical skill I learned from a product owner I worked with. We didn't waste time throwing around story points or hours for estimation in that project. Instead, we meticulously assessed how risky moving forward with a proposed change is. In agile software development, it's crucial to understand the consequences of your actions so you can react and correct the course as fast as possible.

The technique I use is relatively simple. I like to map uncertainties on two levels: business and technical uncertainty. I refer to these in T-shirt sizes from XS to XL because they are usually more helpful than arbitrary numbers. The levels are as follows.

You may wonder where do you find this mythical data to back up the claims whether a change is risky or not. The simplest way to gather data is to set up a proper CI/CD pipeline enabling continuous A/B testing in production. Doing so decreases the feedback loop in your decision making, thus eliminating the uncertainty.

If you want to know whether your users benefit from something or not, deploy the change now — and roll back if it was a wrong decision. There is an only effective way of agile software development called DevOps.

Assuming you now have two metrics describing relative uncertainty, how do you use these two together? A fruitful way is to use a whiteboard.

An entertaining exercise in teams is to write down the planned features and ideas on post-it notes. Then we draw four quadrants according to how high the uncertainty is from a technical and business perspective. Next, have each proposed feature placed into one of the quadrants. You should now see a rough picture of what you can make vs what you should make next.

Prioritising work using the uncertainty quadrant is swift.

Low Technical Uncertainty & Low Business Uncertainty. These features are smooth to implement, and we need them. Therefore, we place them on top of the backlog.

High Technical Uncertainty & Low Business Uncertainty. These features are needed, but technically they might be challenging to implement due to, e.g. bad architecture, incompetent design, or rampant technical debt. In the latter case, make sure to allocate time for refactoring and rewriting parts of the codebase to decrease technical uncertainty.

Low Technical Uncertainty & High Business Uncertainty. These tend to happen in greenfield projects where the codebase is fresh, yet stakeholders fight for their unique vision of the minimum marketable product. Consider these low priorities until business uncertainty is decreased through better analysis and refinement actions.

High Technical Uncertainty & High Business Uncertainty. These features don't fit well in our product vision or current tech stack, but they could probably be part of another product. Leave these out altogether.

With the priority laid out for all to see, it should now be easier to pick the next most important feature to work on. Then aggressively slice the feature into the smallest possible stories and work on them with the whole team keeping the team's inventory (work-in-progress) as low as possible. Once you get familiar with this technique, guesstimating with story points begins to feel like an ancient practice akin to writing programs on punch cards.