If the customer claims everything on the product backlog is top priority, and by implication must have, then you’ve a bit of an education job ahead of you. You have to get the customer to the point where only one thing is top priority and even “must haves” are sorted into a priority order. There is a good chance some of those “must haves” turn into “would like to have” and in time disappear.
If you don’t want the answer, then don’t ask the question
I like the saying “If you don’t want the answer, then don’t ask the question.” So I never ask either of these questions:
- “What are the must have requirements?”
- “What are the top priority requirements?”
I don’t ask because the answer is always “Everything.”
This answer isn’t helpful. And it isn’t true. A customer that claims everything on the product backlog is top priority “wants” everything on the list. That doesn’t mean they “need” everything. It also doesn’t mean that they need everything at the same time.
I find people just aren’t good at distinguishing their “Wants” from their “Needs”. Is “Export to Excel” a “Need” or a “Want”? Hard to tell without the context and even with context it is still often hard to tell. If “Export to Excel” is essential for the job then it is a “Need”. But what if “Export to Excel” is merely useful for the job?. It starts getting a bit vague. It is easy for people to then nudge it into “Need” but really it is more like a “Want”.
Unique Numeric Priority
Nobody is going to admit that their “Must have” / “Need” is really a “Would like to have have” / “Want”. So I use a different approach. I just insist that everything is in priority order.
pri·or·i·ty (pr?-ôr??-t?, -?r?-)
n. pl. pri·or·i·ties
1. Precedence, especially established by order of importance or urgency
Teasing out a priority list from the customer helps them distinguish between “wants” and “needs”. “Needs” are more important or urgent. “Wants” less so. “Needs” tend to head to the top of the priority list and “wants” towards the bottom.
To get the Epics into priority order I encourage the customer, which means the product owner, do a card sorting exercise. One thing at the top, then single file to the bottom. No “equal” priorities. Essentially every item has a unique numeric priority, starting at 1 and going up.
I find that this approach helps because even with real “Needs” there is always a priority order. We need to start work on the #1 not the #27 “Need”.
Why not MoSCoW
DSDM uses the MoSCow prioritisation with four levels of priority:
- Must Have
- Should Have
- Could Have
- Would Like to Have
The idea is that each timebox must contain some Must Have requirements with some lower priority items. Essentially in DSDM the Must Haves go into the bucket first, then the Should Haves, and finally the Could Haves. The Would Like to Haves don’t make it into the bucket at all. There should be at most 60% of Must Have in a timebox.
I don’t like this for a couple of reasons:
- It forces me to ask a question I don’t want the answer to, i.e. “What are the must have requirements?” The answer is always everything, i.e. an answer I don’t want.
- It actually results in lower priority items (e.g. Should Have, Could Have) being implemented (i.e. prioritised) over top priority items. Doesn’t make sense to me
Revisiting the Priority
You need to review the priority order regularly as priorities do change. This ensure new items are considered against older items. It is also a chance to reevaluate priorities based on new data, e.g. “Feature XYZ” was or wasn’t very successful.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
I like to encourage stakeholders to think about Output rather than Input by asking them “What is the next most important thing for us to deliver?”. This, hopefully, gets them into a “flow” and “pull” mindset where they are thinking about what they are want to get next, rather than some vague, compromised priority list. I’m with you on the dislike of the MoSCoW categorisation too!