User story writing
Writing user stories. The base of being a Product Owner or a Product Manager. It is the piece of puzzle that links all your work from talking to the users, clients, proxies, to your team, developers, testers and leading to either a great product or a misunderstood one where nothing makes sense.
In the past I've found myself at both ends: as both Product Owner AND a user, getting to know both worlds. Working as a user lets you use the product as you need, find inconsistencies, bugs, complain about it but you don't use any headspace on how the hell could this happen or how can it be fixed. You're a child that complains that something doesn't work as it should be. The world's not fair and you WANT IT TO WORK NOW! And on top of that, you want new toys, too. You want this and that and the other thing you saw at school.
As a Product Owner, you're often found between multiple users or clients, all of them shouting they want everything at once. You have to discern between all the shouts and wishes what they actually want and translate all those cries to your team. But wait: this is the best case scenario. You have clients that tell you what they want at least. What happens when they are introverted, hiding from you, you have no idea what they want and they don't even respond to your invitations or questions. What do you do then?
Then the Product owner has to become proactive, digging through proxies, data and observations to uncover what the clients won't say out loud.
Let's take it from the beginning. What is a user story? A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects: a written description of the story used for planning and as a reminder; conversations about the story that serve to flesh out the details of the story; and tests that convey and document details and that can be used to determine when a story is complete. (from Mike Cohn. User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck)) (p. 4). Pearson Education. Kindle Edition.). The Card may be the most visible manifestation of a user story, but it is not the most important. Rachel Davies (2001) has said that cards “represent customer requirements rather than document them.”
This is the perfect way to think about user stories: While the card may contain the text of the story, the details are worked out in the Conversation and recorded in the Confirmation.
But how do you take this user story concept and turn it into something you can use? Dealing with clients will be different from one person to another, from one company to another and so on. But I'd like to split the clients into two major groups for now: present clients and absent clients.
While working with present clients is rather nice and straightforward (which has its own difficulties like prioritization, understanding the needs when the field expertise is not at the same level between the developers and users – but this is for another time), working for an absent client or clients forces the team to take a few steps behind and do something before reaching the story writing step:
Find the users.
For an existing application:
Finding the users can be as simple as looking at your application's logs, if you have any. Get the names, emails, whatever you have as information and start writing them. Ask them how are their interactions with the application. Here you can use different methods like sending them a questionnaire to answer, set up a workshop with them, have user interviews where you ask them how they use the product, what would be their needs, what would they like to see in the future as new features, or finally, observe them by standing next to them for a given period of time.
For an application that does not exist yet:
In this case, finding the users can be a bit trickier (or not), depending on how transparent the organisation you work in is. There are a few questions to ask yourself or people close to your team:
For who are we building this product? Who will use it? You need names, departments, teams. Be as specific as possible. These are usually the people that know exactly what they will be using the product for and how.
Who is our sponsor? Who's paying for this development? There's going to be someone in the upper management who will have an idea about the timelines, why the project is needed, how they came up to this idea of forming a team to build this product. But he/they will not have specific use cases or will not go into detail of the product, most probably.
Who are other departments or people that we need to work with? Here you might need databases, APIs, infrastructure already existing, other products to work in parallel with, etc. They will be a source of requirements as well, most often the more technical ones, not necessarily functional.
Creating the stories
To create good stories we focus on six attributes. A good story is: Independent, Negotiable, Valuable to users or customers, Estimatable, Small and Testable.
Independent
As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems.
Negotiable
Stories are negotiable. They are not written contracts or requirements that the software must implement. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team.
Valuable to Purchasers or Users
It is tempting to say something along the lines of “Each story must be valued by the users.” But that would be wrong. Many projects include stories that are not valued by users. Keeping in mind the distinction between user (someone who uses the software) and purchaser (someone who purchases the software), suppose a development team is building software that will be deployed across a large user base, perhaps 5,000 computers in a single company. The purchaser of a product like that may be very concerned that each of the 5,000 computers is using the same configuration for the software. This may lead to a story like “All configuration information is read from a central location.” Users don’t care where configuration information is stored but purchasers might.
Estimatable
It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code. There are three common reasons why a story may not be estimatable: 1. Developers lack domain knowledge. 2. Developers lack technical knowledge. 3. The story is too big.
Small
Like Goldilocks in search of a comfortable bed, some stories can be too big, some can be too small, and some can be just right. Story size does matter because if stories are too large or too small you cannot use them in planning. Epics are difficult to work with because they frequently contain multiple stories.
For example, in a travel reservation system, “A user can plan a vacation” is an epic. Planning a vacation is important functionality for a travel reservation system but there are many tasks involved in doing so. The epic should be split into smaller stories. The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
Testable
Stories must be written so as to be testable. Successfully passing its tests proves that a story has been successfully developed. If the story cannot be tested, how can the developers know when they have finished coding? Untestable stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality.
For example, consider these nonfunctional stories: A user must find the software easy to use. A user must never have to wait long for any screen to appear. As written, these stories are not testable.
Whenever possible, tests should be automated. This means strive for 99% automation, not 10%. You can almost always automate more than you think you can. When a product is developed incrementally, things can change very quickly and code that worked yesterday can stop working today. You want automated tests that will find this as soon as possible.
In conclusion
Whether the client is close or far away, whether you have direct conversations or rely on proxies and observation, writing good user stories is a craft. It demands consistency, discipline, and empathy. The closer you get to your clients and users, the clearer and more valuable your stories will be. And when they’re far away, the responsibility of the Product Owner to bridge the gap becomes even more critical. Good stories aren’t just written—they’re discovered, shaped, and validated through ongoing dialogue.
