After years of delivering software applications, with majority of them focussed on talking to people to understand the problems they are attempting to solve, I thought it would be worth summarising some of my experiences (more or less blissful) in a manner that may inspire those who share the passion of interpreting “user needs”.
The recommendations I’m sharing are user story-oriented, but the mindset that they invigorate is applicable regardless of how agile (or not) your current software delivery practice is. On that note, behold the Ten Commandments of User Stories.
#1. Thou shalt involve users/customers and the development team in user story creation
“In our team, it’s the BA who writes the user stories and then…”, these words give me the chills. The goal of user stories is not to have stories well written. Stories are more like pointers (for those used to lower-level programming languages) than a requirement that someone writes and then sends to someone else to read and build on.
The process of crafting stories must involve — ideally in the same room:
- those who will use the product of the story, and
- those who will turn the story into that product.
Having a designated User Story Writer is practically naming someone to blame when things fail.
#2. Thou shalt not have your user stories signed-off
This might be a surprise, but many people out there are currently seeking formal approval for their user stories. A documented sign-off is the evidence they are looking for, and it literally is the end of the story.
When stories are signed-off, they immediately become a contractual agreement between the requester and the provider. And you probably recall from that construct called the Agile Manifesto1 that we should value “customer collaboration over contract negotiation”, and “responding to change over following the plan” as some of the foundations.
The reason we have user stories is to promote conversations about what we want to do with the software. The very concept of sign-off implies that the conversation has ended, and there will be no further opportunities for ideas or alternatives to be discussed. If you can get the sign-off process off the table, you will be building an environment where trust can thrive.
#3. Thou shalt enrich thy stories with any appropriate media
Stories are reference points and as such, they won’t contain a description of all the possible details. You should use stories to start conversations (remember the 3 C’s? Card, Conversation, Confirmation), and this exchange of ideas should take advantage of all mediums available. Anything can be used, from simply talk (in person, or teleconference), to taking short audio/video records, storyboards, coloured stickies, photos from your whiteboard, sketches, notes, drawings, etc, etc, etc.
#4. Thou shalt create stories as late as practical/possible
Avoid by all means creating an inventory of user stories too early, otherwise, by the time the team starts developing them, chances are:
- Nobody will remember what the stories were about and/or
- The stories will have become obsolete or have evolved due to changes in the business landscape.
Now, what “too early” means is highly dependent on your context. For instance, you will find industry recommendations that, for a single Scrum team, the PO should have refined the work for some 2 sprints ahead. That is a manageable list, which can be re-ordered seamlessly, and even if you end up dropping one or two backlog items, it is not a big loss.
Creating your stories JIT (Just-In-Time) will prevent the destructive culture of “formal approval” of your backlog items (see commandment #2).
#5. Thou shalt not take your stories as specification
User stories are not specifications — they are actually diametrically opposite, as @StefanRoock put together in the illustration below.
Stories will provide the Who, What and Why of a piece of work — the How is not part of them. Too detailed user stories can:
- Restrict the possible solutions the team may come up with
- Delay the point when stories are ready to be built
- Revoke the team’s ownership over what they develop
Write stories when you have to experiment with ideas; and when you don’t know what is the best option — which should be most cases, when you’re exploring a complex environment.
#6. Thou shalt not take thy stories as documentation
Some people think of user stories as “the agile technique for writing requirements”. That could not be further from the truth. Documentation is written to inform what your software product does. It is therefore, one of the artefacts produced by the development team, just like the code itself.
The lifespan of a story ends when it becomes releasable software. If you want to document what the product is about, you can use a wiki, user manuals, business process diagrams, a catalog of business rules, showcase videos, or any type of functional documentation. Notice that all these are by products of development process, and should be created by (or with direct inputs from) the same team who builds the application.
Again, stories are not a way to write or document requirements, and that’s precisely why they are not suitable for creating a requirements baseline — ultimately, they are facilitation tools to promote better communication between requesters and developers.
#7. Thou shalt prioritise stories that may kill thy product the fastest
I won’t get into the details of minimum viable product (MVP) — there are plenty of great resources out there about it. Suffice to say, when selecting high priority stories, you should take into account which ones can validate your biggest assumptions. Remember, building quality software is the most expensive way to test a hypothesis.
The purpose of discovery is to experiment with ideas, and the objective should be to challenge your riskiest assumptions. As a result, you may come to the conclusion that your “amazing” feature is not worth building after all. And you better learn that before building it.
“Maximize the rate of learning by minimizing the time to try ideas”
You would want to involve your customers or users in this discovery path so they can help you spot weaknesses in your product (or increment), before you fully developed it.
#8. Thou shalt not worry about efficiency; effective stories deliver business value
It should really read “…effective stories will eventually deliver business value”. And that is an important element: actual realisation of value will happen only when end-users get their hands on working software. Anything else is but an anticipated outcome — an estimated business value that may or may not be fully realised.
That said, how does efficiency come into play? Efficiency has to do with resource utilisation, cost-effectiveness, and how well your process is followed. It is not a bad thing. The problem is when efficiency (how the work is done) is valued more than effectiveness (what is done, and why).
Imagine a doctor coming out of a surgery, proudly explaining all the modern techniques he used, how challenging the procedure was and how he was able to demonstrate all his skills and years of medical expertise. “The operation was a success” — he would add— ”Unfortunately, the patient did not survive”. This is efficiency overtaking effectiveness.
Now, what is value in this context anyway? The way I like to explain it is this: value is the delta between what the user can do today, and what they will be able to do after you release your product (or increment).
Notice that if your release truly messes up, your “delta” can even be negative! If you for example deliver a version that has lots of confusing features, or is ridden with defects, you might be limiting (instead of expanding) the end user’s experience with the system. You will only know this when your users have the software in their hands.
#9. Thou shalt map stories thinking “kilometre wide, centimetre deep”
In the book “User Story Mapping”, Jeff Patton explains the thought process for mapping the Big Picture:
“Focus on breath, not depth. (…) Go kilometre wide, centimetre deep. If you don’t have a solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have”.
It really is an exercise of continuous refinement and reprioritisation. The more you talk (to users, customers, and developers) about your map, the more you learn. The more you learn, the more you enrich your map.
#10. Thou shalt not take these commandments as if they were set in stone
Don’t lose yourself trying to implement rules just because someone said so — not even your CIO. That is the problem with best practices. People working in complex environments will blindly follow them, just to discover that they are highly context-dependant, and should be adapted instead of adopted.
Point is, think, question, and challenge processes, guidelines, practices, rules or suggestions presented to you. And of course, it includes the suggestions conveyed in the above 9 commandments.
Reference:
