Cookie Cutter User Stories

It might be a good idea to hunker down and grab yourself a coffee, soda, snack bag, or even a cookie before you dive in to this article; it’s a chunky one on the subject of user stories.

While the “keep it simple stupid” has some relevance, user stories are not simple to write, if they were, a lot more people would be much better at it. As Agile Transformation Lead at AgileNX, I’ve written thousands of user stories – and one thing is certain – there is no cookie cutter way to writing good ones. Why? Because every user story has a different story to tell!

One of the biggest issues is fully understanding the “as a <role>, I want a <widget> so I can <goal>” format. The first element I’m going to explore is the “Who” as in <role> or persona. Many agilists and product owners invest a lot of time in defining personas – a profile about a fictional character along with a fictional biography. Let’s look at an example persona and then I’ll explain why I’m not a fan of them:

Amanda is a 35-year-old mother of two, she has an Arts degree and works as a industrial designer. She loves the outdoors but hates shopping. Her dream is to write a book and she often contributes to design related blogs as a step toward fulfilling her dream.

While this conjures up some warm and fuzzy empathy about “Amanda”, from a user story perspective, the bulk of Amanda’s persona is just noise. Let’s say you’re developing a niche software product for industrial designers, one that Amanda might use, it’s likely that you’re developing a feature to facilitate or improve a workflow need, one that’s applicable to many industrial designers. Knowing Amanda is female, 35, has two kids, and likes hiking has little relevance. The end user could also be John the industrial designer. He’s a 26-year-old bachelor who likes heavy metal concerts and motorcycles. Are his needs any different? While a user story has to communicate the who the what and the why, using “As Amanda…”, or “As John…” is a bit pointless, the only common thing between them is they are industrial designers. For me, simply stating “As an Industrial Designer” has enough information to understand the context of the challenge to be solved. I’m sure many of you will disagree, and that’s OK. Much has been written on the subject of personas, both for, and against them.

The next element to explore is the “I want a <widget>”. Here’s where things can really go off the rails with solutioning: “I want a dropdown menu”, “I want a help pop-up”, “I want a data table”, etc. (The exception to this when writing “integration stories”, but that’s a topic for a future article). So, the question is, how does one express the “what” without getting into the weeds of a solution? The answer is abstraction, and here’s where user story writing gets hard. Articulating what is needed is a combination of understanding the context of what the user is attempting to achieve and then expressing that interaction. I often use the phrase “a UI element” or “a UI tool” which are abstract enough but doesn’t imply specific solutions. It’s important to be thinking about acceptance criteria at the time of writing the user story as it’s these that will solidify what the solution must accomplish.

The final element – and the most important – is the “Why”. Sadly, this is the most overlooked and poorly expressed component of the user story statement. I’ve even seen cases where it is omitted completely. Clearly expressing “why” a user wants to do something plays a critical role during backlog prioritization as well as through development and acceptance. This is where the true user value is, and therefore needs the most focus. To that end, I abandoned the “as a <role>, I want a <widget> so I can <goal>” format in favor of “In order to <goal>, as a <role>, I want a <widget>. The reason for this is the value is the first thing that is stated, so it can’t be left off. It also forces the writer to really empathize on the why. Using our Industrial designer friends Amanda and John, here are a couple of examples:

In order to quickly draw new curved lines, or adjust existing curves, as an industrial designer, I want a single UI tool that does both

In order to observe line color or fill color opacity adjustments in real time, as an industrial designer, I want a UI control to be available when an item is selected

In order to move several objects at once, as an industrial designer, I want to select multiple items quickly

Thanks for reading the article

AgileNX is the Agile Transformation Group of Syrinx Consulting.

For more information on AgileNX, call Matt Berg at 781.487.7800, ext 15.