Previous
¶ User Stories
¶ What it is
User stories describe requirements in the software development process and focus on describing roles, functions, and values. They bridge the end users and development teams in natural language.
¶ Why it is useful
User stories make products user-centric. User stories promote cooperation among team members. User stories help prevent feature creep and design dead ends. It can enable team members to understand customers' needs, quickly build consensus, and make products of value to customers.
¶ When to use
After the requirements modelling and verification, the user stories can be created. This must be done before the production team starts working on detailed features.
¶ How is it done
Follow the principles below to create user stories.
- Independent: In most cases, the characteristics described by one story do not depend on other stories.
- Negotiable: Avoid being too detailed, leaving room for discussion and supplementing for details.
- Valuable: The story is to show the product's value to customers. The story describes features, not a single thread user task from start to end. The story is in the customer's language, and the explanation is simple. People who use this product or system can understand this story.
- Estimatable: The story is descriptive, accurate, and concise so that developers can estimate the software workload required to create the functions in the user story.
- Small: It is easier to plan and accurately estimate smaller user stories. A good rule of thumb tells us that a user story should not take up more than half the time of a development team member.
- Testable: You can easily verify user stories and get clear results.
¶ Do's & Don't
Do's
- Set unified tags at the beginning of user story titles so the readers will get the highlights without going into story details. Imagine a list of story titles. Tags help a lot.
- Always link the Epic ticket to the user stories to provide a better understanding of the scenario efficiently.
Don't
- Don’t make the user story title too generic, which gives no valuable Information.
¶ Tools needed
¶ User Story Elements
A user story is to think about the functions that users need from the perspective of users. So a good user story must include the following three elements:
Role: Who will use this function？
Activity: What functions need to be included？
Business value: What value this function brings to customers?
Furthermore, user stories should at least include the following:
Title: the name of the user story (generally short for the function);
As: a user or role (element: role);
I want to: take such actions (elements: activities);
So that: I get such benefits (element: business value).
Some other elements of a user story could be:
- Reporter
- Story points
- Business value
- Acceptance Criteria
- etc
BDD v.s. Acceptance Criteria
BDD is a common way to define a user story's acceptance criteria. It bridges the user perspective expectation and the technical implementation contents of the development team.
Given … (precondition)
When … (action)
Then …. (Expected result)
What are the differences between features and user stories?
First, let’s look at the common places: both are used to describe requirements and convey the functionalities of a software system.
Then why do you still need user stories when you have features already?
Features are simple and have brief descriptions of functionalities. For example, ‘NGO wishlist for manual confirmation’. It should be concise and doesn’t need details. That’s also why it can fit into the feature tree as just a node.
User stories are complex with micro details that the designers, developers, and testers must pay attention. User stories are under the feature level. A user story is the smallest unit of a testable functionality that can be delivered and accepted. It is independent and quite atomic compared to features.
¶ Example
