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.
领英推è
- WIP limits on backlogs. (Basically, limiting the number of items in the backlog) This is the best way to force the prioritiser to make a choice. If they can only have 10 things on the backlog, and a new item comes in, they have to delete an existing item, or reject the new one. Either way, they are forced to relatively prioritise, and this makes them focus on what is really important.
- Alphabetic prioritisation. If the prioritiser still can’t decide, it’s time for a bit of?reductio ad absurdum. Simply agree that your team will do all the items, but in alphabetical order. They’ll start with any item beginning with A, then do the Bs and so on up all the way up to Z. At this point, the prioritiser will usually say something like “but that’s absolutely ridiculous — surely some things are more important and need to be done first?â€. You merely need to point out that, if everything is the same importance, it actually makes no difference whatsoever what order things are done. At that point, they will realise that there is an implicit priority order, they just haven’t been ruthless enough on their choices.
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.