Our recent release is still ringing in our ears – and I must say it still seems like a good ‘un. Everything went smoothly, before, during and after. We’ve had a load of positive feedback, and seen a record low number of bugs and complaints. All in all, well done us.
Now that’s out of the way, we’re trying again with Story Points. To do this, we need to have a good idea of what a Story is, and why we should use it for planning and estimating future work. Here, I ramble on in an attempt to make sense of the concept, with the help of spreadsheets and Battlestar Galactica.
What is a User Story?
A Story describes an enhancement in functionality, from the perspective of the user.
So is a Story like a functional specification? Not quite. We’ve built up our own way of writing specifications over the past few years. A spec should be concise; it should describe a problem, and outline a solution; it should be clear and descriptive, as well as being a living document.
A Story sounds like it should be too vague to be of use, but I think the opposite should be true.
It should start from the perspective of the user. Fill in the blanks:
- – “As a user, I want to … so that I can …”
This keeps us focused on tasks that actually add value – if we can’t finish the question, we shouldn’t be doing the work.
A Story might describe a tool, perhaps, or a one-trick dialog. Let’s take an example:
- – “As a user, I want to change the colour of numbers in my spreadsheet, so I can visually identify important columns and totals”.
This sentence doesn’t say anything about the implementation. Should we have a dialog? Toolbar? Brain-computer bluetooth interface, as seen in the Dr Who episode Bad Wolf? These are important design decisions, and should be considered and written down:
- – There will be an item in the Tools menu, labelled “Change Colour of Selected Numbers”
- – This will bring up a dialog which looks like this:
… and so on. Here we define behaviour at a carefully defined level. Not too much detail, but enough to convey the spirit in which the story is written.
Epics and Themes
Stories should be small, and so multiple, independent Stories come together to make an Epic. There’s no reason to assume an Epic should be completed in a single sprint. For example, we might want to consider the Implement Llama Font Story to be part of the Look Pretty Epic, which reads;
- – “As a user, I wish to manipulate the look of the numbers in my spreadsheet in order to clearly convey statistical anomalies to third parties.”
And similarly, multiple Epics come together to make an overriding Theme:
- – “As a user, I wish to visualise my data in innovative ways in order to clearly and effectively convince prosecutors of my innocence for the fraud of which I have been convicted.”
This hierarchy keeps our mind on the ball. If a decision needs to be made, and it’s not clear from the Story’s description what we should do, we can consider the dilemma in terms of the Epic framework, or even the overriding Theme, all of which are descriptions of how we can help the end user – the customer.
The terminology is a powerful metaphor; one with legs, I think. Let’s consider a Story, Theme and Epic from a rather different source:
- Story: Starbuck shoots down a Cylon Raider, salvages its systems, and flies it back to Galactica.
- Epic: The Battlestar Galactica protects a civilian fleet from multiple Cylon attacks.
- Theme: Stranded humans seek Earth.
How does the Story impact upon the Theme? Well, it’s not clear at first; but it certainly advances the Epic, and when considering the details it becomes clear – without the Raider, Starbuck could never have retrieved the Arrow of Apollo. Obvious.
In the same way, changing the colour of a few numbers can never clear an accused spreadsheet-fiddler of fraud, but together with a whole bunch of other stories, it gets us in the right direction.
All Is Not Lost
We can implement a last-minute approach to mapping out Stories; it’s clear that Number Colour is more important than Llama Font, so the details of that story can wait for a week or two, Similarly, we decide the most important Epic, and fully define the most important Stories within it.
And here is the fundamental difference between Lost, and the far superior Battlestar Galactica remake – BSG was an Agile development, whilst Lost was not.
On the face of it, the production of both had Agile features. They both engaged in last-minute script writing, responded quickly to user feedback, and each episode provided more value (entertainment) to the customer in an incremental way.
But while Lost (arguably) had an overriding Theme or two, it lacked anything at the Epic level. The producers have recently (finally) agreed they were making up the Stories as they went along. Black smoke? Yeah, cool! Magic numbers? Great idea. But this is the televisual equivalent of developers adding the features they want to write. Add sound effects when your spreadsheet updates? Great, but where’s the value to the customer?
If we can get a grip on why we’re writing user stories, we can keep in our mind what we need to implement; when we need to do it; and how everything we do is advancing the user’s experience of our software.
And, just maybe, defend humanity from Cylon raiders, while we’re at it. (Next time: How Agile methodologies can help a Cylon Centurion buy a pint of milk from the corner shop.)