How to Identify Good and Bad Agile User Stories

By: Strategic Services Team | February 11, 2020

What Makes a Good User Story?

The most common checklist that is applied to identify a GOOD user story was coined by Bill Wake, and it is the acronym INVEST. It stands for:

I – independent
N – negotiable
V – valuable
E- estimable
S – small
T – testable

Let me briefly explain each of these, and how it relates to the quality of a User Story.


This seems obvious, doesn’t it? Well, in case it’s not, whenever possible you should strive to keep each User Story independent from another. This means sequencing your stories so there are no dependencies. It also means writing them in a way that does not create dependencies. This can be quite difficult to do and will take a lot of practice to get it right. Sometimes dependencies are unavoidable, but do try to avoid them, if you can.


The items in the Product Backlog need to be negotiable (and negotiated). Just because someone adds an item to the backlog does not necessarily mean it will be developed. All stories in the backlog should be able to be questioned.

One other tip on this is that the solution should not be specified as part of a User Story or its Acceptance Criteria. User Stories describe the “who, what, and why” – not the “how” (which is the development team’s responsibility).


Each story should be valuable to the user. A tangible benefit to the user should be clearly articulated, and it should align with a business goal. If a feature does not have a solid value proposition, question whether it should be done at all.

Also, watch out for stories that are written from the wrong sort of perspective (such as from a developer’s point-of-view) – these will most likely not provide any direct value to the end user.


A User Story must have enough detail for it to be estimated, or sized, by the development team. If there are open questions, big gaps, or it’s too big, it’s likely that the team will not be able to size it. This isn’t to say that there must be a huge specification written – it needs to include just enough information, just in time, and any further details can be discovered during development.


Stories need to be small enough to be completed within a sprint or iteration. I’ve seen some say you should target stories to be equivalent to about 1-2 days of work, but I have also seen teams use a rule, like, “If the story has been estimated at 8 Story Points or above, it’s too big and needs to be decomposed further before being considered for pulling into a Sprint”.

How you size your stories will also be somewhat dependent on the length of your sprints and the size of your team. The main point here is that they should be small enough to be completed (to your definition of done), within a single Sprint.


Stories also need to be testable. This is where the Acceptance Criteria really comes into play. Ideally, it can be used as a further quality checklist (on top of your overall definition of done) that a tester can test for a pass/fail result. If there is anything ambiguous or unclear, if there are missing scenarios, and if unhappy paths are omitted (unless intentionally), then you may have suboptimal results. Ensure that you have clear, crisp, and concise Acceptance Criteria for each of your User Stories.

(You can also use this as a “pointer” to figure out if you need to split a story; if you find you are writing far too many scenarios or criteria, then it’s probably a good sign that you have too much going on in that story.)

What Makes a Bad User Story (aka User Story “Smells”)?

Now it’s time to explore the flip side of the coin. Here’s what you should look for to identify BAD stories (or, in the parlance of Agile, Story “Smells”).

Stories Violate Any INVEST Quality Criteria

This includes stories that are:

  • Dependent on other stories
  • Haven’t been discussed, questioned, or negotiated (or you skipped the conversation)
  • Have no value to the customer or end users
  • Don’t have enough information to be sized or estimated by the team
  • Too big
  • Are not testable

Stories Are Written from an Improper Perspective

Rather than being written from a customer or end-user perspective, stories are:

  • Written from a Product Owner’s perspective (WRONG)
  • Written from a Developer’s perspective (WRONG)
  • Written from a generic user’s perspective, without considering other roles

Stories are Poorly Sliced

  • Stories are split horizontally (by technical layer) instead of vertically
  • They are sliced in ways that don’t deliver value

Stories are at the Wrong Level of Detail if They…

  • Include too much detail
  • Don’t include enough detail
  • Forget about progressive elaboration
  • Don’t include the “why” part of the story – they just state what the user wants

Acceptance Criteria…

  • Are missing
  • Don’t include conditions of satisfaction (boundaries for testing)
  • Specify the solution (they shouldn’t)
  • Include the look and feel (they shouldn’t)
  • Don’t include enough information to be truly “suitable for development”
  • Have open questions or gaps
  • Have no definition of “Ready” for stories
  • Don’t include items such as non-functional requirements – which are often overlooked (or could be included in the team’s definition of done, since they often apply broadly across a project)

As you can see, there are many issues to watch out for when evaluating the quality of User Stories (and their Acceptance Criteria). These are clues that can help us when we approach how to split User Stories in appropriate ways to make them small, but still valuable.

Core's Strategic Services team of Project Managers, Scrum Masters, and Business Analysts provide mission-critical leadership to guide our clients' projects to success.

Subscribe to our Newsletter

Stay informed on the latest technology news and trends

Relevant Insights

Cisco On-Premises Calling End-of-Life Options and Next Steps

If you are running Cisco on-premises Calling applications (including Cisco Unified Communications Manager), be aware that the end-of-sale date for...
Read More

14 New Updates to Microsoft Teams | March 2023 Update

There are many changes to Microsoft Teams to report on this month – especially with the introduction of Teams Premium...
Read More

Machine Learning Requires a Strong Data Foundation

When business leaders find themselves interested in machine learning (ML), there is often a desire to jump right into the...
Read More