User stories are the primary construct for capturing product functionality, but they are typically not well-suited to describing the relationship between different features and functional workflows. This blog will first examine the possible effects of ambiguous user stories, then explore an alternative solution that will create more clarity.
Too often, developers don’t know if they have delivered what the customer wanted until reaching user acceptance testing (UAT). At this stage, ambiguous or misunderstood user stories can be the root cause of rework and delays. Unless all stakeholders involved in the process of planning, design, development, and testing share a common understanding of the intended results, a project is at risk of delay or even failure.
Agile project teams will typically address ambiguity during planning, standups, or ad hoc conversations. In Agile development projects, it can be extremely helpful to remove ambiguity earlier before a developer writes the first line of code. The cost of rework increases significantly in later phases of development.
In waterfall and iterative development approaches, it is even more important to remove ambiguity as early as possible. The less ambiguity you have at the outset, the more likely you’ll deliver what the business wants with higher quality and velocity.
User story models help validate functionality, elicit user feedback on requirements, and provide a framework to determine development techniques. Most importantly, models provide clarity and remove ambiguity for all application stakeholders. Below is a list of benefits that can be derived from having a user story model:
It is often said that a picture is worth a thousand words. That can literally be true when a user story has complex application requirements and logic. Providing a visual representation reduces rework and delivers what the business needs.
User story models are often seen as an unnecessary step in an Agile development process. They can, however, significantly reduce rework efforts by delivering the right solution faster and with better quality. Let's look at some of the best practices for user story modeling.
One of the goals of user story modeling is to create a shared understanding of the desired product functionality. It is important to involve all stakeholders in the process of creating the model.
Focus on this specific user story. Don’t include functional references to other user stories or include unnecessary information.
User stories can be loaded with complex requirements. Try to model individual paths separately. Be careful with dependencies on other requirements.
In person collaboration is extremely difficult in a post-Covid-19 world. Electronic tools allow for collaboration and versioning. Remember: the user story may change over time.
Additionally, electronic tools may allow you to generate content such as tasks, test data, or test cases out of the model.
Many times, you’ll work on a user story that results in a change to an existing application. The user story model may not exist. Model the change and the existing portion of the model. Over time, it will grow to near completion.
User story modeling can create a shared understanding of the desired product functionality. Furthermore, working collaboratively with all stakeholders gives everyone an understating of the desired outcome.
It may feel like an unnecessary step that can slow you down, but sometimes you have to “slow down” to speed up.