See if this problem sounds familiar:
Your agile team runs a series of sprints, always doing the highest priority work as chosen by your product owner. But after that series of sprints, you look back at what the team accomplished. And it’s not very satisfying. All the team seemed to do was move from emergency to emergency, putting out one fire after another.
The team very likely got a lot of work done. But it doesn’t add up to much.
What happened? You fell into the trap of prioritizing based on what seemed most urgent at the start of each sprint, a frequent side effect of the iterative and incremental nature of agile. There’s a better way.
The Agile Prioritization Trap: Selecting Work Each Iteration
Selecting whatever work seems most important at the start of each iteration can be sub-optimizing in some cases. It can lead product owners to prioritize work on the crisis du jour, whether that’s
- A hot tech support issue
- Something that cost a sale yesterday
- The latest whim of an important stakeholder
While any of these may be the most important thing to work on, all too often they are not strategic. And by choosing to work on whatever someone is screaming about in the moment, the product owner forgoes the opportunity to make progress on something bigger, more important or more strategic.
Prioritizing Without Goals Is Like Scaling Mountains without Maps
My fellow residents of Colorado and I are proud of our 53 “Fourteeners,” which are mountain peaks that are at least 14,000 feet high (4,267 meters). There are two ways to summit a Fourteener.
In the first approach, you simply drive to the base of the mountain and start hiking toward the highest thing you see. That will almost certainly be a false peak, which only appears to be the summit because it obscures the real summit.
But, having climbed the false peak, you can now see a higher peak. Believing it to be the true summit, you climb it. And discover that it, too, is a false peak.
You proceed this way until you finally do see the true summit. But between you and the summit is a deep valley. And to reach the 14,000-foot summit, you have to first descend 10,000 feet before climbing back up.
Clearly, this is not a good way to summit one of Colorado’s Fourteeners.
The second approach involves buying a topographic map at a local hiking store. Equipped with the map, you can then plan a more efficient route up the mountain that avoids the need to descend and re-ascend 10,000 feet.
Multi-Iteration Goals: The Product Owner’s Map
For the agile product owner, the equivalent of the topographic map is having a larger, multi-iteration goal. Without a multi-iteration goal, the product owner is merely climbing from false peak to false peak. That product owner and team may eventually arrive at their ultimate destination, but often only after descending and climbing out of the equivalent of the 10,000-foot valley.
It’s so tempting, though, to address those short-term crises instead.
First, it gives the product owner a sense of accomplishment: Something has been completed and can be ticked off the to-do list. Second, it appeases whoever is asking for the immediate solution. Most of us like to please other people, and this does that, often with only an invisible or unacknowledged impact on the bigger, longer-term, and usually more important goal.
When Prioritizing, Remember What Is Urgent Is Seldom Important
United States President Eisenhower knew how critical it is to distinguish between important matters and urgent ones. Although history is unclear on whether Eisenhower actually phrased it this way, he is often quoted as saying,
“What is important is seldom urgent, and what is urgent is seldom important.”
However he phrased it, Eisenhower was saying that those urgent crises we all get tempted to work on are not usually important in terms of achieving our overarching goal.
A good product owner will be careful to consider both the importance and the urgency of product backlog items when prioritizing work for the team.
Product Owners Should Identify a Significant Objective Quarterly
But if a product owner doesn’t know what it’s important, the urgent will always win. And this leads to the unsatisfying series of sprints I described at the start of this post. When an agile team goes from urgent issue to urgent issue, the immediate gratification fades as the team and the stakeholders realize no progress was made toward more important goals.
This means it’s vital for a product owner to define an important significant objective. I find that the best significant objectives will take the team about three months to accomplish.
Taking more than a single iteration is important because it focuses the team on a longer time horizon. This means the significant objective should be an important business result, such as migrating a portion of a system to a new technology; adding a big, important and noticeable feature; or any number of things.
But it needs to be significant. For a new product, it could be creating a minimum viable product (MVP). For an existing product, it might be adding a minimum marketable feature (MMF). Some organizations will refer to it as a wildly important goal (WIG).
Equipped with a significant objective—whether in the form of an MVP, MMF, or WIG—the product owner will be better able to assess urgent needs. If addressing an urgent issue is more important than working toward the significant objective, by all means the team should be directed toward the urgent issue.
The intent of establishing a significant objective is not create a slavish devotion to a multi-iteration goal. Rather, it is to establish a mechanism to support the product owner’s prioritization decisions.
Without a significant objective against which the importance of urgent issues can be compared, the urgent will always win.
