As an MSM Software Solved developer/blog writer, I was keen to write a piece about User Stories so others can see why they might work for them.
What are User Stories?
User Stories are a short description of a new feature or piece of functionality, from the perspective of a user or role in the system. They also describe what the user intends to gain from this particular new piece of functionality. I mean, if you can’t think of the benefit of this, what are you wasting your time on it for?
They often follow the form;
As a <user>, I would like to be able to <awesome new feature> so that I can <huge reward goes here>
- Criteria 1
- Criteria 2
- Criteria 3
The user describes a particular role in the system and not necessarily one particular person. So for example, “as an existing user of the site..” or “as a newly registered user..” etc. The feature is fairly self-explanatory. What does that user want to achieve? “.. I would like to be able to sort the list of available sandwiches by user rating..” or “I would like to be able to reset my password..”. To finish, and arguably the most important bit. The reward or benefit that would be achieved if said awesome new feature was implemented “..so that I can find the best sandwich”.
The benefits of User Stories
I’ll be perfectly honest. I feel quite daft reading these things out loud – but that’s ok. It’s ok because not only do they help everyone keep focussed on discussing the problem at hand, but they’re actually very beneficial in keeping the technical bods focussed on solving the problem the customer really wants solving and not other problems that may or may not exist. It’s very easy as a technical person to get bogged down in the technicalities and implementation of a specific solution and maybe lose sight of the actual problem everyone wants solving in the first place. There’s nothing more frustrating than hearing people discuss databases, APIs and other technicalities before they’ve clearly defined the problem. With User Stories, customers can clearly see in plain English what functionality they stand to gain. Developers can stay focussed on delivering a solution that gives the customer exactly what they want. Testers can be confident their tests cover everything that’s expected of this great new feature.
The simple act of completing a User Story may even spur discussion on the actual usefulness of the functionality in the first place. Is this actually much benefit to anyone? They may prompt discussion on even more useful features or heaven-forbid, poke holes in a somewhat inefficient bit of existing business process.
How to write User Stories
User Stories are almost always written on postcard-sized paper cards; cards small enough that they physically can’t be filled with reams and reams of information. If the story cannot be described in the confines of such a card, that’s a good indication the story is too complex and needs to be split down further into smaller stories. These behemoths are often called ‘epics’ – large pieces of functionality that if discussed in one sitting would not only cause everyone in the discussion to lose the will to live, but more importantly, the developer to be overwhelmed and begin to cry. No one wants this.
After the initial story summary is penned, everyone in the discussion must decide the detail, or the criteria of the story. What constitutes as ‘done’ here?
Going back to some of the earlier examples (don’t write blogs when you’re hungry).
As a sandwich buyer, I would like to be able to filter the available sandwiches by ingredients, so I can easily find the perfect sandwich for me.
- Users can filter by Bread Type, brown or white
- User can filter by Vegetarian
- Users can filter by Does Not Contains Gherkin
- Users can filter by Star Rating, 3+, 5 only
- Users can clear all filters
- Filters persist between browser sessions
If they’re done, then we’re done, right?
Criteria will be added, amended and scrubbed out at will until everyone’s happy. Pencils and rubbers are a wise choice here, but coloured pens get my vote. Sprinkle glitter on them if you like.
So to recap;
- Everyone stays focussed on the problem at hand
- Techy discussion takes a back-seat
- Functionality is described in plain English
- The benefit (or potentially lack of) to the end user is clearly laid out
- Work is split into manageable chunks
- Everyone knows when a piece of functionality is done
And the best bit? Everyone gets to play Planning Poker!
https://www.mountaingoatsoftware.com/agile/planning-poker
