Needs, wants and desires

As a…
I want to…
So that…

The trouble with this story template is that everything is a want. And as I tell my three year old daughter when she says “I want some sweets” I say no! You can’t have them. They’ll rot your teeth!

A story list of “wants” is little more than a feature list. Yes, it may be prioritised, but are we just prioritising “I want a mars bar” over “I want a Twix”?

So how about separating needs out from wants.

When I travelled in Tibet, I needed to go to the toilet. I certainly didn’t want to go… As a junkie, I need a fix. I don’t necessarily want to stick a dirty needle into my arm.

Possibly not the best examples…

I need to login to access my on-line bank account details. I don’t want to log in.

What if we focus upon what our users need to do before including all their low level wants? Imagine the needs are the roots of product that we build, with the wants being the branches. The needs are the outcomes that must be satisfied.

I need to get to Manchester.

As soon as I introduce “wants” I begin to loose sight of my outcome. “I want to fly in an executive jet with Champagne on tap…”

There’s another dimension to consider. Needs and wants may be persona or environment specific.

There’s a half drunk bottle of water lying on the ground.

I’m in the desert. I’m dehydrated. I need to drink it.
I’m on the street. I’ve been to the pub. I certainly don’t want to drink it!

And maybe there’s another expression of volition, that of desire.

I need a drink
I want a glass of wine
I desire a bottle of ’53 Margaux

Maybe there’s something in this…

4 Comments

  1. Sean Patterson · Thursday, 9 November, 2006

    This is what BA is about.

    I have sometimes been tempted to write about how does one get ‘good’, valuable stories. Obviously, as a BA, one talks to various stakeholders – although not necessarily end customers.

    One part of BA is sifting through all of their ‘I wants’ to find the end customer’s (and system purchaser’s) ‘I needs’.

    Some, perhaps only a few, ‘I wants’ are really ‘I needs’. The rest of the ‘I needs’ come from a bit of thought, analysis and research.

    This can take time and a bit of modelling/discussion/etc, and is not necessarily understood by those that pressure us to churn out stories from Day 1 of a Quickstart.

    The first stories that you get are not always good nor always valuable.

  2. Aslak Hellesøy · Friday, 10 November, 2006

    Very perceptive. I like it.

  3. Rant · Sunday, 12 November, 2006

    oh My..
    Does BA’s role start to become word manipulator as a lawyer or some?
    BA’s story is never used outside the project, so if you communicate well( of coz you have to), people will understand no matter it’s a need or a want. And prioritization is never solely based on “I need” vs. “I want”. And obviously as a developer, I pay less attention to “As a…
    I want to…” pattern, and now all of sudden I need to catch the difference of the english word other than understand the story

    More cynical:
    Do we agile ppl feel that we are losing the cutting edge, the coolness, that we need to constantly come up with new cliche to define “Best Practice”?

  4. Josh G · Tuesday, 14 November, 2006

    Reminds me of my expression “User Desirements” to be blatant that very few things are “required” to obtain explicit value and realise return on investment.

    What’s wrong with thinking in terms of MoSCoW (Must, Should, Could, Would)?

    Perhaps, though, we should use Zork or a MUD engine instead of kooky BAs…

    You are in your cubicle. There is a desktop computer running your enterprise-class Excel spreadsheet displaying an out-of-memory error. The stains from your coffee cup have occluded your hastily-written TODO list. You can hear someone talking nearby and the sound of a water cooler gurgling.

    You have a chewed pen, a crumpled old version of your Business Requirements Document (some pages are missing), a watch, and a Blackberry that constantly bleeps new message alerts at you.

    There is an exit to the West. You gaze mutely at it with barely sufficient synaptic activity.

    > go West

    You are in a corridor. A water cooler is dispensing a clear liquid into a white plastic cup, held by your Manager.

    Your cubicle is to the East. There are exits East, North, and South.

    > say Manager Hello

    Manager: “Never mind that, have you got that document signed off yet?”

    > say Manager I was just going to

    Manager: “Aren’t you late for a meeting?”

    > go North

    You are in a meeting room full of people sitting a large table. There is one seat available.
    .
    .
    .

    > say Need Requirement 5.1

    You don’t need that requirement to satisfy the primary goals of the organisation, nor the objective of this project.

    > say Want Requirement 5.1

    Requirement 5.1 is descoped until Budget is increased.

    .
    .
    .

    > say Accept Mandatory Stories in Release 1

    Your solution, now 70% leaner, is released into Production with zero defects due to clean, simple code and 12 months earlier than vaguely plausible with your original document.

    Return on investment commences immediately and all stakeholders express thanks along with eagerness in awaiting the next Release.

    The PMO releases the next traunch of funding with the knowledge you can be trusted to spend company money wisely.

    You are at your open work desk next to the delivery team. You are looking at the burn up chart and it shows good progress for Release 2.

    Your manager brings you a cup of coffee and suggests you organise a team dinner at the local Belgian beer cafe.

    There are 4 exits and endless opportunities.

    – END GAME –

Leave a Reply