Story prioritization at the "Blink" of an eye
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!