So we were talking car metaphors as being a sort of semi-interesting way of making complexity a relational matter for non-technical people. This one can be done with just about anything and is less about a car and more about a journey so could be swapped out with different modes of transport.
But I like to use cars, so here we go.
We often ask our clients for User Acceptance Tests (UATs) so that we all have a shared understanding of what is being delivered. To get a UAT we ask that we start with a User Story.[1] And we often have to return to the client to get more detail and are presented with the problem that some people see this as over-specifying.
Now you can get overly specific. You can have too much information which restricts your choices and produces something that is not innovative and un-intuitive. But we are not talking restricting every decision and being inflexible, we are talking about too much vagueness in the story.
My car allegory
Client User Story: I want to be in London, in a car, by 3 p.m. tomorrow.
So that sounds like the user has given us their story, right? Yeah, no. Let me show you:
At 15:00 on the following day the client's body was found in the trunk of a red Astra perched precariously on the top of Nelson's column having been dropped by helicopter from just above at 14:59.
We could have assumed the client meant alive, a red mercedes or their red BMW, that they meant they were driving it, or someone else was, that they wanted to drive via Leeds, or Manchester, or San Diego or...
You see, vague.
What they have given us is an end target and quite often that is what non-technical people think the user story is. But the story should be more than this. The story is a description of a journey. You place in every fact that is relevant and leave out those that are not.
So we examine it as a series of steps.
- What is the end state?
- What is the method to reach the end state?
- What do I do to interact with the method and the end state.
Our end state here is to be in a red car in London the following day, I want to be alive and I want to be driving the car. My user story is this:
I want to leave my home and drive by car into central London. I need to be at my location by 15:00 tomorrow. I need to be functional to drive the car. I need the car to be owned by me. I need the car to be red. I need the car to be mechanically safe. I do not want to be late. I must be refreshed and to have no debilitating effects from the journey. I will be the person operating the vehicle, driving.
There is still a lot of room for us to infer the methods we use to achieve this User Story. But we have our end test point, the UAT describes what the goal is. But the user story gives us the operant conditions for method and final status.
In an actual example we may have this UAT: The button is pressed and the user is taken to the Options .
The User Story is likely:
- The user must be able to get to the options page from any other page on the site
- The user will press a single link, in the form of a button
- The button will have a web-standard graphic
- The button will be visible at the top of the page and from the taskbar on mobile
[Don't forget that you can join in this conversation by using the comments form or by tweeting at @shadowcat_mdk]
Notes
[1] This is a fairly common technique and has been employed in Project Management since long before someone jammed those two terms into a job title.
