The Anatomy of the User Story Pt. 1

Photo credit: Michael Podger, unsplash

Ever seen a spider with 7 legs? How about 3? Probably not, but I would bet you’ve seen a user story with less than these 8 key components scurrying its’ way through your iteration.

In this article and it’s successor I’ll present my take on the anatomy of a user story and the unique value of each of these key element as well as a few critical takeaways and tips for each section.

In many agile work spaces you see whiteboards and walls filled with sticky notes. Those sticky notes are later inputted into an online tool like CA Agile Central (formerly Rally), Trello, or Pivotal Tracker. That’s the humble beginning of the User Story. An index card, sticky-note, jotted idea on a napkin, written from a user’s perspective which starts a conversation with business, engineering, quality assurance, and other key stakeholders.

The user story consists of the Big 3: Who, What, and Why.

As a <User>

I want <Functionality>

So that <Value to my experience>

In most cases Product Managers and Owners sometimes fudge the “As a <User>” and “So that” statements. I’ve even seen stories without a “So that.” NO! These are key parts of the picture.

“So that…” statements are the bread and butter of the story for your business stakeholders. Why would C-Suite Charles care that you’re spending $5,000 to allow your Agent facing CRM systems to utilize County FIPS codes vs. utilizing Street Addresses and Zips to verify insurance availability? He cares because using the FIPS will result in 42% less agent sales errors, and the back end can more quickly retrieve the accurate and truncated list of available health plans, reducing clicks and call time by ~4% and even up to 12% during peak season with new reps on the floor. Your “So that” statement conveys the value of the work.

When you see, “As a nurse…” what comes to mind? Busy, wearing scrubs, managing multiple case files, and starts and stop work in progress as she moves from patient to patient. No time to fetch data and needs tried and true systems. That understanding helps you vet user story value at basic levels.

Pro Product Management (PM) Tip: Use defined personas. I helped a not-for-profit once define their key personas; the couple was called Chuck and Sally we fleshed these personas out and empathy mapped their key needs/wants. During brain storming sessions later I would ask, “Would that be helpful to Sally?” “Is that what Chuck would want to experience?” Using personas gives you a person as a user and not just “As a user…” for your user stories.

“So that…” statements are the bread and butter of the story for your business stakeholders.

Acceptance Criteria

Acceptance Criteria (AC) are explicit statements of functionality and sometimes non-functionality which when met allow a predefined requirement to be satisfied. The Acceptance Criteria will expound upon the “I want <Functionality>” statement of the user story.

This differs from the team’s Definition of Done — a group of tasks the team agrees to complete for each item of work within an iteration.

Here are 5 key considerations to excel your Acceptance Criteria:

  1. Consider Less is More: Your story has 7 AC and all but 1 pass. The entire story fails and the work is held up In-Progress or Rejected. Reduce the Acceptance Criteria of each story. I once worked with the guys at Pivotal Labs on a very high pressure/high profile product launch. Their processes make them rock stars. One of the coolest things about working with them was how they approached refinement/planning and story writing. If a story had more than 1–2 Acceptance Criteria it needed to be split.
  2. Consider Pass/Fail: Nothing will upset your QA team faster than vague AC which cannot be tested. Your AC is the definition of success or failure for the story.
  3. Consider Present/Past Tense: “The system shall display 12” vs. “12 is displayed” if it shall then it can happen at any time. If I need to see “12” in order to accept the story, then I need to blatantly express my needs. Shall is not a blatant expression.
  4. Consider Gherkin: Given, When, Then, And, But laid out in sequential steps of the user’s experience.
  5. Consider UI/UX: If your AC is user facing, you need to consider UX/UI. Do we apply the style-sheet? Does this statement need to stand out? Does the time stamp return in a format the user finds easy to read? Take time to flesh out the intended design of your requirements. It’s a worthwhile effort and will reduce re-work.

Pro PM Tip: If AC are based off conjectures because you’re working on a Greenfield project, then make the story a discovery SPIKE, with an AC of working prototypes, to firm up AC within a follow-up story. SPIKEs are much better solutions than changing the AC mid-sprint due to discoveries. No one wants to play a game with a moving goal. No changing AC mid-sprint.

This is one of my favorites! I’m a “Somewhat Technical” Product Manager. I learn something new every day and I always value my team’s insights and inputs when refining a story. A Dev Consideration is anything of note that an engineer would need to be mindful of when working the user story. During Refinement Sessions everyone is in the room and the creative juices are flowing. A great idea is provided, but within the work week that fix will be forgotten. Dev Considerations act as reminders to help engineers who pick up stories remember why it was sized a certain way or points them in the right direction technically.

I recall a very demanding product launch. Think of the most aggressive timelines and morphing requirements you could. Mighty Morphing Requirements! Our teams failed stories which met the previously outlined requirements, remember what I said earlier about no one liking moving goals.

At the time I was Product Management Consultant, coming alongside the business and being a liaison with the engineering staff and helping to manage the requirement execution as well as help with Agile methodology adoption. To help the business stakeholders recall what acceptance criteria the stories were written to, we began notating the original requirements as they were delivered to us and prior to pulling the story into the iteration flow we would verify that no changes were being made to the requirements and the acceptance criteria. This type of rigor was necessary in order to help the engineering teams focus and keep the business churn external from the teams.

Pro PM Tip: Referencing a changing document defeats the purpose of traceability. Take screenshots or save copies to your tracking system. This exercise isolates potential false fails created by Mighty Morphin’ Requirements.

No one wants to play a game with a moving goal. No changing AC mid-sprint.


Wire-frames, prototypes, and mock-ups: go ahead and attach them to your story. They help in ways you can’t believe. When managing the creation of a set of mobile apps, we had all types of media flying around the organization. Protect the engineers from this noise and only put in the collateral you want in the app in the story. Nail down image dimensions and ensure the graphics teams have those dimensions and file types in mind when creating collateral.

Pro PM Tip: Supporting rotation capabilities are a choice, not a mandate from Heaven. If you find that you’re working with content-heavy or informational apps then rotation capabilities may not be the best thing for your app. Does your user really want to move her phone every which way to engage the content?

Understanding user stories is fundamental to moving any product forward. Thanks for reading about these 4 components of a User Story and in the next article we’ll examine the other 4 legs of the User Story Spider. Let me know what your Pro Product Manager Tips? Feel free to review more articles over at my blog.

Product Guy, Dad, Husband…I write things