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
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”.
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
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:
- Story Mapping Slides, by Jeff Patton
- What Is Customer Journey Mapping and How to Start?, by Paul Boag
- A Beginner’s Guide To User Journey Mapping, by Nick Babich
- User Stories, by Agile Alliance
- User Stories Are Better than PRDs, by Teresa Torres
- Gherkin for Business Analysts, by Ryan Thomas Hewitt
- Writing User Stories with Gherkin, by Nic Werner
- The “Right Way” to Write a User Story, by Cash LeBrun
- Writing Effective Use Cases, by Alistair Cockburn. Also,
Alistair’sextensive online resources related to usecases, including relationship to user stories.