7 Common User Story Mistakes and How to Avoid Them?
We have seen a drastic increase in the number of products being launched in the recent past. Young startups are disrupting the product ecosystem with cool and innovative products that are developed to resolve multiple problems faced by different customer groups. These companies are leveraging multiple digital technologies such as machine learning, robotics, IoT, and cloud to develop such products either by themselves or by taking help of software product engineering partners.
While product companies want to tap the untapped potential, there are multiple challenges that these companies face pertaining to time to market, product evolution, data paralysis and much more. Product companies have started adopting an Agile mindset to instill pace and business efficiency. These companies ensure iterative and test-driven development to launch products faster.
Software product development companies with Agile mindset have a collaborative mindset ensuring design-led engineering approach and CI/CD led processes. Moreover, with an early and continuous delivery of product, there is a greater project visibility among stakeholders thereby helping them to track the project milestones easily.
There are various Agile frameworks that software product development companies adopt such as Scrum, Kanban, and XP. A user story is one of the key development artifacts for Agile teams.
This blog provides an in-depth understanding of user stories, key mistakes to avoid and how to write winning user stories.
What is a user story?
A user story is a tool or technique which captures specifics of a software feature from an end user perspective. A good user story describes the type of user, what are their asks and why? With a good user story, it becomes extremely easy to simplify the description of software requirements.
Moreover, user stories are also designed to help the technology and development teams remain focused on the end product and customer needs. It helps them to deliver high-quality software quickly.
A user story has three main components:
- Description: A story has a description that reminds about the feature
- Test: A user story test helps to determine whether the story is complete
- Conversation: Conversation is a discussion around the points of interest with respect to the story
Who can write a User story?
User stories can be written by either of the stakeholders although most of the times’ product owner along with others write the story. At times, user stories are also initiated jointly by the product owner, client, development team and scrum manager. Sometimes product owners and other stakeholders also conduct workshops to come up with multiple user stories.
When to write a User story?
User stories are written at the initial stage to get clarity on the features of the product. User stories can also be written when a particular new feature is to be released.
The INVEST Model and Splitting of User Stories:
The INVEST model helps to build user stories that are exhaustive and precise:
- Independent: A user story needs to be independent of other stories.
- Negotiable: A user story is an open invitation to all for a conversation rather than a contract.
- Valuable: The purpose of a user story is to provide value to the end customer.
- Estimable: A story should be short so that it is estimable.
- Simple: A user story should be simple to implement.
- Testable: All the relevant information must be available so that it could be tested by the QA team.
Here’s one more interesting framework and cheatsheet from Richard Lawrence and Agile For All which helps to split the user stories in a better way:
Figure 1 – Cheatsheet (You can view a clearer and larger preview here)
http://agileforall.com
Figure 2 – Framework (You can enlarge and view the entire framework in a downloadable pdf here)
Moving further now that you are aware of the user story and who writes them, outlined below are the five key benefits of developing a user story:
1. Delivers value – The ultimate objective of a user story is to deliver value to the customer. With short and precise feature descriptions, delivering a product as per the expectations becomes easy. Unlike use cases or scenarios, user stories do not describe detailed application interface or flow charts.
2. Provides early feedback – As clients are normally involved in writing user stories, development teams spend time with clients and understand what they need better. With early stakeholder participation, expectations are set right at the beginning of the project. This also helps to fast track product development.
3. Makes it easy for remote teams to understand the project – There has been a tremendous shift from developing products in-house to outsourcing it to a technology partner or remote offshore development center. Countries such as India have preferred outsourcing destinations. User stories act as a powerful arsenal for distributed and remote development projects when the project teams are geographically dispersed or located at different locations in the same city. With the help of user stories, explaining product features becomes easy. At times, technology partners use collaborative tool to communicate user stories to clients, get their feedback and amendments on features. Coordinating on a tool will also eliminate challenges of reviewing user stories on a call or email.
4. Provides freedom to run the product – User stories aren’t detailed. They just talk about specific features of the product. User stories give the development teams flexibility to run the product in their own ways without giving a detailed way of working.
5. Brings speed and agility – With user stories in place, it becomes easy to estimate the roadmap more precisely. Accurate roadmaps and estimates lead to faster development at reduced cost. This is mainly because the scope of end user work is defined and the entire product development plan is clear ab initio. The expedited delivery on account of user stories also increases the ROI.
Most companies that are practicing Agile fail to get user stories right despite they know the importance of user stories.
Getting the user stories correct is vital and therefore we have outlined below 7 common user story mistakes and ways to avoid them:
1. Role not defined – The first part of writing any user story is defining the role of which this is being written. This can be complex for many organizations. If the user role is vague, it would be difficult to address the benefits that would be provided to the end customer. However, some stories are very narrowed and only specific to one particular user than a role.The role can end up being too specific while creating a story. For example, if a user story is written for “marketing” role, same might also be applicable people in advertising and promotional roles. Compared to this when it is written for a specific user say event executive, it becomes too narrowed to one user.
2. Extreme focus on the title or description – User stories are a short description of features that a customer needs. The title of the user story should be short around 3 to 10 words and at the same time should be simple.The purpose of the title is to distinguish a particular story from other. Furthermore, the title should be discussed among all the stakeholders. After finalizing the title, write the complete description of the respective user story.
The template for the standard user story is something like:
As a [persona/role], I can [do this], So that [I get this benefit]
3. No appropriate slicing of stories – User stories can incorporate different levels of details. Some stories are too long that they become vague for the team when understanding and implementing them. It is recommended to start with Epics, which are normally long format user stories and more detailed. These epics can then be split into detailed user stories specific to features. The benefit of breaking Epics into smaller user stories is that it becomes easy for the development teams to understand various features of the product. When epics are slid into feature based user stories, it also provides more structure to the project. Also, these stories need to be testable and feasible.
4. Acceptance criteria / Condition of Satisfaction – As epics further break into smaller stories, it is important to add Acceptance criteria to it. Acceptance criteria or COS is one of the most misconstrue parts of the user story. These criteria’s are set of statements, each has a clear pass or fail result. They specify both functional and non-functional requirements applicable at the current development lifecycle of the product or project. Acceptance criteria have conditions of satisfaction and there is no partial acceptance. It could be either pass or fail. Basis the acceptance criteria, user stories are developed and high-level objective or product features are taken into account. As a rule of thumb, use more than four to five conditions for detailed stories.
Below is the purpose of acceptance criteria:-
- Define boundaries for a feature.
- A minimum functional requirement to add value Define the boundaries for a user story/feature.
- Help teams gain a common understanding of what is required.
- Help QA teams to derive use cases and tests.
5. Writing technology and not features – User stories should be feature-centric and not talk about the technology in specific. If user stories are narrowed and only outlining technical points of discussion, the higher objectives of meeting a product feature expectation will be discarded.
6. No collaboration on writing user stories – Collaboration is the key to succeeding at writing user stories. The product owner, technology teams, testing teams and the customer should all get together before writing a user story. Moreover, the team and the product owner can schedule regular meetings when the new functionality is released or built as this would save time and improve time to market with shorter release cycles and enhance build quality. Paper cards can be a way to capture user stories as there are many advantages to it. With individual jotting down their ideas on paper cards, it can facilitate brainstorming during collaboration. They can be utilized as an approach to keep a check on consistency and envision conditions by gathering them on the table or a wall. Later, these stories can be stored electronically as well. Remember, the more the communication and information flow, the better the output.
7. Not keeping the story visible: Hiding stories on an intranet, network drive or on a licensed tool will prove to be a hazard. Make them visible by putting them on a wall or a table. Some product teams also use a product canvas for storing the user stories. Here’s how it looks:
Romanpichler.com
Developing product doesn’t just require product engineering consulting, but also correct requirement gathering, collaborative design thinking and much more. Practicing Agile is a key to ship releases in time and build products faster. User stories act as arsenal to understanding product features and build as per expectations. It is always recommended to accompany user stories with techniques such as workflow diagram, storyboards or mockups. Writing a well-narrated user story is complex and only the best Agile craftsman should consider writing them along with the stakeholders. User story mistakes such as wrong feature description or poor acceptance criteria will hamper the entire product development. Avoid these user story mistakes or take help of a technology partner that provides software product development services and understands Agile well for the errorless development of such user stories.
