If you work on an Agile product team, you’ve likely already heard the term User Stories. As a product manager, you probably write those every day and you might think there isn’t much of a secret to writing them. Although this communication tool is rather simple, following the canvas naively will not help your team capture its real power. Here are the two major traps that product managers can easily fall into when writing user stories. But first, what is a user story?
A user story is a short sentence that follows a simple structure:
As <description of the user>, I want to <description of the need>, so that <description of the objective>. An example would be: As a swimmer, I want to be aware of the time when I’m swimming so that I know when to get out of the pool.
The sentence is meant to carry the user-centric message of a problem that needs to be solved or a value that can be provided. The product manager usually gathers multiple user stories that the team wants to tackle next. User stories are made for delivering this message to the team and reminding them of the objective of each feature. It’s a good way to make sure the solutions provided are aligned with the pain points or opportunities described.
Don’t Write Monster User Stories
The first trap you need to avoid is writing monster stories. With a user story, you want to stimulate your team and deliver value continuously to your customer.
Your development team probably tackles user stories in sprints as those allow incremental delivery. It’s also a great way to manage commitment in a regular time frame and to monitor progress. However, if your user stories cannot be finished within a sprint, you cannot assess if your team has fulfilled the commitment on time. You want to create a pressure to achieve the goal and thus a feeling of satisfaction for your team.
By definition, user stories are the smallest description of a value that a product could provide to its users. One of the most important duties of a product team is to deliver incremental value regularly and you can’t achieve that if you don’t pay attention to the scope of each of your stories.
User Stories Are Not the Agile Version of Requirements
The second, and most common trap you could fall into, is to turn user stories into an Agile way of writing a requirement.
Before Agile became popular, the main communication tool between a product manager and the development team was through a long and specific document called the Product Requirement Document (PRD). That document contains a detailed list of features and describes how they should be implemented. From UI layout to back-end flows, from database table structure to front-end button displays, the product manager specifies the solution based on their biased assumptions. The developers would read the PRD and code what the requirements specify. Most of the time, they don’t even have the chance to share their opinion on the product they are building. The drawbacks of such approaches have been proven and few product managers still use this method. The solution often comes exclusively from the writer of the document alone. Discussions are not encouraged within the team to optimise the solution and, worst, the requirements have not been challenged by the team regarding whether it’s a valuable proposition.
On top of the frustration that the product team may feel being used as a coding machine, they lose connection to the actual business problem and will eventually build products that no one uses. That leads to a significant loss of motivation, ownership, and responsibility towards the team.
The user story should be simple enough so that the team understands the problem that they are solving without detailing the implementation. The discussion about how to design the solution can only begin once the team recognises the necessity to tackle this problem. The solution design should be carried by the product team and not the product manager. Engineers are generally much more motivated when they see something they can do to make one’s life better rather than waiting for a document to read through and code. They are very sensitive about the usage of their product and any positive or negative feedback can trigger the urge to build something even better. It’s when the teams are presented with a problem to crack that you can leverage the collective intelligence and creativity of the team into the product. If we only write requirements for engineers to implement, why do we work as a team?
Key takeaways
The essential message to keep in mind is to look back at why we use user stories in our product development process. At the end of the day, the product manager needs to inspire the product team and continuously deliver value to the users of the product. User stories are merely a tool to achieve this bigger goal in a product organisation. That’s why you don’t want to fall into those traps, but instead, write user stories in a way that truly empowers your organisation.
Photo credits: Antoni Shkraba, Ivan Samkov & kaboompics
