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.
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.
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:
Figure 1 – Cheatsheet (You can view a clearer and larger preview here)
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.
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 a collaborative tool to communicate user stories to clients, get their feedback and amendments on features. Coordinating a tool will also eliminate the challenges of reviewing user stories on a call or email.
4. Provides the 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 the 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 a 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. The 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 a “marketing” role, the same might also be applicable to 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 others. 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 misconstrued parts of the user story. These criteria are a set of statements, each has a clear pass or fail result. They specify both functional and non-functional requirements applicable to 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 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 key to ship releases in time and build products faster. User stories act as an arsenal to understanding product features and build as per expectations. It is always recommended to accompany user stories with techniques such as workflow diagrams, 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 descriptions or poor acceptance criteria will hamper the entire product development. Avoid these user story mistakes or take the help of a technology partner that provides software product development services and understands Agile well for the errorless development of such user stories.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.