An Agile user story - whether intended for traditional software development or RPA development - is meant to spark conversation within an Agile team. When written well, they can be powerful, because they help developers and testers view requirements from an end-user’s perspective. They provide context and an understanding of what motivates the people who will use the solutions they deliver.
Unfortunately, however, when people think of how to write user stories it is often done poorly. Business Analysts and business specialists, who are often new to an Agile framework, have never written them, and – as with learning a new language – it takes time to become fluent in user story vocabulary, composition, and best practices. As a result, user stories are commonly incomplete, inconsistent, or missing altogether, putting projects at risk.
AgileConnection – an online community that brings together key Agile principles and ideas from experienced software professionals and thought leaders – shared a list of some of the most common user story issues. Here are five classic mistakes made while writing user stories in agile that you should look out for.
1. System Requirements after “so that…” leads to missed needs.
The “so that…” section should describe business value, not business requirements. For example, in the statement “I need to be able to save my shopping list, so that I can print or duplicate it later,” saving is not the only end user requirement. Printing and duplicating are also requirements, but because they are included in the “so that…” statement, the development team may miss them. Make sure the “so that…” section describes the business value users expect to realize through the story. If needed, create separate user stories to address additional requirements.
2. The Odyssey – or “ultra-huge” story – can’t be digested.
A user story should be written at a level of granularity that enables the development team to accurately estimate the level of effort it will take them to build functionality to support the story. When written too broadly, that is impossible. Additionally, crucial details are likely to be missed. If there are a lot of “ands” or “ors” in your team’s user stories, consider breaking them down into multiple stories, so they can be estimated and understood clearly.
3. Technical stories lead to Waterfall model sprints.
Often teams get lost writing user stories that contain only design or technical requirements. For example: “As a developer, I want to finalize the database table changes, so that I do not have to make changes later.” This is a developer story, not one written for an end-user interacting with the system. It leads to sprints that follow a Waterfall methodology approach. Conduct requirement analysis by scanning user stories that are not written from a business perspective, moving those needs to project planning, design, or implementation documentation.
4. Rigid, inflexible user stories lock teams in.
Another common mistake teams make when writing user stories in Agile is that of including too much detail. This inhibits creativity, boxing the development team in to deliver functionality in the way the user story specifies instead of brainstorming freely to determine the best solution to the problem at hand. Avoid including implementation details in user stories, so the development team can exercise creativity in their solution design to maintain speed and flexibility.
5. Poorly-defined roles lead to confusion.
The first part of a user story is the “As a <role>, I want to…” section. Coming up with the best set of roles for a project can be complicated, and often roles end up being too vague (for example, “As a user…” or “As a business user…”), which does not convey enough information about the end user to the development team.
User story roles can also end up being too specific. For example, if a user story written for a “marketing” role will apply the same way to an “advertising” role, teams end up with duplicate user stories or – even worse – two user stories that should be the same but are not.
Finally, the “system” should never be used as the role in a user story. What the “system” needs to do does not speak to delivery of business value.
For the full list of common user story mistakes and how to correct them, read the full article on AgileConnection.
Blueprint’s auto-generation of user stories in Agile and acceptance criteria helps teams avoid these classic mistakes.
Blueprint is designed to help organizations address these types of real-world, enterprise-scale challenges, so they can continue to grow their automation and Agile development practices. Blueprint accelerates projects and RPA development by automatically generating user stories in Agile – with complete, consistent acceptance criteria – and test cases that can be pushed into any RPA tool you use thanks to our bi-directional integrations with the leading RPA platforms.
For more information, download the Blueprint Business Transformation Platform datasheet or contact us today.
