Skip to content

Garbage In, Garbage Out: Why Bad User Stories are Bad for Business.

This time five years ago, I weighed as much as an adult male giant panda. Two years after I gave birth to the very active and delightfully inquisitive Dylan, I couldn’t even fit into my maternity clothes. I was tired. I was unfocused. I was not happy. And I was obese. Something had to change. 

I made several attempts to lose weight over the course of 2 years including joining Weight Watchers that yielded very little success.  Soon after, I began meeting with a trainer whose gym was just minutes from where I lived. I committed to 3 personal training sessions per week at 5:15am. I also was allowed to attend any of the high intensity group sessions for free on weeknights and weekends, which I eagerly attended as my schedule permitted.

Never miss a post.

Sign up now and receive updates when we post new content.

I will never give away, trade or sell your email address. You can unsubscribe at any time.

After 4 months of this, I began seeing pretty decent results but for the amount of effort I put in week after week, I knew I was still missing something. Then one morning after a really tough session and venting my frustration, my trainer said to me, “I see how hard you work and you never whine or complain, but you can’t go home and just eat garbage. You can’t out train a bad diet. You have to put good fuel in your body if you want it to run good, be healthy and fit.” 

While studying everything I could about food, I came across a familiar phrase that I have heard so many times, “You Are What You Eat” and boom, the light bulb went off on so many levels about so many things in my life personally and professionally. I’d spent the first half of my career as a systems engineer and there are two key principles I often fall back on when trying to solve business or people problems: 

1) Systems give predictable results based on inputs

2) Everything is a system 

That day changed everything for me and my weight loss journey. If you make it til the end you’ll find out how… 😉

But what does this have to do with User Stories, Danni? 


If Scrum is essentially a set of principles and practices done in an organized way then Scrum by definition is a system. And since everything is a system then Scrum must have inputs, outputs and a predictable outcome. In other words, if the predicted outcome of sprint is an increment then requirements are the inputs. User stories are a popular way to express the requirements, features, functions, enhancements and fixes that development teams use to produce an increment of software. The quality and subsequent value of that software depends greatly on the quality of the requirements or user stories. Garbage in, garbage out.

Over the past 10+ years I’ve worked with several Agile development teams and what I’ve found is that the teams that are highly productive have a well put together product backlog that includes well written requirements. Yet in every single instance that I’ve been called on to serve a team that is consistently challenged to produce an increment sprint after sprint the same is not true.

Before moving forward let’s level set on what an increment is. The Scrum Guide defines and an increment as a body of work that can be inspected, delivers incurred value, is usable and meets a predetermined set of quality guidelines, standards or conventions. If the software produced by a Scrum team at the end of the sprint does not check ALL of those boxes it is not an increment. Though something may be produced it will ultimately not be an increment, the desired output of a sprint.

So what then makes a good user story or good requirement? Wow, you ask the best questions! 

Bad User Stories are Bad for Business.

In our Good, Hot and Ready User Story Workshop I go deep into the mechanics and benefits of good user stories as well as covering several other concepts that lead to what I call value driven development. Let’s compare and contrast the main characteristics of good and bad user stories as well as the far reaching effects of both. 

Bad user stories will have one or more of the following characteristics:

  • Unclear
  • Not ordered
  • Too broad/general
  • Dependent
  • Too much detail
  • Inflexible
  • Too large
  • Untestable
  • Over complicated
  • Not enough information
  • Too much information
  • Inaccurate
  • Missing value statement
  • Created in a bubble
  • Non existent

The effects are far reaching down to and including customer dissatisfaction even revenue loss. As a result, these types of inputs inevitably lead to but are not limited to:

  • Buggy/defective software
  • Rework
  • Undone work
  • Technical debt 
  • Waiting
  • Rarely/never used features
  • Extra processes
  • Conflict
  • Waste (time, money, effort)
  • Missed deadlines
  • Missed sprint goal
  • __(fill in the blank)___

All of the above outcomes/outputs are just bad for business. It’s as simple as that. The only recourse for these conditions is to bake quality in from the very beginning. Take reasonable measures to improve a Scrum team’s chances to produce a “done” increment consistently. Start with good requirements.

So what then makes a good user story or good requirement? Wow, you ask the best questions! 

What are Good User Stories Made Of?

User stories are a great method for expressing stakeholder requirements. And good ones are characterized by the following:

  • Well structured/simple format 
  • Relevant to the product
  • Ordered (business value, complexity, risk)
  • Tailored to specific user/user group
  • Clear
  • Concise
  • Compelling value statement
  • Tied to business objectives/goals
  • Easy to understand
  • Transparent/visible
  • Small enough to estimate
  • Flexible/open for discussion
  • Multiple contributors
  • Testable

When a team has well-structured user stories as inputs, it reduces misinterpretations, misunderstandings, and false starts, thereby enabling successful software development, planning and faster delivery of quality working software. Good user stories are relevant to the project and understandable.  Thereby, providing an additional layer of transparency that facilitates empiricism in Scrum.

Garbage In, Garbage Out.

All systems are designed to give predictable results. In Scrum that means consistently building increments. A valuable, usable, “done” body of work. If a Scrum team is not achieving that consistently over time no matter how big or small the increment is there is a breakdown in the system (roles, events, artifacts, values). In my experience, 90% of the time the reason for defects, missed requirements, late delivery, even conflicts “poor requirements” was cited. For that reason, the very first thing I say to an underperforming team is take me to your backlog as it gives me tons of insight on where the gaps really are. I cannot express enough how critical the implementation of good user stories is to delivering real value. It’s absurd to expect results that are better than the initial effort put in. 

You only get out what you put in. So best you figure out what “exactly” you’re putting in if you ever hope to change what you’re getting out. This goes for Scrum and any goal you’re trying to achieve. Speaking of goals, I focused primarily on what, when and how much I ate. Also, I cut my work outs down to less than half of what I was doing initially. Not only did I reach my fitness goal I also won $1,000 for the Most Dramatic Transformation that year!

Danielle Pollard

Danielle is a Senior Managing Advisor with Responsive Advisors. She specializes in agile team development and peak performance strategy.
Filed Under: ,
Tagged with: ,