Priority Mechanisms

Font is Marker SD

Setting priority for tasks is essential to agile/lean software development. Agile teams strictly limit the number of tasks in flight in order to have greater efficiency and effectiveness. The improved focus means code is completed sooner (not faster) and that product may be delivered to production more often. This focus is frustrated if we have too many "#1 priority" items and "emergency" items thrown in on top. Controlling the flow makes teamwork possible, and actually speeds the process.

We sometimes refer to the system that filters tasks into priority order as the magic funnel. All tasks and features are metaphorically dumped into the top of the big funnel. Ideally, the first (or next) item that falls out of the bottom of the funnel is the absolute most important thing we could possibly be doing. It has won the prize. It is the task we should be working on.

Setting priority is unsurprisingly one of the hardest things a customer can do. Do you pick the story that satisfies the most "important" customer (where "important" varies daily, almost hourly, and by which person you ask), or the greatest number of customers? Do you pick tasks that you think will bring the greatest number of new customers, or please the existing customers? Do you streamline processing or go with aesthetics? What makes one story more valuable than another?

Since the problem is large, and depends on local standards, there are many ways of prioritizing stories. The method shouldn't be something a team should agonize about for weeks. The most important point is that the product owners are able to reach a consensus, and that the features they pick are truly important. Tactics can vary, provided the strategy is good.

Here are some schemes and techniques that might help build a working "magic funnel":

• A simple priority triage system (one short sentence) was reported by Mary Poppendieck in Lean Software Development as one of the simplest things that could possibly work. The rule doesn't have to be subtle or obscure. A maintenance team might adopt a three-part rule, where production crises came first, followed by bugs on the release-in-testing, followed by everything else. Features that affect all customers may come first, followed by those that primarily affect million-dollar customers, followed by those that affect half-million dollar customer, followed by whatever. It is possible that product stakeholders already have a rule of thumb that suffices 80% of the time. The other 20% of the time is settled through escalation.
• Determine "The Constraint" as in Goldratt's writings The Goal and Critical Chain. If you can define the one thing that inhibits you from being successful, then you can prioritize all outstanding bugs and backlog items in such a way that those that remove the primary obstacle become top priorities. Goldratt was speaking of process steps and production, but why not apply it to features that sell or flaws that inhibit? It may be that scalability of your web application is more important right now than enhanced functionality. It may be that a difficult feature is the primary reason you are losing sales or even customers. It may be that one issue prevents you from expanding, growing, producing. Critical Chain shows us that we need to solve this one big problem. And then the one after it.
• Covey's Quadrants from First Things First will have us divide work into quadrants, so that #1 are those things that are both important (to the future of the company or product) and urgent, #2 are those that are important but not urgent, #3 are those that are urgent but have little long-term impact, and any unimportant non-urgent work is simply eliminated from the backlog. These items are taken in quadrant order, so that important, non-urgent tasks are done before urgent, non-important tasks are considered. Covey, et al, were talking about personal importance and daily tasks, but why not apply it forward to planning other work that has potential value and obvious levels of urgency? Remember that urgency and (to a lesser degree) importance are dynamic properties, to be revisited frequently.
• Value-First is the rather like the Covey and Goal approaches, where the work that provides the greatest value (frequently represented in customer satisfaction or decreased support) goes first. This sounds easy, but of course the problem is defining "value" and dealing with "value to whom?" One could place value to the customers or to the sponsors or to the shareholders first.
• Risk-First would tell us to start on those things that need the most research and testing sooner. High-risk items have unpredictable schedules, and may not pan out at all. Such stories would be prioritized earlier because they cannot reliably be produced on a schedule. Alternatively, some will choose to use risk-last planning, so that the so-called "low hanging fruit" may be completed before moving on to less predictable work. Some organizations may want to plan a mix (70/30 or 80/20) of low-risk to high-risk features. 
• Greatest Good to the Greatest Number works like the other "value first" kinds of schemes, but adds voting to the scenario. Each customer, role, or market segment that would benefit from a change votes for it (consider dot-voting). Among items of the same importance/urgency quadrant, those with the greatest number of votes would go first. Changes with fewer stakeholders would be done later. This is a customer-focused version of "Bargain for Success."
• Fixed-length action queue would work by using a short list of only a few bug fixes or marketable features. This list would be overseen by executives, and to push an item from "backlog" to "action queue" requires high-level approval. Items in "action queue" can be retracted only by executive order, since stopping a feature-in-progress represents a financial decision to throw away development dollars. The customer works to push items into the fixed queue as other things are completed or redacted. Customers will have a list of two or three items that might be next if approved. This tight focus helps the Customer not lose focus on immediate delivery. It is a lot like the Biblical "Law of the Medes and Persians", famous for being unrevokable.
• “Only One Thing” is a little game best used when the priority rule is more intuitive than explicit. The stakeholders are given a hypothetical situation that only one feature can be reliably developed in the next iteration/month/quarter, and are tasked with picking which one feature it would be. Once they have picked the solitary feature, they are asked why it is important to them. This game can be played with "only three" or "only five" for a larger sample size. Most organizations, having argued through the exercise, will have a Simple Triage System they can use for future priority meetings.
• Bargain for success is another game-like system. Each product stakeholder is given a number of votes/dollars/tokens/chips to spend. They are allowed to buy into features in order to bring their priority up in the queue. Stakeholders can make deals with each other ("I'll give 7 tokens to your feature Y this time if you'll give 7 to my feature Z next month"). The game-like nature of the exercise may cause some to see personal "winning" as the goal, rather than the greatest good for the company, but it will drive consensus nonetheless. Ultimately, the stakeholders have decided either way.

Some of these techniques (Bargain for Success, Only One Thing, Fixed-Length Queue) may qualify this card as a "Power Card". They are not guaranteed to result in happy handshakes and back-patting among all stake holders. Some may even resent their work being treated as a game (though in my experience they usually prefer to work in a game-like system with some rules and a fair degree of bargaining authority).

The ultimate power card (not included) is "CEO/Owner Demands". Most development organizations will pitch in and do all they can to get the feature completed well and soon. As long as the demands are within reason it should not be a problem. Most executives should understand the realities of development hours and sustainable pace, and are pretty hard-working guys themselves. The CEO DEMANDS power card is rightfully used sparingly and in cases most deserving of it.

Overplayed, all power cards will result in demotivation, loss of quality, slowed pace, and/or attrition. Coaches, managers, stakeholders, and product owners should move cautiously.