As a Product Owner one of my key responsibilities is ensuring that backlog items are worked on in the correct priority order. This is far more difficult than it sounds, as most clients have priorities that rapidly change along with the needs of the business. To help deal with this, I have always used the Kano Model as a guide for helping clients understand what priority should be given to an item of functionality.
The Kano model essentially breaks down requirements into three sections; ‘must haves’, ‘should haves’ and ‘could haves’.
‘Must have’ requirements
These are requirements that must be in place for clients to be able to use the product at its most basic level. For example if we were building a word processer, the ability to save or print work might be considered ‘must have’ functionality. Without these basic requirements, the project will not achieve the base level of acceptance by clients and will not be used by them, regardless of how many ‘should’ or ‘could have’ requirements are added.
‘Should have’ requirements
These requirements provide additional client satisfaction proportional to the amount of functionality added. Put simply, the more ‘should have’ requirements there are the more satisfied the client will be. With these requirements, there is a neutral satisfaction point prior to which clients will not be satisfied. This point will vary from product to product and is the average expected level for the product. Using our example of the word processor, it can be considered that changing font size and type or adding images to a document are examples of ‘should have’ requirements.
‘Could have’ requirements
Once a product has satisfied the must have requirements and sufficient ‘should have’ requirements to satisfy clients, attentions can be turned to requirements that ‘could’ be added to the product. These are traditionally requirements that set the product or service apart from the competition and are where most innovation lies. They add the ‘ooo’ factor to a product. Drag and drop functionality could be considered a recent ‘could have’ requirement.
A note of warning; as time passes, functionality will move from the ‘could have’ pot into the ‘should have’ pot and then from the ‘should have’ pot into the ‘must have’ pot. For example, a spell checker would once have been an exciting, innovative, ‘could have’ requirement. Nowadays it would be considered as a must have for any word processing product.
Take clients through the backlog
By taking clients through the backlog and putting stories into these groups, it is far easier to prioritise important functionality over and above work that may not affect the success of a project. Some clients may struggle at first to break stories down into these groups (“but it’s all necessary!”). When going through this process, I tend to use a tried and tested (also extreme) formula; whenever a client is unsure where a story should sit in the backlog, I ask;
“If the team were to be killed in a car crash/ hit by a meteor, drowned by a tidal wave (pick your favourite) at THIS point in time (specify a point in the backlog), would the product be in the best position possible?”
If not, reorganise the backlog as required.
This process should be repeated every so often (more often for those backlogs that change regularly) to ensure that the backlog is still appropriately prioritised. Hopefully, you will find that you work on the important tasks first and leave those sudden whims of the client until later in the project. This way, if you do run out of budget or time, the product will be in the best shape possible.