Alphabetic Proritisation: how to force stakeholders to focus
Steve Wells
Building online agile games and workshops that are as engaging as "the real thing"...
I’m sure you’ve all been in the situation where your Product Owner, or other stakeholders, are unable to prioritise things. Everything must be done, and done at once. The upshot is, the team gets overwhelemed with requests, nothing gets done, and no real value is delivered to the customer.
There are techniques to alleviate this issue, but,?in my experience they simply don’t work. An example is MoSCoW (Must Have, Should Have, Could Have, Won’t Have), where items are rated on how essernatial they are. At one company, I went through 5 years of MoSCoW reports, and only found 2 items (out of hundreds) that were not “Must Have”. Other, similar techniques give the same results. The reason is not a flaw in the technique, it’s a lack of focus on the behalf of the prioritiser; they simply cannot decide on the relative importance of items because they are not forced to choose.
So, I came up with 2 techniques to help in this situation.
Failure to prioritise is not about the tools and techniques being used, it’s about not making the decisions between items because there are no consequences. WIP limits and Alphabetical Prioritisation simply force the choice.
I take the risk out of your software development projects and make them valuable, efficient, and predictable.
3 年Instead of WIP limits on the Backlog, I usually just stick a column between the Backlog and the rest of the system, WIP limit that, and ask the organization to fill that column on some kind of regular basis based on the team's throughput. That way, everyone is still free to throw their requests into the Undifferentiated Pit of Hopes and Dreams (i.e. the Backlog), but the org can only prioritize a set # of things at a time. This is especially helpful at the team level, because a lot of PO/PM/Whatever can understand, "You get 2 items a week to spend." The reductio ad absurdum is highly effective. Love this implementation of it. My version is, "Well, if everything is equally important, my team will just do all the easy and fun stuff first. Is that ok?"
Project Manager| Agile Project Manager
3 年I wander why do we need a to z prios? Prios 1 to 4 are sufficient. Prio 4 as default. We implement by priorites. If a stakeholder is not able to justify higher prio, it may never be done. When we agree on prio 1, it means that everybody who can help is helping, and other issues need to wait.