Author Topic: How do we write a effective user story ?  (Read 5775 times)

1202894803

  • Global Moderator
  • Newbie
  • *****
  • Posts: 5
Re: How do we write a effective user story ?
« Reply #15 on: June 04, 2020, 11:16:01 pm »
the things we should care  about before writing a user story:
?understand the requirement
?draw use case diagram
?draw activity diagram
?try to understand the whole scenario
?start writing from First use case
?consider things accordingly

1192091407

  • Global Moderator
  • Newbie
  • *****
  • Posts: 11
Re: How do we write a effective user story ?
« Reply #16 on: June 05, 2020, 06:22:14 pm »
Any Example of Validation?

1202988902

  • Global Moderator
  • Newbie
  • *****
  • Posts: 5
Re: How do we write a effective user story ?
« Reply #17 on: June 18, 2020, 03:36:35 pm »
User stories are simple, one-line benefits statements of a valuable function. Prior to writing the user story, conduct user surveys and interviews to query the user about needed functionality. Start by writing a customer journey, stated in incremental stories, on 3x5-inch cards or Post-it notes. These cards can be put immediately into production or provide context for the backlog.

In the case of user story mapping, you can display Post-it notes along a conference room wall so the entire team can see it and work on long-range planning.

There are a few techniques you can use to help write the stories you need. A common technique is the Role-Feature-Reason or Benefit (RGB) structure that you construct by filling in the blanks of this sentence:

As a (user/persona/customer), I want to (do something) so that I will (receive a benefit).
Adding to the RGB question is a method pioneered by Ron Jeffries which highlights his ?three C approach:?

Card: Write the answer to the RGB (described above) on the card.
Conversation: The limited detail on the card is the basis of a promise fulfilled by the second C. During this phase, the team discusses the details and establishes a definition of ?done.?
Confirmation: This is the result of feedback that determines the test or acceptance criteria. This acceptance criterion is often written on the back of the card and is used as the initial checklist during future meetings to determine completion.
First introduced in an article by Bill Wake in 2003 and popularized by Mike Cohn?s book, User Stories Applied for Agile Software Development, the acronym INVEST is a method to evaluate user stories. INVEST criteria is as follows:   

Independence to develop in any sequence.
Ability to Negotiate the extent of the story to develop.
Provides Value to the user or business. 
Can be Estimated for completion.
Is Small enough to design, code, and test in a single iteration.
And finally, can be Tested.

1202408706

  • Global Moderator
  • Newbie
  • *****
  • Posts: 3
Re: How do we write a effective user story ?
« Reply #18 on: September 22, 2020, 10:11:13 pm »
A user story has an equation followed by
As a <type of user>, I want <some feature> so that <some reason>
As a <type of user> ? this is the WHO. Who are we building this for? Who is the user?
I want <some feature> ? this is the WHAT. What are we building? What is the intention?
so that <some reason> ? this is they WHY. Why are we building it? What is the value for the customer?

Eample:
As an internet banking customer
I want to see a rolling balance for my everyday accounts
So that I can keep track of my spending after each transaction is applied

1202638409

  • Global Moderator
  • Newbie
  • *****
  • Posts: 11
Re: How do we write a effective user story ?
« Reply #19 on: November 21, 2020, 05:16:00 pm »
How a BA can be most efficient in a project is by writing great user stories. The backbone of any project is to write a solid user story based on which a project's destiny is decided . So the key ten points to write a magnificent user story are given as follows:-

1. Users Come First.

2. Use Personas to Discover the Right Stories.

3. Create Stories Collaboratively.

4. Keep your Stories Simple and Concise.

5. Start with Epics.

6.Refine the Stories until They are Ready.

7. Add Acceptance Criteria.

8. Use Paper Cards.

9. Keep your Stories Visible and Accessible.

10. Don?t Solely Rely on User Stories.


1210387404

  • Newbie
  • *
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #20 on: June 03, 2021, 07:06:28 pm »
User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But telling effective stories can be hard. The following ten tips help you create good stories
1. User come first
2. Use personas to discover right stories first
3. Create stories collaboratively
4. Keep your stories simple and concise
5. Start with Epics
6. Refine the story until they are ready
7. Add acceptance criteria
8. Use paper cards
9. Keep your stories visible and accessible
10. Don't solely relay on user stories

1210591304

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #21 on: August 09, 2021, 12:38:28 pm »
User Story is a popular format of representing a feature or user requirements of a software system from an external user perspective. The format comprises of three key elements as shown below:
As a <User role>
I want <to do something>
So that I can <achieve some goal>
The user role represents a type of user (and not an individual user). The requirements are presented from this user role perspective ? <to do something>. The third part of the user stories is the purpose of the action.
The user stories, not only, represent the system feature/requirements, it also explains ? why it is being done?

User Story Example
Let?s a simple example to understand the user stories basics better. A customer is looking to get a travel portal for flight tickets booking. One of the requirements for this portal is the search of flight tickets for a business traveller. The user story for this case can be presented as shown below:

As a <User>
I want <to search for flight tickets as per my schedule>
So that I can <so that I can attend a business conference>

The good thing about user stories is that every stakeholder (customer as well as developers) gets a complete idea about the requirements.


Writing good user stories
What are the characteristics of a good user story? Well-written user stories are critical to the success of a project. INVEST represents the characteristics of a good user story as explained below:

Independent ? User Stories should be as independent as possible.
Negotiable ? User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
Valuable ? User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
Estimable ? User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
Small ? User Stories should be small. Not too small. But not too big.
Testable ? User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
In addition to INVEST principle, some important points should also be considered while writing user stories:

At the time of writing user story, the requirements would not be very clear. It is advisable to capture all the assumptions and constraints related to requirements / user stories. These assumptions provide the basis for managing risks.
Ensure that user stories are written clearly and have no ambiguity. A very famous example is usage of word bi-weekly. Many people treat it as once in 15 days, where as other group of people may consider this as twice in a week.
Use a mutually agreed user story format as there is no standard format of a user story and that can lead to confusion.
Clearly mention the Acceptance Criteria. Acceptance criteria help in the definition of DONE? Done definition helps in identifying when a user story is completed
It?s always advised to keep refining the product backlog. This will ensure that new user stories are getting added to the list and also the stories which were on low priority might get enough attention.

12114113106

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #22 on: September 27, 2021, 10:52:54 pm »
1.Begin with the first user stories.
2.Find the appropriate stories
3.Collaborate to write stories
4.Make your stories brief and to the point.
5.Break down your stories until they are ready
6.Include acceptance criteria

Don't rely solely on User Stories:

Writing user stories isn't enough to create a great user experience. Consider your product's user journeys and interactions, visual design, and non-functional properties. This produces a comprehensive description that makes it easier to identify risks and assumptions, and it increases the likelihood of producing a product with the appropriate user experience.

1210895805

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #23 on: October 01, 2021, 07:42:28 pm »
The benefits of User-story are to keep the focus on the user. A To Do list keeps the team to focus on the tasks to be finished. A user story enables collaboration, creates momentum and drives the team to get creative solutions.
The format to write a user story is
As a (ROLE), I can (FEATURE), so that (REASON)
User stories should be short, precise and easy to understand.
Example:
As a USER I want to login
So that
I can ACCESS THE SOFTWARE

12121113406

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #24 on: October 03, 2021, 09:01:45 pm »
User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But telling effective stories can be hard. The following ten tips help you create good stories. 1 Users Come First As its name suggests, a user story describes how a customer or user employs the product; it is told from the user?s perspective. What?s more, user stories are particularly helpful to capture a specific functionality, such as, searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality (symbolized by the circle). If you don?t know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas?but not on data and empirical evidence.

2 Use Personas to Discover the Right Stories
A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviors, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product. But there is more to it: The persona goals help you discover the right stories: Ask yourself what functionality the product should provide to meet the goals of the person

3 Create Stories Collaboratively User stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery. You can take this approach further and write stories collaboratively as part of your product backlog grooming process. This leverages the creativity and the knowledge of the team and results in better user stories.

4 Keep your Stories Simple and Concise Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what?s important, and leave out the rest. The template below puts the user or customer modelled as a persona into the story and makes its benefit explicit. It is based on by Rachel Davies? popular template, but I have replaced user role with persona name to connect the story with the relevant persona.

5 Start with Epics An epic is a big, sketchy, coarse-grained story. It is typically broken into several user stories over time?leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and a placeholder for more detailed stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users. It also reduces the time and effort required to integrate new insights. If you have many detailed stories in the product backlog, then it?s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing inconsistencies.

6 Refine the Stories until They are Ready Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story?s meaning; the story should not be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done.

7 Add Acceptance Criteria
8 Use Paper Cards User stories emerged in Extreme Programming (XP), and the early XP literature talks about story cards rather than user stories. There is a simple reason: User stories were captured on paper cards. This approach provides three benefits: First, paper cards are cheap and easy to use. Second, they facilitate collaboration: Every one can take a card and jot down an idea. Third, cards can be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

8 Use Paper Cards User stories emerged in Extreme Programming (XP), and the early XP literature talks about story cards rather than user stories. There is a simple reason: User stories were captured on paper cards. This approach provides three benefits: First, paper cards are cheap and easy to use. Second, they facilitate collaboration: Every one can take a card and jot down an idea. Third, cards can be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

9 Keep your Stories Visible and Accessible Stories want to communicate information. Therefore don?t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible, for instance, by putting them up on the wall. This fosters collaboration, creates transparency, and makes it obvious when you add too many stories too quickly, as you will start running out of wall space. A handy tool to discover, visualise, and manage your stories is my Product Canvas shown below.

10 Don?t Solely Rely on User Stories Creating a great user experience (UX) requires more than user stories. User stories are helpful to capture product functionality, but they are not well suited to describe the user journeys and the visual design. Therefore complement user stories with other techniques, such as, story maps, workflow diagrams, storyboards, sketches, and mockups. Additionally, user stories are not good capturing technical requirements. If you need to communicate what an architectural element like a component or service should do, then write technical stories or?which is my preference?use a modeling language like UML. Finally, writing user stories is worthwhile when you develop software that?s likely to be reused. But if you want to quickly create a throwaway prototype or mockup to validate an idea, then writing stories may not be necessary. Remember: User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible?not to impose any overhead.


1190761312

  • Global Moderator
  • Newbie
  • *****
  • Posts: 11
Re: How do we write a effective user story ?
« Reply #25 on: October 05, 2021, 08:11:38 pm »
The effective user stories enables teams to deliver right products fast by following effective checklist :
1. User comes first: As name suggest these describes how a user employs the product , So user to be considered first .
2. Keeping Stories simple and concise: Writing stories that are simple and concise  is the most effective way as it avoids confusion and ambiguity. The stories needs to be written in active voice and should be focused on what is important.
3.Create Stories Collaboratively: User stories are intended as light weight technique and they should be embedded in a conversation. The product owner and the team should discuss the stories together as it allows  to capture minimum amount of information, reduce overhead and accelerate delivery.
4.Starting with EPICS: An epic is a big sketchy, coarse grained story. Starting with epics allows to sketch the product functionality without committing to the details which helps in describing new products and features. It also reduces time and effort required to integrate new insights.
5.User story should be INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testable)

1212490604

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #26 on: October 12, 2021, 10:39:45 am »
A User Story has three primary components, each of which begin with the letter ?C?

Card
The Card, or written text of the User Story is best understood as an invitation to conversation. This is an important concept, as it fosters the understanding that in Scrum, you don?t have to have all of the Product Backlog Items written out perfectly ?up front?, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories.
The Card is usually follows the format similar to the one below

As a <user role> of the product,

I can <action>

So that <benefit>.

In other words, the written text of the story, the invitation to a conversation, must address the ?who?, ?what? and ?why? of the story.

Conversation

The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.

As much as possible, this is an in-person conversation.

The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.

This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

Confirmation

The Product Owner must confirm that the story is complete before it can be considered ?done?
The team and the Product Owner check the ?doneness? of each story in light of the Team?s current definition of ?done?
Specific acceptance criteria that is different from the current definition of ?done? can be established for individual stories, but the current criteria must be well understood and agreed to by the Team. All associated acceptance tests should be in a passing state.

12105103006

  • Global Moderator
  • Newbie
  • *****
  • Posts: 10
Re: How do we write a effective user story ?
« Reply #27 on: October 15, 2021, 12:28:39 pm »
User Stories are one of the core elements of the Agile methodology. However, they?re often jumbled with software requirements which isn?t true. The main aim of this element is to put end users in the center of conversation and capture product functionality from their perspective.

Great User Stories always fit the INVEST set of criteria by Bill Wake:

Independent ? they can be developed in any sequence and changes to one User Story don?t affect the others.
Negotiable ? it?s up for the team to decide how to implement them; there is no rigidly fixed workflow.
Valuable ? each User Story delivers a detached unit of value to end users.
Estimable ? it?s quite easy to guess how much time the development of a User Story will take.
Small ? it should go through the whole cycle (designing, coding, testing) during one sprint.
Testable ? there should be clear acceptance criteria to check whether a User Story is implemented appropriately.