Recently I was working with a customer to put together an initial product backlog for a development effort. The purpose of the effort was to build a minimum viable product (MVP) as a first version of their application to take to market. The backlog was based on a list of requirements that the customer had spent a lot of time thinking about so the user stories were relatively easy to write. The rub came when it was time to prioritize the stories so that we could lay them out into a rough development plan. Because they had spent so much time thinking about the requirements and had also built a proof of concept, for them, each requirement was critical and had to be there to qualify as an MVP. Therefore, predictably, as we went through the stories, each one was a “high” priority.
This is not an unheard of scenario as customers often have difficulty admitting that they could live without certain features. As agile practitioners, however, we know that once development starts, priorities and requirements inevitably change and features initially deemed critical are dropped and new features never before thought of become critical. However, even though we know that this will be the case, it is not productive to try to convince the customer that their critical features won’t actually end up being critical in the end. This can lead to arguments and a loss of trust if the customer thinks you are trying to convince them they are wrong.
So how do we get a customer to prioritize when everything is a priority? One answer: Change the question
Rather than phrasing the prioritization question as, “What features are most critical and what could you live without?”, instead use a quality and testing approach. Ask, “Which features will require the most testing and therefore should be added earlier?” In a well-designed agile project, features added earlier are subject to more regression testing than those added later, resulting in higher confidence in the correctness features. Re-phrasing the question in this way allows you to
- Acknowledge and support the customer’s belief in the criticality of including all features
- Gain a feeling for the customer’s underlying understanding of the actual criticality of the features
- Get the customer over the hump and allow a base prioritization for planning
Once I approached the customer with this modified question, the customer was able to comfortably change several stories from high priority to medium or low priority and the backlog and the release plan fell out naturally.
