Does this list look familiar?
Needs Wants Food Lollies Water Atari 2600 Love Television
I’m sure many of us would have initially placed television in the left hand column. The social studies teacher would then patiently force us to confront what really was necessary to our survival. We’d progressively pare away items from our needs list until we had distilled it into the bare essentials.
We have to complete a similar exercise in adulthood when we prioritise the features of a software system. If only it were as simple.
The definition of survival (success) in a software system is often very hard to realise. The prioritisation game we played as children was easier; we die if we do not have food so that is a need. Many wants masquerade as needs and picking them out is often difficult because the definition of survival is not as clear.
Like the human “needs versus wants” exercise, a software project has multiple potential levels of success. I survive if I have a roof over my head but I wouldn’t mind a swimming pool in my back yard. An online banking system could be considered a success if it allows a customer to view their transactions but it would be very useful if it allowed them to transfer money as well. The success of a software system project is like a ladder with perfection perched at the top; the aim is to climb as many rungs as possible before resources or time are exhausted.
Once you identify subsequent levels of success for your project you can make these the themes for following releases. Using small releases will keep steps between the rungs smaller and make them more achievable.
First Things First
Effective prioritisation can be hard for many software development projects because there is not a clear idea of what constitutes that minimum level of success. When features are played that don’t contribute to achieving that minimum level of success, they steal resources from those that do. This can weigh down the project and increase the chance of all-out failure.
Wants are not necessarily pointless or useless, they just have to be prioritised after needs. There should be a point in your prioritised feature backlog where the features cease becoming needs and start to become wants. This point represents the first level of success; if everything up to this point is working as expected then the project has not failed. Any features after that point contribute to subsequent levels of success, they are the wants.
Try and shift that tipping point between needs and wants as close to the start of the backlog as possible. Find the absolute bare minimum that the system can get away with doing and make that your first goal.
Wants are actually very important because they provide the slack that allows your project to adapt to changes. You should plan to complete a healthy proportion of wants even though more or less will actually be completed.
Be thorough (even brutal) about asking what really does constitute the minimum level of survival for your system. Identifying truly essential functionality and then building it first gives you a solid foundation for further successes.
Mike Cohn’s Agile Estimating and Planning is in my opinion the current bible for exactly what is mentioned in the title. It contains a lot of great stuff on slack and how to prioritise features based on real information. Check it out.
By the way, I never did get that Atari 2600.