A User Story is not a unit of work

Image from Wikipedia

I first learned about “User Stories” when in my company, we started to use Extreme Programming. I didn’t give them much thought, they were just a fancy way of describint a feature for a system. The strict format of a User Story forces you to include relevant aspects. “As a carpenter, I want to drive in nails” is a user story that leads to the production or purchase of a hammer. A user story does not come alone: once you have a hammer, you’ll write “as a carpenter, I want to pull out nails”. As a carpenter, I want to conveniently carry my two tools. This works well. The carpenter gets a small toolbox, when their number of tools grows, they get a bigger toolbox, and a still bigger one. For a carpenter, a user story is synonymous to a “feature”, or a tool. For the toolmaker, the user story is a unit of work.

Now let’s see what a User Story is for a software developer. When making a web site or an app for a retail company, the first User Story would be “as a customer, I want to browse product images”. The software developer adds descriptions to the images, because that seems only logical. The second user story is “As a customer, I want to keep products in a virtual shopping cart”. The developer makes a new screen or web page, for the shopping basket. The third User Story, “as a customer, I want to drag product images into my shopping basket”, requires an overhaul of the features that have been built so far. The more features are added, the more restructuring is required for that what alread has been built. In the end, the developer has spent twice the amount of time they would have spent had they first designed the web site or app as a whole. In the latter case, they would have built the site or app as a whole, in a logical order of components, rather than in a random order defined by the priorities that a product owner sets for the user stories.

As a third example, let’s look at a house. You hire an architect and a builder, and you start with your first User Story: “as the home owner, I want to watch TV in the evening”. The archtect designs a living room, the builder builds it, you buy a TV and your first User Story is done. The second user story “I want to store a ton of stuff in the attic” tells the builder to put an attic on top of your living room. It is later removed and put on top of the bedrooms on the second floor. Windows are put in at the end, and for the staircase, walls and floors have to been broken out.

It is obvious that you cannot build a house with user stories. You build a house by hiring an architect who designs the whole house, then you hand the design to a builder who builds it in an order that is most efficient and effective for them. In the end, al User Stories have been realized, just not one by one but rather in a way that in the end, they are suddenly there.

I have learned to see a User Story not as a unit of work, not even as a feature. I rather compare User Stories to Personae. The book “The inmates are running the asylum” gives a nice introduction to Personae. A Persona is a typical user of your system or product. When I worked in a project to create an app for the Albert Heyn supermarkets, we had 12 personae. Each of them had a detailed description, a profile, a name, even a photo. When a new feature was created, we’d say “what does this mean for Emma” or “how would this work out for Robert?”. This helped the team to focus on the needs and requirements of the customers. When we were creating a visual dashboard for the carts in the Symbolica dark ride at Efteling, I kept imagining personae. The carts could seat six people, I thought of grandpa and the kids in the front, grandma and the parents in the back. The kids focusing on the touch screens, grandpa trying to help them, grandma admiring the scenery, parents getting a quick nap because they are tired. Or six teens, moving about, trying to hack the screens, leaning out of the carts. Imagining an actual group of people in a cart helped us create the right features and make the ride enjoyable for a wide range of visitors.

A friend, who is an architect, explained to me how he designs a house, collecting User Stories from the future inhabitants. Depending on who sleeps on which side of the bed, he would plan light switches and land line connections. He would ask the future owners about hobbies, about guests, pets, everything, so he could plan the restrooms, guestrooms and hobby spaces accordingly. Based on the User Stories, he’d plan the master bedroom to have mornin sun or evening sun. The future inhabitants of the house are his personae, the User Stories connect the personae to actual features of the house. After everything has been designed, the work is done by the builder, who’s units of work are “build the basement”, “build all walls”, “put in all windows” etc. There is no direct relationship between personae and user stories on the one hand and actual work on the other.

I propose the same should be true for information systems. When you build a web site, or an app, or any system, you first collect your personae. You name them Emma, Robert, Abigail and Achmed. You give them a face, you give them a job, hobbies, pets, dogs, everything. Then you imagine what your personae will do with your system. You talk to future customers or users about what they need from your system. You write them dowen, like “Emma wants a financial overview of last months sales every month”. “Achmed needs a bill of materials a day before he starts building the product”. “Norma wants coffee twelve times a day”. Then you don’t start by buying Norma a coffee machine. Rather, you lay out an architecture of your system that fits in your current IT landscape. You design the interfaces with existing systems. You test mock GUIs. You start programming. And at every stage in the project, you keep asking yourself “what will Jonna think of this” or “how will Fatima like this?”. Also, at every stage, you keep track of how you are matching the collection of user stories you have collected. When a programmer starts building feature X, you ask “which user stories are about X?”. If there’s no user story X, then there is no feature X. You’re done when all user stories are marked “covered” and all personae have an 80% happiness score.

Software engineer, AI engineer, entrepreneur, writer

Software engineer, AI engineer, entrepreneur, writer