Skip to content
Cuelogic
  • Services
        • Product Engineering
          • Product Development
          • UX Consulting
          • Application Development
          • Application Modernization
          • Quality Assurance Services
        • Cloud Engineering
          • Cloud Services
          • DevOps Services
          • Cloud Migration
          • Cloud Optimization
          • Cloud Computing Services
        • Data & Machine Learning
          • Big Data Services
          • AI Consulting
        • Internet of Things
          • IoT Consulting
          • IoT Application Development
        • Innovation Lab as a Service
        • Cybersecurity Services
        • Healthcare IT Services
  • Company
    • About
    • Culture
    • Current Openings
  • Insights
  • Tell Us Your Project
Tell Us Your Project  ❯
Processes  4 Mins Read  July 1, 2015  Cuelogic

How to write an effective user stories “AGILE” “SCRUM”

Share Via –
Share on facebook
Share on twitter
Share on linkedin

Home > How to write an effective user stories “AGILE” “SCRUM”

How to write an effective User stories AGILE SCRUM

Story reflect the complexity of the problem, and so, reflect the confidence of how accurate the estimate is. A Story with a high story point tells you that there's a lot going on with the user story that isn't concrete.

If you are being shown an iteration plan with stories with all high story points, this gives you little confidence that the iteration will be executed as expected and that you need to look at other stories for the iteration or start breaking stories down.

When communicating with a Product Owner, high story points mean that it will be extremely cloudy as to when they will get a particular feature. One of the solutions to this is to break the story down and hopefully you'll have a combination of low and high story points to work with so that you can iteratively demonstrate progress to the Product Owner.

Important considerations for writing user stories:

>>Stakeholders should write user stories:

It’s an important concept that your project stakeholders should write the user stories, not the developers. Stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts write them.

>> Remember non-functional requirements:

Stories can be used to describe a wide variety of requirements types.

>> Indicate the estimated size:

One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2x hours per point; therefore the user story will take around 10x hours to implement.

>> Indicate the priority:

Requirements, including defects identified as part of your independent parallel testing activities or by your operations and supports efforts, are prioritized by your project stakeholders and added to the stack in the appropriate place.

Prioritization approaches are possible priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it's own unique priority order number You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. But keep it simple.

>> Optionally include a unique identifier:

The only reason to do this would be is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.

Effective way to write stories:

>> Start with the initial users stories:

User stories are very slim and high-level requirements artifacts. And it describes how a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality.

>> Discover the right stories:

A great way to capture your insights about the users and customers is to use personas aka character. But there is more to it, The persona goals help you discover your stories.

Understand your target users and customers. After all, user stories want to tell a story about the users using the product. If you don’t know who the users are and what problem we want to solve then it’s impossible to write the right stories and you end up with a long wish list rather than a description of the relevant product functionality.

It offers a great way to capture the users and the customers with their needs. They are fictional characters that have a name and picture; relevant characteristics such as a role, activities, behaviors, and attitudes; and a goal, which is the problem that has to be addressed or the benefit that should be provided.

>> Write stories collaboratively:

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.

>> Keep your stories simple and to the point:

Write your stories so that they are easy to understand. Keep them simple and short. Avoid confusing, unclear and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team.

>> Start with epics:

Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time- consuming to relate any feedback to the right stories.

Typically user stories which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Epics are typically lower priority user stories because once the epic works its way towards the top of the work item stack, once you have created your personas, use their goals personas to identify the product functionality.

Epics are great to pictorise the product’s functionality; there is more to your product than epics and stories. You should also capture the user interaction and the sequences, in which the epics are used, the visual design of your product, and the important nonfunctional qualities such as interoperability and performance.

>> Break down your stories until they are ready:

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done.

>> Add acceptance criteria:

As you decompose epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensure that the story can be demoed or released to the users and the other stakeholders.

>> Don’t completely rely on User Stories:

Creating a great user experience requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the non functional properties of your product. These results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.

Recommended Content
Chaos Engineering : Why the World Needs More Resilient System ❯
Will agile development work if you outsource software development? ❯
Tags
agile scrum agile software development methodology user stories
Share This Blog
Share on facebook
Share on twitter
Share on linkedin

Leave a Reply Cancel reply

People Also Read

Big Data

Data Mesh – Rethinking Enterprise Data Architecture

8 Mins Read
Consulting

Top Technology Trends for 2021

10 Mins Read
DevOps

What is Infrastructure as Code and How Can You Leverage It?

8 Mins Read
Subscribe to our Blog
Subscribe to our newsletter to receive the latest thought leadership by Cuelogic experts, delivered straight to your inbox!
Services
Product Engineering
  • Product Development
  • UX Consulting
  • Application Development
  • Application Modernization
  • Quality Assurance
Menu
  • Product Development
  • UX Consulting
  • Application Development
  • Application Modernization
  • Quality Assurance
Data & Machine Learning
  • Big Data Services
  • AI Consulting
Menu
  • Big Data Services
  • AI Consulting
Innovation Lab as a Service
Cybersecurity Services
Healthcare IT Solutions
Cloud Engineering
  • Cloud Services
  • DevOps Services
  • Cloud Migration
  • Cloud Optimization
  • Cloud Computing Services
Menu
  • Cloud Services
  • DevOps Services
  • Cloud Migration
  • Cloud Optimization
  • Cloud Computing Services
Internet of Things
  • IoT Consulting
  • IoT App Development
Menu
  • IoT Consulting
  • IoT App Development
Company
  • About
  • Culture
  • Current Openings
Menu
  • About
  • Culture
  • Current Openings
We are Global
India  |  USA  | Australia
We are Social
Facebook
Twitter
Linkedin
Youtube
Subscribe to our Newsletter

We don't spam!

cuelogic

We are Hiring!

Blogs
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
Menu
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
cuelogic

We are Hiring!

Blogs
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
Menu
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
We are Global
India  |  USA  | Australia
We are Social
Facebook
Twitter
Linkedin
Youtube
Subscribe to our Newsletter

We don't spam!

Services
Product Engineering

Product Development

UX Consulting

Application Development

Application Modernization

Quality Assurance Services

Cloud Engineering

Cloud Services

DevOps Services

Cloud Migration

Cloud Optimization

Cloud Computing Services

Data & Machine Learning

Big Data Services

AI Consulting

Internet of Things

IoT Consulting

IoT Application Services

Innovation Lab As A Service
Cybersecurity Services
Healthcare IT Services
Company

About

Culture

Current Openings

Insights
Privacy Policy  
All Rights Reserved @ Cuelogic 2021

Close

By continuing to use this website, you consent to the use of cookies in accordance with our Cookie Policy.