User Stories

Writing Good User Stories (Hint: It’s Not About Writing)

My first experience with Agile occurred due to my quest to write better User Stories.  As a new software development manager, I realized that the team’s biggest problem was estimating.  I found the book Agile Estimating and Planning and it changed everything.  It set us down the path of creating User Stories instead of using the CRD (Customer Requirements Document) that we had previously been using.



Over the next decade, I focused on writing good User Stories.  I became an expert on INVEST, using it to determine if a User Story was well written.



One of the most critical aspects of a User Story is it’s role as a place holder for a conversation.  As a reminder, a User Story is made up of a Card, Conversation, and Confirmation.

User Stories 1

Somewhere along the way, teams have forgotten about the Conversation.  Teams almost exclusively focus on the mechanics of User Stories.  Why?  I’m not sure.  Maybe it’s because the mechanics are what everyone is worried about.  Mechanics are concrete and familiar.  They are closer to the old way of doing things.

The risk when focusing on only mechanics is that your User Story becomes a contract.  You are leaving Customer Collaboration over Contract Negotiation from the Agile Manifesto in the dust.

I hear teams say things like, “The Product Owner isn’t writing well defined User Stories so we can’t start“,  or “We have a hard time completely defining and documenting our User Stories in the Sprint Planning session“.  My response to these statements is: “You aren’t supposed to”.

While watching some YouTube videos on Story Mapping, I stumbled across an interview with Jeff Patton.  Here, he gives a brief history of how User Stories started:


Watching this reminded me of what User Stories are supposed to be, not what they’ve become: contracts.  It’s easy to ignore the Negotiable part of INVEST.

Here is how to write good user stories:

  1. Focus on the value to the customer: why they want to perform some task, not just what they need to do.
  2. Don’t strive to define every possible scenario in a User Story in the planning session.  If you do this, you are eliminating conversation that needs to be occurring for the rest of the iteration.
  3. Don’t assign the responsibility of writing User Stories to one person.  Writing User Stories is a collaborative effort.  It’s best to include the whole team.
  4. Don’t be a slave to a User Story format, i.e. “As a …. I want … so that“.  It’s a great place to start, but if there is a way that works better for you, go for it.  A User Story is just a placeholder for a conversation.
  5. Do not treat a User Story as a contract.  It will change throughout the iteration as the team gets feedback from the Product Owner, SMEs, Stakeholders, etc.  This is Agile.
  6. Run every User Story through the INVEST litmus test.  It works.  It may be hard at first, but it gets easier over time.

There are a lot of articles out there about writing better User Stories with great information about mechanics.  However, many imply that the only conversation required occurs during the iteration planning session.

Let’s set this straight:  The conversation is over when the User Story is done.

If your team could use help writing User Stories, contact One80 Services.  Our existing course, Agile Requirements & User Stories might be something you find helpful.  We’re also available for customized training and coaching – just drop us a line.

Talk to Us Today
post =