In my years working in in software development I've come to the conclusion that most products fail not because it's a bad idea or unskilled developers. It's also usually not the tools or not having enough money or time. In most cases, it's because the good idea isn't translated into actionable, explicit steps for a developer to build.
After all.
You can't expect good software when the requirements are bad.
The issue, however, is mostly not that it is bad requirements. Rather, it is good requirements not translated into a language developers can understand. And no-one can build something good when they don't understand why or what they are building.
Lost in translation
When different cultures come together to transact - whether in business or for pleasure - they have to either find a mutual language both speak, or get a translator. Yet, in product development we separate business from technology and hope that somewhere between the lines the message will get to the other side.
Often, this attempt fails. What the customer wanted comes out as something very different to what is built, with each person included in the value chain having a different perspective on the solution as depicted in this well-known image of a user asking for a simple swing (2nd picture), what they pay for (the roller coaster), and finally what they get (the last picture).
People laugh when they see this image because they know it's true. Yet, stubbornly, most people continue what they've been doing before just to repeat the same issue again and again.
Over the past decade this problem hasn't become any easier. In fact, it has exponentially become more complex to communicate ideas with more tools and technologies that broadens the gap between the different vocabularies even more than ever before.
So how do you communicate a user story from business to technology talk without getting lost in translation?
In a rough guide to crafting user stories that's just right, I analyse the anatomy of a good user story and a few tools to help craft user stories that's just right for everyone to understand.
Here's a summary:
1. It's valuable
A good user story is a complete functional unit that adds value to a user. It does one thing well enough to make it useful to someone that uses it. Sometimes this value is something tangible like a new feature in an existing system, other times it is less tangible, like a security improvement to ensure that your data stays safe.
A good user story starts with why. It has a clear outcome that will positively impact at least one demographic using or interacting with the software.
2. It's re-usable
A good user story forms a unique part that fits into a bigger system. The more this part is re-used by other parts, the more valuable it becomes. An additional bonus is that by making it re-usable it also increases the speed of development and decrease the need for maintenance.
When a user story is designed to be a re-usable part, it becomes more robust and more valuable. A good user story takes multiple use-cases into consideration.
3. It has clear boundaries
A good user story is contained within clear and explicit boundaries. It has a definitive start and end and goal. When a user story has grey areas that becomes fuzzy depending on who is using it, it becomes confusing and error-prone.
When crafting user stories make sure that you clearly define the boundaries and exclusions.
Tools to craft good user stories
Understanding what a good user story is, is the foundation, but how do you practically craft one? The easiest way to look at a system is to look at it as a human body with different layers for different functions.
At the core is the skeleton which ensures the body can stand up and move around. Then comes all the different organ systems, each with a unique and important function, and lastly is the outside flesh and appearance - the part the other people can see.
Each individual layer needs different tools to make sense of and communicate its function and ensure the granularity is right and complexity managed. If you can't draw an abstract map of your system, you probably can't build a robust engine to drive it.
So next time you struggle to build a user story that's just right, consider the different layers and whether you are adding enough structure, a valuable and unique function, and a user friendly and pleasing aesthetic layer.
To read more about the anatomy of a good user story and find some of the tools to apply to each layer, read more here.
To get help with your journey to get your user stories just right, consider booking a one-to-one mentoring session at https://www.funficient.com/.