A story about a Project Manager and a Programmer going shopping

So once upon a time I walked into town one Friday lunch time with a colleague and friend who happens to be a developer.

I told him I wanted to buy a green cardigan, and he said he had nothing better to do and he’d come with me.

In the first shop we wandered around, couldn’t see any green cardigans and wandered out again.

Same in the next.

In the 3^rd shop he helped point out 2 green cardigans, but I didn’t like either. One was too fluffy and one was “the wrong green”.

After about 20 minutes he lost interest, told me that this was impossible and he was going back to work.

That evening, I arrived at the pub – he looked me over and asked if I’d bought a cardigan.

I gave him a spin and said that no I hadn’t, I’d bought a green handbag and green nail varnish.

This did not compute! I’d told him I was looking for a green cardigan. How could a green handbag and nail varnish possibly meet that brief? He’d been looking at the wrong items all along! He could have spent the whole day shopping and still wouldn’t have come up with that solution.

So when I said I needed a green cardigan, this was only what I thought I wanted! Actually, what I needed was something to tie my new green shoes into outfit I had chosen for the evening! Pretty much anything green would have done – belt, scarf, necklace, bag, nail polish – green accessories.

As a user story

Frances wants to buy some green accessories, so that she can wear her new shoes with a black dress

Although this may appear to be a story about shopping, it’s actually about ensuring that your requirements don’t jump the gun and guess a solution rather than outlining what you’re actually trying to achieve…

Frequently when I asked people what they are trying to achieve, or what is the objective of the project, I am told things like to implement a database of training courses.

 No, no, no! This is not your objective, or if it is, then something it wrong!

Firstly at this stage, perhaps don’t be so certain that a database is the answer, maybe SharePoint list would do the job in half the time and at no cost? Don’t limit your options or guess the solution too soon.

But more importantly, share the purpose and context - it helps give a shared understanding, it ensures that we understand your goal, how it contributes to the business and allows us to appropriately prioritise work. It also allows us to explore all options and to ultimately ensure that you achieve what you actually need to achieve.

I'm pretty sure you're not implementing a database just for fun, what is the background and reason for this?

Potentially the real objective of your project might be to  improve ease and visibility of accessing/booking training courses, or even to zoom out one step further, the objective might be to increase the number of people on training courses or increase revenue generated by training.

Getting your objective wrong, could mean that it is possible to achieve your objective, but not achieve what you need to achieve

You may have implemented a new training database, but no one has entered the courses, or no one approves booking requests, or it is located where no one can find it

Alternatively you may get exactly what you asked for, but then realise that that isn't actually what you wanted at all!

Story about the rabbit and the cream cheese

It's the way you tell 'em - user stories vs requirements spec

Return to GeekSpeak page