The user story is one of the most fundamental bedrocks of agile processes. It is the unit that we divide the requirements into. It is the minimal unit of value. It is the unit that we work on at a time. It is the unit of deployment and it is the unit of measuring progress. And now, it seems that the time has come to retire the user story.
The user story as a unit of deployment and progress
The user story used to be the minimal unit of deployment and progress. If you don’t deploy the whole user story then you count zero against your progress. In Scrum, this would mean you get no velocity for a half complete story. However, the new revolution in deployment, DevOps and Lean Startups is changing all that.
The latest advances in continuous deployment have meant that it is now very possible to deploy half complete features. What is the use of that you ask. Well take a look at this scenario
Consider a user story that requires some database migrations. Lets say we want to migrate data from an old column to a new column. In the old days we would implement the story, along with some database migrations and at the end of the Sprint we would deploy the story and migrate the database simultaneously.
In today’s world of continuous deployment, that happens very differently:
- First a database migration is created to create the new column. Checkin, test and deploy
- Write code so that all writes on the old column also write to the new column. Checkin, test and deploy. At this point the new column starts getting filled for some users.
- Write a database migration to migrate all the existing data in the old column to the new column. Checkin, test and deploy. At this point, the data in the old column and new columns are in sync.
- Wait a few days to verify that everything is working so far.
- Write code to start reading data from the new column instead of the old column. Checkin, test and deploy
- Write code to stop writing to the old column. Checkin, test and deploy
- Wait a few days to verify that everything is working so far.
- Write a database migration to drop the old column from the database. Checkin, test and deploy.
As you can see, we do many many deployments into production long before the story is complete. There are pieces where we wait to verify that everything is going okay so far before continuing. This is just one use case. There is the use of “feature flags” to deploy incomplete user stories into production, where some incomplete stories are deployed and then hidden from users. There is the use of “special access” where priviledged users can use the story, but not the general public. Some teams use “gradual rollout” where a feature is slowly rolled out to users over a few weeks.
The “user story” is only complete when the last of these steps is over. But progress happens at each of these steps. In other words, we can no longer say that the user story is the minimally deployable piece of functionality, nor can we say that it is the minimal measure of progress.
The user story as a unit of requirement and value
Agile processes are based on the user story as the fundamental unit of requirement. Different processes call them different things – Scrum calls them Product Backlog Item for example – but the concept remains the same. You divide up the overall requirements into these small user stories, and that enables you to independently implement stories and build up the product incrementally. And that has worked wonderfully – until now.
When user stories first came upon the scene, they were pretty large pieces of functionality that took a couple of weeks to implement. Over time user stories have become smaller and smaller. A user story today is about a couple of days to implement. The upside of that is that you can split stories really small and deploy small increments of software. The downside is user stories have become divorced from customer value. Look at the following example:
Lets say that we want to implement GMail’s priority inbox. This piece of functionality has three stories (assume)
- Allow the user to turn the feature on/off in the settings
- Implement the algorithm to sort emails into priority buckets
- Allow the user to adjust the algorithm by manually overriding the categorisation of the algorithm
Now, suppose we implement and deploy the first user story alone… how much customer value have we delivered? None! Because what is the value of adjusting the settings when there is no algorithm implemented? And if we implement and deploy the second story alone? No value still! In fact it could be negative value! Because you’ve implemented this algorithm and some users don’t want it, and they are fiercely complaining that there is no way to turn it off – this is a potential PR disaster on your hands.The bottom line is that no customer value is delivered unless all three stories are implemented and deployed.
Welcome to the MMF
The replacement for the user story is the MMF – minimally marketable feature. The MMF is a bigger component of requirement compared to the user story. It recognises that a single story by itself may not have customer value, and often you need a group of user stories to deliver value. The MMF is this group of stories. It is minimal meaning that it is not possible to remove a story and still deliver value. It is a marketable feature, which means that it has to be big enough to deliver value. Being minimal and being marketable are two opposite constraints. The equilibrium point is the MMF. Sometimes the MMF is just a single story. At other times it could be a collection of stories.
The second thing to consider is the move away from “user”. The user story was conceived as a way to focus on end user benefits, and that is good. The problem is that is focused only on end user benefits. This led to some extremely contrived mechanics when you wanted to do things that didn’t impact the end user.
For example, a refactoring could not be a user story because it had no end user benefits. Instead the recommendation was to combine it with another user story that required the refactoring. This is extremely contrived, touching your nose around your head because the “rules” of agile said so. What if we needed to migrate architecture? Should we wait till tiny a user story came along and then estimate 3 months to implement this user story because we need 2 months and 29 days migrating architecture? It makes no sense. And people ran around this limitation by creatively writing user stories like “As a developer I want to refactor so that the code is easier to maintain”, and then claimed themselves as a user of the application.
In the MMF world, an MMF is any piece of work that has value to someone. So if we need to implement an analytics system for a web app, then we can create MMFs out of it, because it has value to us, even if it has absolutely no end user benefit. Similarly, an architectural migrating is valuable to us, even though it has no end user benefit – just make it a separate MMF and track it the same way.
The user story in today’s world
With the MMF taking on the duties of “minimal” and “value”, the user story is now just a plain old work item (POWI?). Its the minimal piece of functionality that can be deployed – whether you deploy complete user stories or you deploy stories in pieces. Each time you deploy some functionality then thats a user story. Of course the term user story doesn’t really fit this, so I just prefer to call it a work item. Progress is made when each of these work items goes into production. Value is delivered when all the work items under an MMF are complete.
RIP user story – you were fabulous when you were around, but its now time to move on.