If you’ve even been to a scrum course or company training, you have probably heard of something called a “user story.” User stories are a way to present a functional requirement in a non-technical way so that stakeholders and product owners can reason about it. In other words, it’s a way of telling the development team what you want, and letting them figure out how to build it.
Traditionally, user stories have a general structure that looks like this: “As a X I want to do Y so that Z.” For example, “As a driver, I want to be able to turn my steering wheel so that the car will turn in the indicated direction.” However, quite often we tend to leave out the last part of that structure. This makes sense: after all, we all know how cars work (IE, we understand the domain of the problem) and when you’re writing ten or twenty user stories to describe adjacent requirement in the same product, repeating the “why” seems cumbersome and a waste of time.
But consider, for example, the following user story:
“As a business person, I want to be able to fly.”
On its face, this seems pretty obvious, especially if you’ve ever worked in any kind of professional organization. Businessmen fly all the time, it’s such an integral part of the job description that many airlines have a “business class.” Surely there’s no need to explain it any further, is there?
Maybe. It is true that some business people fly a lot. It is also true that quite a few people in that category are under a lot of stress and would love a chance to unwind by hang gliding. If you put a person like that on a flight to the central office or an important meeting, you will have technically fulfilled the requirement, and at the same time completely failed to satisfy the client.
Context matters in other ways too. Let’s say that the full story actually reads like this:
“As a business person, I want to be able to fly to my client meeting in Berlin”
Armed with this new information, we can now implement a more appropriate solution. Not only do we know that the person is planning to fly for a business meeting, rather than pleasure, so a hang glider is probably not the optimal choice here. But also, we are now free to consider other forms of fulfilling this requirement: Could the user take a train, for example? Or maybe just use video conference?
In fact, context is so important that it can sometimes replace the requirement itself. If we merely say something like “As a business person, I need to attend a client meeting in Berlin,” we’ve taken out any mention of the “how”, but the story is still effective. During the refinement process the development team can take that story and ask the Product Owner for details like “how many people will attend this meeting?” and “does this meeting have to be face to face?” This information can then be combined with domain knowledge (like “is there convenient rail service to the target location?”) to produce an effective solution.
When I work with scrum teams and product owners on how to approach a new topic or requirement, I usually tell them that the way to do it is to start with “why.” That is, why does the client want what they want? Simon Sinek has a great talk about this topic called “Start with why” which I highly recommend. He is specifically talking about leadership, rather than features, but the basic structure is still the same. Start with why, the how and what will follow.
