Software Estimation

How to Nail Your User Stories

Luis Ortiz

Aug 1, 2022 — 11 min read

Normally, Product Owners, with the help of Business Analysts and Scrum Masters, develop and refine the Stories that will be worked on during the project's lifespan. Developers and Testers may also suggest some. This dynamic, while effective, can cause inconsistencies.

Anybody can propose User Stories. But crafting good ones requires knowledge of the product, customer, team, and business objectives, as well as refined drafting skills. All that, wrapped up within Agile principles and experience, will make Stories comprehensible and compelling for anyone involved in the project.

Keep reading to learn the foundations for writing great User Stories.

Topics to Check

What is a User Story
a. Epic
b. User Story
c. Use Case
d. Task and Sub-task
How to Write a Good User Story
a. The INVEST formula
b. User Personas
c. The Definition of Ready (DoR)
d. The Definition of Done (Dod)
e. User Story Examples
User Stories and Estimations
a. Story Points
b. Story Refinement
c. Re-estimating

1. What is a User Story

A User Story is an easy way to capture needs, requirements, and a general description for each Backlog item. These are traditionally written from the user's perspective, with a simple format such as the following:

As a [User Persona], I want to [Perform this action] so that I can [Accomplish this goal].

Let's check each concept inside the brackets:

User Persona - A fictional character that represents your ideal user. Some teams establish several personas to visualize how a feature may be employed by different profiled users.
Perform this action - This represents the task that the user wants to execute. At this point, you should focus on the What, and be as brief and clear as possible.
Accomplish this goal - After considering which kind of user wants to perform a given action, it's time to think about the reasons or, more precisely, its objective while doing so.

User Stories originated in Extreme Programming (XP) and are meant to "provide enough detail to make a reasonably low-risk estimate of how long the story will take to implement." Do not cram more than one action to be performed and one goal to be accomplished per Story. Keep it simple.

a. Epic

User Stories are a great way to visualize what the team should develop concretely. However, when its scope is too big, it is better to think of Epics, which are nothing but a collection of User Stories with a unified goal.

Some generalities to better understand Epics:

How big should an Epic be? As with Stories, teams will always consider the size of work items as a relative measure based on other delivered tasks or projects. An example of this would be to launch a Credit card payment option for all your service tiers. It would require several Stories focused on users being able to use said option.

Initiatives are bigger than Epics. Adding layers of hierarchy depends on the circumstances. Many teams find it comfortable to put Epics at the top of the pyramid. Initiatives agglomerate Epics into more complex programs inside organizations that use scaled Agile frameworks, such as SAFe.

Themes take the crown. Some organizations use Themes as strategic pillars to frame Initiatives, Epics, and Stories. Regardless of the size of your company, this method can improve the bonds between your company values and the products or services you supply.

Epics outside software development. If you are adopting an Agile focus to manage projects that aren't related to crafting digital products, you can use Epics too. Once, we learned that a steel factory in Iceland uses Epics inside Jira to manage stock replenishing each time a ship comes into the harbor.

Learn more about that factory and how the Jira use cases are everywhere.

b. User Story

We've described Stories, their origins, and how to use them. It's critical to consider them an integral part of the Agile software development process. In terms of conceptual hierarchy, Stories should be contained inside Epics.

c. Use case

These are used when it makes sense to dig deeper into how a feature would address a Story but on a more technical level. The main difference between User Stories and Use Cases is that the latter is more granular and technical detail-oriented. This makes Use Cases dependent on Stories.

d. Task and Sub-task

At the bottom of the pyramid lie these two classes of items. Tasks act as a translation of the Story into actionable requests, totally focusing on the What. Consequently, Sub-tasks are more granular and serve the person committed to performing the task to break down the job tracking as required.

These hierarchies aren't meant to be blindly followed. You should use them as they fit within your projects and organization.

2. How to Write a Good User Story

User Stories are a backbone for effectively communicating what should be implemented to deliver value. Themes, Initiatives, Epics, Tasks, and Sub-tasks quality (and execution) highly depends on defining explicit Stories. The following are the key aspects to consider.

a. The INVEST formula

This acronym represents a set of criteria employed to assess the quality of a User Story. While not all Stories might comply with all lineages, failing to cover most of them should be enough reason to review or re-write a Story.

Independent. Meaning it won't become a blocker nor has dependencies on other Stories. Though this is desirable, an unforeseen dependency can spot, and you're not going to rephrase and repurpose it. You might have to create a new User Story to unblock the latter.

Negotiable. In case of being blocked or losing time-sensitive relevance, it can be reserved for later work cycles. In all cases, the product should address market needs, but there can always exist some legal agreements to be honored. Pivoting is key in Agile.

Valuable. It must add value by itself. The point of a Story is to produce something that can be tested and used. Depending on the Definition of Ready (DoR) established by the team, it might be required to create appropriate documentation. More on that later.

Estimable. The effort required for its completion is measurable. Even if estimates tend to fail, practicing it is essential to understand and improve the performance of any team.

Small. It should fit into a single sprint, iteration, or work cycle.

Testable. It must be tested before being released to production.

This formula should be in the toolbox of any professional Product Owner. However, there might be cases when a Story might lack one property, such as Independency from others or being Negotiable due to contractual reasons.

b. User Personas

INVEST is an excellent method to sculpt Stories. But considering who will be benefited is essential to address users' needs. Hence, some teams define User Personas to calibrate their aim. For defining useful Personas, you might employ the following techniques:

Gather feedback from users - This will let you understand who the persons using your product or service are, what motivates them, and what their pain points are.

Prototyping - Launching Minimum Valuable Versions of your product will let you know who the people interested in using it is. Try catching their opinion with online forms.

Digital analytics - Unleash the power of analytics to understand where your users are located, their position, affinities, etc. Any data source that helps you better understand your audience and users is valid.

Some examples of User Personas are:

Katy Success, a 29-year-old Customer Success Sr manager, based in Paris, working for an e-commerce company.

Project Paul, a 34-year-old Project Manager based in Seattle, working for an assets company.

You may target Katy and Paul with the same service, but they definitely have somewhat different needs. You must consider the two profiles while developing your Stories.

Maybe you'll prioritize Stories around Katy over Paul due to her leading several teams, meaning a potentially more significant headcount of users. The possibilities are endless if you do your research.

c. The Definition of Ready (DoR)

We have gone through two techniques to help you conceive better User Stories. Then there are the acceptance criteria, meaning what any Story should include before being picked up by the team. In Agile, this is called Definition of Ready (DoR) and must be understood by all teammates.

There is not a universal way to establish your DoR. It mostly depends on what better suits your business goals, but here are some guidelines that you might find helpful:

It should follow general business rules - An excellent way to begin is to stick to the company policies regarding what is considered delivered work.

For example, documentation for any performed task is required in most companies. The same goes for this: A Jira issue or any sort of ticket should exist for each User Story.

There must be a look & feel guideline - When delivering experiences for engaging any kind of user, aesthetics play a crucial role in how any solution may be deployed without disruption.

It would be great to have a mock-up for each Story, but if not possible, a general view with a supporting wireframe can be beneficial.

It must have been estimated - Before starting to work on anything, it should get in the Sprint Backlog and have been reviewed by the team to estimate how much effort it will take. We'll dig deeper into estimates later.

The team at SoftwareDevTools uses the following checklist:

A mock-up must exist - The UI team usually delivers design prototypes in Figma.

A document must exist - All stories are contained in individual issue cards.

A deployment environment must exist - Devs must know where they should deploy their solutions.

Now that we have reviewed what it is, you may think: Then, who creates the Definition of Ready? The whole Scrum team should do it, as it's one of the main consensuses in product/project management.

If your team isn't adding input for each area, you might want to revamp your process.

d. The Definition of Done (DoD)

Considering that a ticket or issue has been concluded should meet the Definition of Done (DoD). It is a set of conditions that must be met to ensure quality, lower rework, and prevent any incomplete feature from being promoted to higher-level environments.

Having clear and well-established Definitions of Done is critical for the success of any software project. Still, it can also benefit teams working in other areas, such as recruitment, marketing, etc.

You may want to consider the following elements to formulate your Definition of Done:

There must exist test cases
When delivering code, it should achieve over 80% of test coverage
It must comply with 100% of the Quality Assurance tests
Related documentation is up to date, including all points mentioned before

It's critical to understand that the Definition of Done differs from the Acceptance Criteria. The latter refers to a set of test scenarios that should be met to ensure that the product works correctly. In any case, Acceptance Criteria can be part of you Definition of Done.

As you can see, both the Definition of Ready and the Definition of Done are crucial for your projects to be successful, so be sure to properly establish them before jumping into action.

e. User Story Examples

If you need some inspiration for understanding how to nail your Stories, consider these examples:

As a Restaurant Manager, I want to easily capture customers' feedback about the service to detect improvement areas.
As the Leader of a Remote Team, I want our project management tool to integrate with the company's cloud environment.
As a Musician, I want to listen to previews of my compositions to be able to record more accurate material in fewer sessions.

Note that these examples are straightforward. Always consider a User Persona, and don't tackle technical matters.

3. User Stories and Estimations

We've gone through quite a ride, from the basics of User Stories to good practices and even some examples which should help you get started. After creating them, you want to put them in the Product Backlog and Sprint Backlog, two primary artifacts in Scrum, to be executed appropriately.

Simply put, the Product Backlog contains all Stories that may be completed to conclude the product or project delivery. Similarly, the Sprint Backlog contains the items that should be worked on during the next Sprint or work cycle.

The main person in charge of crafting and communicating Stories is the Product Owner (PO). When working with Scrum, most of the time, this happens in a three-step dynamic:

1- The PO understands at a high level the solution to be developed and who might be its potential users. This first process is mainly based on business stakeholders' expectations about what can bring value to the company.

2- The PO creates a Roadmap, which includes the Epics or Stories required to achieve what stakeholders request, stating the estimated time it will take for features to be delivered.

3- When it applies, the PO works alongside the Scrum Master (and Business Analyst) to refine the Stories and prioritize them to define which ones will be performed on which Sprint or cycle. This leads to the consolidation of the Sprint Backlog.

4- After the Sprint Backlog has been communicated, the Development reviews it and can raise any inquiries before estimating how much effort the Stories might require. The latter is done during an Estimating Session when the team assigns Points to each Story.

a. Story Points

Estimating is never an easy task. Due to that, one of the best practices adopted by teams worldwide is using Story Points to represent how easy or hard to develop a Story may be.

The most well-accepted method for estimating is using a Fibonacci sequence-based scale, where small numbers represent low effort.

Learn the best techniques for more accurate estimations.

Some people opt to estimate in hours or even days. While there's no wrong path, it might be even harder to estimate within time measures, especially for recently formed teams or when working with new technologies, which is often the case.

Dig deeper into how estimates tend to fail but still are worth doing.

b. Story Refinement

Working with Stories requires flexibility and dynamism. Even the INVEST formula states that User Stories should be negotiable. This means that they can be swapped by another item from the Product Backlog when required, but also lets there be room for improving or further clarifying one.

The refinement may happen at any time during the Sprint. Let's say a developer got assigned a Story and, while working on the solution, a blocker arises, requiring a workaround that may alter it somehow. Engaging with the Scrum Master or even the Product Owner is fine to properly handle it.

c. Re-estimating

Would you need to do a new estimate after refining a Story? Our suggestion is to skip re-estimating most of the time. Ultimately, you want the team to better foresee how much effort jobs may take without going all in. Being able to do so is a core feature of Agile.

In the words of expert Mike Cohen, "There are times when you want to re-estimate. Generally, re-estimating is useful when you completely blew it on the original estimate and can see that the mistake was a rare occurrence. (That is, if every estimate is systematically off by half, I wouldn't re-estimate)."

We encourage to discuss any significant inaccuracy during the Retrospective session at the end of the work cycle to improve the process in the future. Story Points serve to calculate Velocity, a metric that expresses how much work the team might be able to handle during a period based on past experiences.

Velocity is helpful to forecast delivery capacity, as well as being valid for scheduling and budgeting purposes. If you keep re-estimating, you might lose sight of original estimates, highly altering the perception about what can be delivered, especially while dealing with high uncertainty projects.

In conclusion

User Stories are vital for effective Software Development practices but can be helpful in any professional context. If you understand the driving reasons behind creating simple yet straightforward Stories, it will be easier to make them.

Conceiving great User Stories will also enhance your estimation skills, as clear expectations make it easier for team members to delimit their scope. Use the formulas suggested in this article, and you'll do better each time.

Check out our tools:

Stay on top of our upcoming releases:

And subscribe to our blog below!