Project Practitioners > Story prioritization at the "Blink" of an eye

Story prioritization at the "Blink" of an eye

By Brandon Carlson

It was late July and I was sitting through yet another agonizing prioritization meeting. The sounds of debating product stakeholders filled the air, each weighing in on his or her pet feature’s relative merit, desperately trying to inch it toward the beginning of the development queue. I was physically present but my mind was elsewhere, thinking about how ridiculous the act of prioritization was, how every organization I had been to suffered from endless debates around it, and how nobody seemed to think there was anything wrong with the way it was being done.

As my mind drifted, my thoughts turned to Lean concepts and the elimination of waste. How much actual value was being delivered by this room full of people? Here we are, six or so highly paid professionals, and nothing was really getting accomplished. Even worse, this wasn’t just an occasional prioritization meeting, this was an hour and a half of my life every week. Every week the same discussions come up because a “customer complained” or “we just lost a sale because of this”. Doesn’t Lean have a thing or two to say about rework? I decided something must be done, but what? Prioritization, to the best of my knowledge, is a necessary evil for any project, especially those of the Agile flavor, so we can’t get rid of it. Another option then was to automate, eliminate the debating and try to make the whole process more scientific, more efficient. When I solicited input from the product stakeholders on how to make prioritization automatic I was met with comments such as “You can’t man, there are just too many factors”, or “It’s a gut thing, how do you automate that?”. It was the latter that stuck with me, I just didn’t believe it. There’s something driving your gut instincts, but what is it?

Later that week I was settled in for my daily commute and fired up an audiobook to keep me company. The book I had chosen was one I had read earlier but never took the time to really digest. It’s called Blink, and it’s written by Malcolm Gladwell. In the book, the author explores the split second decisions we make every day and how and why we make them. He introduces the concept of “Thin Slicing”, that is, identifying small pieces of information within a larger context and using them to make a decision, ignoring the rest. Gladwell’s position is that we are masters of thin slicing and we do it subconsciously. The book cites an example of how doctors at Cook County Hospital improved patient care and throughput using the technique. I thought to myself, if doctors at Cook County Hospital can use a small subset of relevant attributes to effectively prioritize patients in life or death situations such as an ER, it could certainly be applied to even more important decisions such as the prioritization of features, right?

So off I went to the next prioritization meeting with a plan, we needed to quit spending time on irrelevant details and focus on the most important issues. I discussed my thoughts on how the prioritization meeting was sick and that I had just the medicine: Thin Slicing.

The team agreed to give the ideas I had been formulating a shot and accepted a single task for the next prioritization meeting: Think about the attributes that you use to formulate a priority decision. Make a list of those attributes and bring them to the next meeting.

Another couple of weeks passed by before we met again and pooled the results. What we ended up with was a consolidated list of about 15-20 attributes that drove the prioritization of features. Some of the features were obvious, contractual obligations, market windows, and customer impact. Some, however, were not so obvious (but probably should be), system health and corporate strategy (duh!) to name a couple. Once we had our list, we decided that each attribute needed a score from 0 to 3. Zero being not applicable and three meaning high positive impact. Once we had our scale, we needed to score the attributes for each feature in the backlog. As it turns out, this is where the secret sauce comes in.

Each person in the prioritization meeting is there because they have a stake in the product; it directly impacts their work. The problem is, the product impacts each stakeholder in a different way! How does the architect know about the impact of a feature on customer service? She can give it a shot, but ultimately that’s not where her specialty lies. In light of this information we assigned an owner to each attribute on the list: the stakeholder that knows the most about the attribute in question. For the architect, she only has to score system health and, as the owner, she is the only one who gets input into the score. The same holds true for all the attributes, contractual obligations? Sales Manager. Customer complaints? Customer Care Manager. You get the idea.

Once all of the stakeholders have scored his or her own attributes, the scores are tallied and the features with the highest positive impact to the product float to the top of the list. No debates (Ok, a few, but not like before), just numbers.

Since making the switch, we have witnessed noticeable improvement in the productivity of the meetings. The baseline priorities are set in first few minutes of the meeting and the total meeting time has dropped significantly, from an hour and a half down to 30 minutes.

Are you stuck in prioritization hell? If so, story prioritization in the blink of an eye is an effective solution and amazingly easy to implement. You can identify your attributes and their owners in about 30 minutes and completely prioritize the backlog in another 30. Give it a try and tell me how it goes!

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Brillant! Nice work, really.

Very nice summary.

Influenced by the same book, I introduced a similar concept to a group of Product Owners. It had the effect of breaking the communication deadlock. Since broken, the PO's moved on and now manage well face2face.

Nice. I like the way you move to a quicker decision without trying to do a complete analysis. I think that's very valuable.

Doesn't the procedure you follow amount to majority rule (though with multi-valued voting)? I can see circumstances where some important considerations were starved for attention because they were important for fewer people in the meeting.

Years back, I attended a session that Ellen Gottesdiener presented on "Decide How To Decide." Voting, or consensus, may not always be the best choice. These decision mechanisms are often used without further consideration. I would think about this, and keep an eye on the decisions made.

It all may be fine. Or you may find that reducing the decision making to a mathematical formula has unintended consequences.

Best of luck, George.

This approach sounds interesting.

Personally I believe it can be more intuitive whn you have a single Product Owner.

However, when you don't have the benefit of a single Product Owner, perhaps because you're developing central software formultiple busniss units, I think this approach could be useful.



Thanks for the feedback. The approach we've taken works pretty well for us so far. Sometimes, the score we came up with for a feature is lower than another so we move them around a bit. We then discuss what attributes are at play that cause us to re-prioritize and add them to the model as well for future stories. We have also run into issues of certain stories being starved as you suggest, and have dealt with them through open dialogue.


We actually do have a single Product Owner, and he's the one that gets all of the questions "Why didn't you do feature A but instead picked feature X?" One of the reasons we've adopted this model was to bring some transparency to the decision making process and show some of the criteria for our decisions. Thanks for the feedback!


Yes, this really sounds like a good approach, if the number of attributes can be kept to a manageable number, and I think is equally relevant now (4 years later)

What about scaled attributes i.e. attributes are more important than other?


We did not consider scaling the attributes in any way. One of the driving forces behind using this process was it's simplicity. We had multiple viewpoints about what was important, and how important (scaled) each should be. I wonder who would place the scale values on each of the attributes? I could see where that would be useful (say, portfolio level) if the attributes were scaled the right way.



Hi Brandon, really interesting approach, and valuable.

I think I misunderstood the part when you comment that each stakeholder is "mapped" (owns) a given attribute.

Isn't this definition introducing (again) the discussion between the priority of Story "Foo" that was prioritized using Attribute A (owned by Stakeholder 1)
and Story "Goo" that was prioritized using Attribute B (owned by Stakeholder 2).

Hope I made myself clear! (I'm a bit rusty on my english)

In a


Thanks for the kind words and comment. I believe that the scenario you've described is possible, however in practice I have rarely observed it. I believe that it is due to the nature of the attributes. With each stakeholder "owning" 5 or 6 attributes, there are rarely stories/features that are scored "3" across all of them. Consider customer service. Their attributes may be something like:
- Renewal Horizon
- Customer Temperature (Angry, happy?)
- Customer Impact (Broad, Narrow?)
- Customer Size
- Problem Type (Nuisance, Showstopper?)

Now, your typical issue doesn't rate high in all 5 of these categories, it tends to be a mix. Stakeholder 2 has similarly broad attributes that make ties less likely. The more stakeholders and attributes you have, the less likely these types of discussions are required.

Hope that helps!

Hi Brandon,

Thank you very much for sharing your experience. Do you have tool support to your decision-making process?

Thanks, Emilia


Indeed such an interesting post.

I've a question, born from the reading.

First I need to be sure I understood the most You say 1.- "priorization meetings are a pretty hell mainly because it is very hard to get an agreement".

2.- Then a logical, but until your post not obvious ,consecuence is: To avoid arguments lets say the value you give to this feature.

3.-So there is a meeting to fix all different criteria different stakeholders must evaluate.

My questions.

1.- It is great having a set of valuebles points of view of every stakeholder involved in a new feature definition. Then... Why to Keep meeting for priorization?. They could send to the product owner (i assume) information by email and he can priorizate without any Discussion.

2.- May be i couldn't get you totally, but. If every single stakeholder (I mean key or involved stakeholders) has a set of criteria to evaluate. How to decide what criteria is more important? I mean. Client service could have as you said in your kindle response to Marcelo Renewal Horizon
- Customer Temperature (Angry, happy?)
- Customer Impact (Broad, Narrow?)
- Customer Size
- Problem Type (Nuisance, Showstopper?)

Imagine that Billing department is involved with other criteria that could be against those.
What of those criteria are more important? Is this scale fixed on a previous meeting?

Thank you for you time and kindly answer

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.