Prioritizing requirements
The topic of prioritizing requirements came up in a recent meeting. Often the customer will say that all the requirements are top priority and are unwilling to place priorities in individual items.
The reason that we care about priorities is that we are going to implement the requirements in priority order. The most important things get built before the less important items. So, how do you handle the case where the customer says everything is top priority?
What I’ve found is that customers often think of priority and the order things get built as two separate items. If you explain that we can’t build everything at once and need to decide which things to build first, the customer is usually more than willing to help with that. They’re satisfying our need for priority but aren’t thinking of it as setting priorities.
If you are using the XP technique of writing requirements on story cards then one technique for getting them prioritized is to hand the stack to the customer and explain that you will implement them in the exact order in the stack. If they wish to change the order of items then this is their chance to do so. It’s helpful if you stress that the current order in the stack is fairly random.
I’ve found that when I do this, the customer will usually split the stack into two piles. One that really has to be done first because those cards are most important and then a second pile of less important cards that could be done in any order.
Cross-posted from Mike Bowler’s blog.
