by Jason Gardner (ed.)
User stories are an essential part of Agile software development. At their core, they’re simple: they’re a way to describe the needs and requirements of the users of a software system. But all too often, development teams will write user stories that are phrased in a way that doesn’t make sense. Specifically, they’ll write stories that begin with “As a system…” or “As a dev…”, which misses the point of what user stories are supposed to be. In this blog post, we’ll explore why these types of user stories don’t make sense and what needs to be done to write more effective ones that add value to the project.
When a development team writes a user story that begins with “As a system…”, they ignore the end user. A system doesn’t have needs or requirements – users do. By focusing on the system first, the team is missing the point of what user stories are supposed to achieve: understanding the user’s needs. Similarly, user stories that begin with “As a dev…” are also problematic. Developers are an important part of the software development process, but they’re not the ones who are going to be using the system.
Another issue with user stories that begin with “As a system…” or “As a dev…” is that they don’t provide any real value to the project. When a user story is focused on the system or the developers, it’s not going to lead to any actual outcomes that will benefit the end user. User stories should always be focused on creating value for the user – whether that’s by providing a new feature, improving an existing one, or streamlining a process. If we can’t figure out how a story benefits the customer- whether directly or indirectly- we should question if it should be done at all.
So, what needs to be done to write more effective user stories? First and foremost, it’s important to always focus on the user. User stories should start with “As a user…” or “As a customer…” and should be written to understand what the user needs and how the software can help. Another useful technique is to focus on the story’s business value, even if it seems to be an indirect benefit. For example, instead of writing a story that says “As a developer, I need to update the database schema,” write one that says “As a business owner, I need to be able to scale the product to meet demand.” This reframing helps to ensure that the story is focused on creating value for the business and the end user. After all, security improvements, retooling, and even easier maintainability all benefit customers in the end.
Finally, breaking down user stories into smaller, more manageable chunks can help ensure they’re focused on value and can be completed on time. Stories that are too large or complicated are more likely to lose focus or become bogged down in technical details. By breaking them down into smaller parts, it’s easier to ensure that each story is focused on creating value for the user and that the team can make measurable progress toward completing the project.
Conclusion
User stories are an essential part of Agile software development, but they can also be a source of frustration and confusion when they’re not written correctly. User stories that begin with “As a system…” or “As a dev…” are problematic because they focus on the wrong things and don’t provide any real value to the project. To write more effective user stories, it’s important to always focus on the end user and create stories that provide clear business value. Breaking down stories into smaller, more manageable chunks can also help ensure they’re focused on value and can be completed on time. By following these guidelines, development teams can create more effective user stories that lead to better outcomes for the end user and the business as a whole.
