A Practical Approach to Agility and Product Management

Tag: planning

Nail your Backlog Priorities by Figuring out Return on Effort

Prioritization of work is hard: it’s often more an art than a science. Unless you work in an organization that has mastered the delicate balance of work from a prioritized roadmap as well as customer requests, you too may often be faced with squeaky-wheel prioritization: The customer yelling the loudest (or the one who last spoke with sales or the CEO) gets what they want.

We product management professionals thought there must be a better way to figure out prioritization, one that’s more “scientific” and less subjective. So various schemes for prioritization emerged from the industry, looking at the benefits of features such as new revenue, customer retention, cost savings, … you name it. Either one or multiple of these factors were being considered and summarized into terms such as “business value”. Agilists quickly pointed out that absolute values (e.g. dollars) make things hard to compare and that measurements are often imprecise, so we started thinking in relative business value points.

Great, so now we have a way of systematically prioritizing our features, right? As long as we work our way down our feature backlog in descending order of business value, we’re making sure we deliver the most value to the business and we solved the problem of old-school prioritization, right?

Well, not so fast, cowboy… (Continue reading this post on MindTheProduct where it has been published in its entirety)

Reducing Variability and the Airport Omelette

Like many times before, I was sitting in my favorite airport restaurant before my first flight and enjoyed my typical egg white omelette. Then I questioned myself: why don’t I eat breakfast at home instead and leave later for the airport? That didn’t feel right (apart from the fact that my home cooked omelettes don’t taste as good), until I realized there was a deeper reason for it: Eating at home meant leaving later, which would increase the likelihood of hitting traffic on the road and longer lines in the airport. Leaving later would also reduce the safety buffer I can rely on if something unforeseen happens. If worst came to worst, I could skip my airport breakfast and chow down a bar instead and still make my flight. If I ate at ours have that safety buffer.

Taking a step back, making a flight as well as completing work projects on time is about increasing predictability. One way to do that is to reduce schedule and other risks by eliminating variability early on in the process. So if a project consists of multiple sequential steps, it makes sense to eliminate variables as early as possible and take on those tasks that have the highest possible variability first (assuming the tasks can be resequenced accordingly).

This is very much in line with Agile’s recommendation to take on those stories and features with the highest level of technical risk first. It’s all about reducing risk and increasing predictability.

Wait, you might say, doesn’t SAFe propose to preserve options and defer decisions till the last responsible moment? Yes. If these options bear the same amount of risk and variability, doing so may not necessarily increase project duration and risk, but it certainly doesn’t remove variability early on. The goal here is to stay responsive to changes in market and business demands and not place technical bets until necessary.

In practice, one will need to find the right sweet spot between reducing variability and preserving options as those two approaching are some what opposites sides of the same continuum. SAFe practitioners are, at the end of the day, also incentivized to be predictable and meet PI commitments, if possible.

Now that I understand why my usual airport omelette actually helps me make my early flight, I will certainly keep my eyes open for other opportunities in my life to reduce variability and increase predictability where it matters.

Predictability in Agile Delivery

It comes at no surprise that predictability of Agile delivery is a big deal. I would define it as the team’s ability to predict with reasonable accuracy which backlog items they will be able to complete either by the end of a sprint or within a certain timeframe (in case of Kanban teams). And predictability scales up: multiple predictable teams may make a shared program they’re a part of predictable and multiple predictable programs combine to a predictable portfolio. Organizational leaders look for predictable delivery in order to be able to make business commitments.


Nonetheless, I’ve always been quick to point out that predictability may not always be what one wants to optimize for. A key factor affecting the importance of predictability is where a product is in its life cycle. A very young product at the beginning of its life  will not require predictability. For such a product, especially if the organization follows approaches promoted by the Lean Startup, focus will be on defining an MVP and releasing it to the market as soon as possible, after which point the team will attempt to validate learnings as quickly as possible and pivot where necessary. Under these circumstances, iterating on the product quickly will be imperative. Therefore, I concluded, predictability is not important under these circumstances but something only more mature products (or larger, traditional organizations) require, right?

Recently, I realized that this it is the wrong question to ask whether a product requires its team(s) to be for what timeframe a development team needs to be predictable. If I’m iterating on my startup’s MVP, I need to be predictable, but maybe my planning horizon is only a week or two. If I’m maintaining a mature product, I may require high predictability in order to forecast 3 to 12 months out. Another factor necessitating high predictability is a market requiring long-term commitments from the companies serving it. Since the need for predictability is a function of the product needs, it’s quite possible that a well diversified company may have multiple products where the answers are different.


One caveat is that for the same product, one usually has to decide and pick one or the other: do I want to be highly predictable or highly responsive and able to turn on a dime? In most cases I can’t have my cake and eat it too.


My takeaway from this is: predictable delivery is always required, but it’s important to determine for what time horizon teams need to be able to make commitments and why.