Skip to content →

User Stories – a practice exercise

As I continue to build out my Business Analyst portfolio, I took a look at User Stories and Acceptance Criteria. Again, I used the hypothetical People Profile application and context to motivate my practice.

User Stories are chunks of desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes…Kent Beck first introduced the term as part of Extreme Programming to encourage a more informal and conversational style of requirements elicitation than long written specifications. – Martin Fowler

Initially, I thought I would also use this work as an opportunity to learn a new-to-me tool or two. To that end, I reviewed Cardboard, FeatureMap, and StoriesOnBoard; however, none seemed to have the tight structure for user stories and acceptance criteria that I had in mind. So, it was back to my tool of choice, Microsoft Excel.

I also thought the work might be a chance to try out Story (Journey) Mapping; however, I didn’t see the utility for the People Profile application where there isn’t a well-defined journey as in a customer journey through a sales funnel. For the People Profile, the user stories are more isolated and disconnected tasks without any inherent logical order.

With these decisions out of the way, it was time to craft the desired spreadsheet. For the user stories I used the well known “As a [persona], I need to [action], so that I [achieved benefit or value]” structure. For the acceptance criteria I used the Gherkin syntax: “Given [pre-condition(s)], When [action], Then [result]”.

In picking these formats, I acknowledge Alan Klement’s criticism of the user story format and his proposal for “job story” as a better alternative. The job story syntax is “When [situation], I want to [motivation] so I can [expected outcome]”. I largely agree with Alan’s critique; however, I thought it was still best to gain some practice with the more common user story and acceptance criteria format. To demonstrate that I am bilingual between these alternatives, perhaps I will circle-back and recast the spreadsheet as “job stories”.

Excel spreadsheet screenshot

Download spreadsheet

The spreadsheet is but an illustrative sample for my practice — it is far from comprehensive for the envisioned application. This incompleteness is especially true for the acceptance criteria where for many of the user stories I only provide a single acceptance criterion. In an actual deliverable, each user story would have roughly five or more criteria. Also, I was knowingly informal with the acceptance criteria and acknowledge that many are not yet rigorous enough for Cucumber test automation. Think of the acceptance scenarios as would be written in an initial user story creation workshop, before refinement with the development team and stakeholders.

Following from my recent work with personas, as I started the user story work, I thought I would be using “Robin” and “Pat” as named actors to make the user stories more relatable. However, as I got into the exercise, this didn’t sit well with me as it seemed to imply that only Robin or Pat would perform the particular user story. I still feel that the personas are powerful for creating empathy within the development team and for suggesting user stories by visualizing a day-in-the-life of the persona, but not so helpful within the user stories. In the end, I used ‘generic user’ almost exclusively for the actor in the user stories. This discovery is consistent with Alan Klement’s criticism.

Crafting the user stories did have the desired effect of surfacing features that I hadn’t yet thought of when working only with the database or personas. For example, before the user stories documentation, I hadn’t yet thought of the now obvious benefit of being able to include external people (non-employees) as connections for social network analysis.

I made a first pass at chunking out major development milestones into Epics, which might line-up with application releases to end-users.

In crafting the spreadsheet, I occasionally had some doubt regarding when to use a separate user story and when to just use multiple acceptance criteria for the difference between (for example) ‘add’ versus ‘edit’ versus ‘delete’ for a network connection. I’m interested to hear from others regarding how you navigate this granularity decision. Please leave a comment below.

Next up, I’m thinking I’ll take-up change management for the People Profile application — moving away for a bit from the technology components and addressing some straight-up business concerns. For now, I plan to skip creating the less common full-out use cases that I learned “back in the day” when I first was a Business Analyst.

For further reading:

Published in Business Analysis Portfolio

4 Comments

  1. Jennifer Jennifer

    I followed your link from a post on Facebook in Laura Brandenburg’s Bridging the Gap. This addition to your portfolio is amazing! I love the way you detailed your thought process as you moved from one idea/tool to another. I’ve also considered something like this so I can write up things I’ve done without having to link with an employer (and get in trouble). Excellent example 👌 Keep on doing this, if it makes you happy – I think it’s valuable.

    • Ray Ray

      Hi Jennifer, Thanks for the encouragement. It means a lot to me. Good luck with your own portfolio. I do think it is a great way to learn and also keep yourself maximally employable. Ray

  2. Ray Ray

    This Mastering Business Analysis podcast episode http://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/ recommends three approaches to documenting non-functional requirements:
    * As part of the Definition of Done. Use this approach “if a non-functional requirement is well understood, is of relatively low effort, and applies to most of your backlog items”
    * Acceptance Criteria. Use if this approach “If the requirement is fairly well understood and is low effort but it only applies to specific backlog items.”
    * A Backlog Item. Use this approach “for non-functional requirements that are a bit more complex”

  3. Ray Ray

    Deliver IT podcast episode 86: Other Story Types (17 April 2019) refers to the following resources for alternative user story formats:

    In As a, I want, So that Considered Harmful by Gojko Adzic and David Evans (2014) credits Chris Matts for pulling the “So that” to the front with “In order to” “As a” “I want” (or “we will”). The authors also propose adding “Whereas currently…” or “Instead of…” to user stories. Read more with 50 Quick Ideas to Improve Your User Stories by Gojko and David.

    Maarten Dalmijn in Unheralded Alternatives to User Stories (2018) describes five alternatives: Initiatives, Job Stories (as mentioned in my original post), Problem Stories, Improvement Stories, Feature-Driven Development features.

    Maarten describes Improvement Stories further in Improvement Stories: a simple alternative to User Stories where he writes “Improvement Stories are great for small improvements. You already have User Stories that explain the context really well. You just want to make some small improvements. The User Stories describe the problem you are solving for what user. You just want to make some small tweaks. So you just link the Improvement Stories to your existing User Stories. Now you and your team can easily access the context of the existing User Stories if necessary for deeper understanding…Improvement Stories have the following template: We have [current situation], we want to have [desired situation].”

    The Pragmatic Institute also proposes “problem stories” in the format of “[Persona] has [problem] with [frequency]”.

Leave a Reply

Your email address will not be published. Required fields are marked *