“As $role I want $desire so that $benefit”

I’m growing to love the idea of user stories. A simple short sentence or two capturing someone’s need, providing context to indicate their motivation, and usually specifying little in the way of implementation details.

Put aside any “Agile-with-a-big-A, Methodology-with-a-big-M” notions or definitions, and just go with the concept.

Implementing things according to user stories gives you:

• An idea about who you’re doing the work for; who will benefit
• A notion of what that person is ultimately trying to achieve, because the XY problem is real
• Freedom to solve that problem in whatever way seems best

I keep likening them to Java Interfaces, or type signatures. From an external perspective, you’re often uninterested in the implementation, you just care if the user story is satisfied.

For example: as a conference attendee, I want a hard copy of the schedule I can use for quick easy reference. It doesn’t matter much to me if there’s a nice glossy program with speaker bios and talk abstracts, or someone’s just printed a copy of the schedule on the website and handed it to me when I show up. I just don’t want to have to pull my phone out and load the website to work out what room I wanted to be in next.

There’s a lot of value in collections of such user stories. To go back to the “hard copy of the schedule” example, I reckon most people would agree it’s a good idea. However, I’ve been to multiple conferences that haven’t done this, and I suspect the biggest reason was that the idea simply hadn’t occurred to anyone.

The UK’s GDS Service Design Manual has a brilliant set of user stories for web operations, with the following intro:

This document outlines the typical scope of infrastructure and web operations (sometimes erroneously referred to as hosting) work on a large service redesign project.

The sample list of user stories provided is not intended to be a complete list of all areas of interest nor are you likely to need to do all of this for every service. The idea is for this list to be a good starting place from where to you can write additional stories, delete ones you do not require and split stories into smaller ones.

Planning things is hard. Estimating things is hard. It’s easy to overlook things.

A curated list of user stories, like the GDS one above, is an excellent resource. I’m on the PyCon UK committee for 2016. To that end, I’m putting together a list of user stories that I’d like to see a conference implement. Got ideas of your own? Please add them in the comments!