Organising Your Backlog

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.

It’s just like ‘Grand Designs’

I was sat watching ‘Grand Designs’ with my wife a while ago (It’s not a programme I would normally watch, but I was looking to earn some brownie points at the time) and I noticed just how agile the couple were in terms of creating their perfect home. For those who don’t know, ‘Grand Designs’ is a programme where couples design and build their dream homes (some of which are truly amazing). The couple on this particular episode had some basic requirements for their new house in terms of size and location but that was about it. They had bought some land in a nice location, received the designs from the architect and started building. This seemed to surprise the presenter of the programme, who was astounded that the couple hadn’t worked out all of the tiny details for how they wanted their dream house to look and what it would contain upfront. He made his opinions clear to the couple that he thought they were mad to start with the actual building of the house, as they would surely end up wasting loads of time and money.

What actually happened astonished both him and my wife (who had agreed with the presenter’s views), but will come as no surprise to those of you who use agile on a day to day basis. As the house went up, the couple worked through each stage of the process, always staying just one step ahead of the builders. They made sure that they had narrowed down the requirements for the next part of the build, just in time for when the builders got there. They were always on hand, ready to provide guidance or offer feedback on certain aspects of the build. The build was completed on schedule (almost unheard of on this programme it would seem) and the house met the couple’s requirements and expectations.

This may not have been software development, but we can still see the agile process at work here with a Stakeholder/Product Owner prioritising their backlog in terms of importance and providing continuous feedback. They only worried about the small details when they were sufficiently close to being worked on by the builders, as opposed to getting all the specifications laid out at the beginning.

It just goes to show that provided that you apply it properly, the agile methodology comes up trumps every time, even outside of software development.

All I need to do now is convince my wife to live in a house that looks like a castle and we can get started on building our ‘Grand Design’!