User Stories are Broken
There comes a time when something is so ubiquitous that is starts to lose it’s original purpose. This usually happens when a process or method reaches critical mass, is often ‘standardised’ and everyone you speak to utters something along the lines of “ah yeah, that…”.
Scrum is a perfect large scale example of this, but that’s a seriously big topic so I’m going to look at a smaller scale example of something often used as part of the Scrum development process.
User Stories.
I’m pretty confident that everyone reading this knows what user stories are, and it’ll boil down to the following
There are a number of different variations on this, but they pretty much cover the same thing just in different order or priority.
The Origin of User Stories
User Stories originated in Extreme Programming in 1998 though they rapidly evolved from their original description as being “like use cases” to what we see today.
In 2001, Ron Jeffries proposed the well-known Three C’s formula, i.e. Card, Conversation, Confirmation, to capture the components of a user story:[2]
A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction;
A Conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation;
The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally.
Quoted from Wikipedia — User story
They have been fully integrated as part of the agile development process by the Agile Alliance with the most recent recommended structure being the ‘given-then-when’ method of writing them.
The Problem With User Stories
User Stories, as first envisioned, are good ways to describe parts of the system which as a whole describe the product we’re trying to make. But they have issues that that make them unsuitable for a large number of software development projects.
User Stories and Iteration Length
In all cases, user stories are designed to be to be completed in a single iteration, so at the end of each iteration we have X number of user stories complete.
But user stories do not take into account the dependant nature of most creative endeavours. Take the following user story for example (which is a user story I remember having in more than a couple of infinite runners)
As a Player, I want to swipe the screen to move the character between lanes
From a discipline perspective, we have a number of dependancies here
- [Art] We may need to model the character
- [Art] We’ll need to animate the character moving between lanes
- [Code] We’ll need to move the character between lanes
- [Audio] Create the audio samples to move between lanes
A number of these can be done in parallel, as part of the iteration, but the amount of cumulative work is longer than the iteration length.
So we have a few options
- We could break the user story down so they fit the iteration length, but what kind of user story is this - As a <which user actually wants this?> I want the character to animate.
- We could simply create a laundry list of animations that need to be created and completed in isolation (which is what I often see) but what we have now is two distinct teams working for each other rather than with each other.
- We start working on the user story and accept that it’ll stretch over multiple iterations.
If this was rare it wouldn’t be so bad, we could cope with the odd problematic user story and continue working, but it’s not rare. This happens again and again and again.
User Stories and Integrations
People like to tweak things, and creative people like to change their minds. This is often a good thing and it’s that tweaking and iteration when a product is coming together that often takes it from a good product to an excellent one.
Lets take the previous user story which for the sake of example we’ll say was completed 3 iterations ago
As a Player, I want to swipe the screen to move the character between lanes
Since it was completed, we’ve implemented other character controls, animated the character in various poses and gone through a couple of rounds of play testing.
As a result, we have a few changes we want to make to this feature, which might take a couple of days or maybe a whole iteration.
How do we add this to our backlog?
- As another user story, for example “As a <again, who?> I want to tweak the swipe to change lane so that <what, it’s just ‘better’?>”? This is not a good user story, there is no explicit user who wants this and there’s not an explicit reason for adding it (other than it being ‘better’).
- As a general improvement (this is what you’d do if using Jira, for example) but now we have a combination of user stories and improvements in our backlog, both requiring different way of being designed, implemented and estimated.
- As a second list of requirements, usually along with bugs, but now we have multiple columns of work, both independent of each other!
Again, this is not a rare occurrence and before you know it your backlog is full of non-user story improvements of various scale or you have multiple work columns for different elements of work. Any project with a creative element, with user feedback and constant iteration (which we want from our agile projects) will have this throughout their development timeline.
User Stories and Scale
Big projects have a lot of user stories. Small projects with a lot of features have a lot of user stories.
Often you’ll have a lot of user stories.
We get around the first problem by using Epics, which will eventually be broken down to smaller user stories. We get around the second by, well, grouping them into epics.
But epics hide important detail, especially when it comes to estimations and preparations.
For example, this was a future epic in one previous project I worked on
Support local and online multiplayer
It’s certainly an epic, but it’s an epic which permeates almost every other user story in the product. You can’t support multiplayer (either local or online) without planning it into every aspect of the game before you start.
But that epic, since we don’t need to support it until later on in the development timeline, is hidden all the way down the product backlog.
So, as projects scale, the atomic nature of user stories starts to be lost and user focused features start to become dependent to each other but the act of describing and focusing on user stories means these relationships become lost and significantly more rework is needed as we continue with development.
User Stories and Hidden Technology Dependencies
Let’s take another example from a Twitter like service
As a user, I want to be able to post a message
If this is an early story we’re implementing, the amount of hidden work required in this is immense. If it’s later in the development timeline, it might be relatively easy.
User Stories are designed to be atomic, which is simply impossible for a project of any reasonable scale, and as a result the amount of hidden work in a single user story can be significantly higher than anyone anticipated.
So we have two options when dealing with this
- We can technically prioritise user stories and estimate them based on their hidden technical detail. This requires the backlog be prioritised by technical need rather than impact, and will artificially inflate the earlier user stories as we include the ‘hidden’ work involved in this feature
- Start to use ‘developer stories’ which are nothing if not controversial. We still need to technically prioritise the combined stories and it does mean that user stories won’t be inflated, but the second we introduce non-users to our user stories we lose the primary reason we’re using them in the first place!
Everyone Knows User Stories
Finally, user stories have reached the point where everyone knows, and confidently knows, exactly what they are, how they’re used and how they should be implemented.
As a result you’ll see backlogs full of ‘as a’ stories, with nothing more than the ‘as a’ and a ‘I want’ because that’s what user stories are, and that’s how they are used.
Request more information, and you’ll be told “We’ve created the user stories, now go and implement them!” [actual quote!].
While obviously this is not a problem with the User Story concept in-of itself, there comes a point of mis-judged universal adoption that it’s often quicker to rebuild the goal posts rather than trying to re-frame them.
User Stories Were Great, Once
User Stories were a great concept when they were first introduced and defined within Extreme Programming. As they were adopted by the agile community they still made sense, but as they evolved and adapted they started to lose their way, becoming more of a stock planning tool rather than one that simplifies and opens up the work that we need to do.
There have been some very good attempts to work around some of the issues with User Stories, the most successful has to be User Story Mapping. I would highly recommend you use if you’re focusing on a User Story style development process.
