Tell Me Why, not How

If you're familiar with the concept of User Stories then you've likely been exposed to the concept of a User Story "script". One of the most common scripts goes something like:

As a <who> I want <what> So that <why>

Looks simple enough, right? The problem is that most people who grew up in a non-Agile environment are not used to articulating the "why" in their requirements. They are used to capturing what it is that needs to built and how. Consequently, that's what usually end up making it into our stories, causing them to look like:

As a <who> I want <how> So that <what>

What's the difference? Let's look at an example.

Old Habits Die Hard

It's not uncommon to see a story that reads like, "As an administrator I want unique group IDs for tickets so that I can easily group tickets." On the surface it looks like a good user story. What's the "what"? The author would argue that it's "unique group IDs for tickets", but that's not the need. The need is to "easily group tickets". The author is trying to dictate how to meet that need in the user story. Those familiar with the INVEST model for user stories will recognize that this violates the "N" - Negotiable.

So we need to move the "what" into its place and establish a proper "why", which means we need to have a conversation. What valuable outcome is enabled by being able to group tickets together? Do you want static or dynamic grouping? Are the groups established by pre-established rules, or is the intent for users to group tickets however they like? Once we have our answers, we may end up with a better user story, something like, "As an administrator I want to easily group tickets so that I can sort and filter to easily find tickets of interest for a given task".

Why? Why?! WHY?!?

What have we gained by phrasing the story this way? A couple of things (at least). First, we have context for the story that will enable the team of professional problem-solvers to create the best solution for the problem within the bounds of the NFRs (Non-Functional Requirements) and FSRA (Future State Reference Architecture).

The second benefit is that we can better decompose the story. With the original wording, we would likely decompose the work into the layers of the system - creating a grouping cross-reference table structure first, then the business logic and virtual object code to associate tickets to groups, and finally the user interface layer for the administrator to actually use this functionality.

With the revised wording, we can leverage the advice from Agile Learning Labs at SmallerStories.com and split our story into smaller stories that are vertical slices through the entire system. This enables us to deliver value sooner and test our architecture as it's being built instead of all at the end.

Living in Reality

This is the most common anti-pattern that I've seen in the real world of user stories. What anti-patterns have you seen? What advice do you have for overcoming user story anti-patterns? Is this even really an anti-pattern?