James Robertson, Principal of the Atlantic Systems Guild
James Robertson is co-author of the best-selling book, Mastering the Requirements Process – 3rd Edition. The virtual public course, Mastering the Requirements Process, based on this book, will be presented by Adrian Reed on 2-4 March 2022.
We build too much software. We know this — our software contains features that are never used, routines and procedures that are near executed, and sometimes who apps that are gathering virtual dust in the cloud.
Why does this happen? It happens because someone produced the requirements for them. While teams prioritise their requirements and backlogs, that still leaves all the requirements/stories on the list.
Perhaps you should try something else to eliminate the unwanted and the unused.
Most of you have come across Marie Kondo, the Japanese lady with the tidying method. The clever part of her method is that instead of looking at, say, your clothes in the wardrobe and trying to decide which ones you no longer want, you take everything out of the wardrobe — and wherever else you have clothes around the house — and put them on the bed or the floor. Now here’s the smart part: you pick up each item in turn and ask — in Marie Kondo’s words — “Does this spark joy?” Perhaps you would rather say something more prosaic and ask if you have worn the garment in the past year, and what are the chances you will wear it again? If you realise you don’t want it, it goes into the charity bag. Only those things that you really want make it back into the wardrobe. (You can do this for everything else in your house.)
We normally prioritise by looking at the list of requirements and their clusters (business events, use cases, stories, epics, or whatever else you use to chunk your requirements), or your backlog or story map, and shuffle the items around, moving some higher up the list and demoting others. But that still leaves everything on the list, with the presumption that all of the list will be developed.
But what if you “tidy” the list? What if you take every item off the list. Now pick them one at a time and ask if it sparks joy. No, don’t, that’s a very snowflake thing to say; better to ask if you really want to develop and maintain it. Will it produce enough value if it becomes part the final product? Will the customers love it? What benefit will it bring to the client, and is that enough benefit to warrant developing it? Is it a requirement/story because it is genuinely needed? Or is it only something that seemed like a good idea at the time?
It will come as no surprise to you that many requirements end up in the charity bag.