Hi I’m Mark. I help organizations write software more efficiently. A big part of this is helping teams find ways to organize their work in a way that follows Agile values and principles. In this video we are going to talk about creating user stories. User stories aren’t Agile in and of themselves, but they can be used to help us follow Agile principles. For example, here are three Agile principles that we should keep in mind for this video.
- Working software is the primary measure of progress.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Simplicity–the art of maximizing the amount of work not done–is essential.
If working software is the primary measure of progress, we need to make sure we organize and track our work in a way that supports this goal. We need to make sure that our work is organized and chunked into units that represent value to the customer and we need a way to sort out what is extremely valuable from what is less important.
Most teams find that the best way to achieve these things is to visualize their work so it is easy to see what has been done, what is being done and what is yet to be done. Visualizing the state of various pieces of work can be done in software or even on a wall with sticky notes, but in this video we want to concentrate just on how to represent the units of work. A good approach is to represent the work through simple stories that describe what the users world must look like in order to mark a story as complete. Here are some example stories using a typical story template.
As a registered user
I want to change my password
So I can keep my account secure
As a website visitor
I want to subscribe to the mailing list for a product
So I can get product updates through email
As an admin user
I want to disable a user
So I can prevent unauthorized logins by past employees
As a mobile app user
I want to save all my data to the cloud
So I can access it from another device
There isn’t anything magical about this particular format for stories. The examples we’ve just seen cover who, what and why. Having a template is a good way to make sure you capture enough information to represent the idea of what the user needs without getting bogged down in the implementation details.
When our development efforts are driven by stories that represent our understanding of user needs, it supports our principles and fosters good development practices. Stories that are written in ways that violate our principles will hinder good development practices. Anything we can do to increase the quality of our stories will make the rest of our development process more efficient.
One time I was working with a team that was just starting to organize their work like this and we were using a template similar to the one we’ve just seen. One of the users had missed the initial meeting where we explained what we were trying to do. He was a bit confused and asked why he kept seeing all these short pieces of poetry about the software. Evidently he thought we were writing some strange form of haiku.
Good user stories start off as fiction. The setting is the world in which the user interacts with the software. The story is written from the user’s point of view and talks about things from the perspective of the user. The user perspective is very important because our principles say that we are going to define our progress based on giving the user the ability to do something valuable with the software that they were not able to do before. If we are working on stories that aren’t creating business value for the customer, we are doing work that we’ve explicitly said isn’t going to count as progress.
So how do we handle all the work we need to do that the user can’t see? How do we handle stories about the developer’s world? How do we handle stories like this?
As a developer
I want a database with all the tables to model the data
So I can store information the application needs
This is a bad story because it violates our principles for software development. Notice I said the story is bad, not the idea of having a database to store data. We definitely need a database, but if we create this story, almost all of the application depends on it being done first. We could complete this story and have no functionality we can show our user—nothing they can actually use as working software, but this would violate our principles. Further, the information we need to acquire to complete this story will only be known when we figure out how we are going to build other parts of the system. So in effect, a story like this is both a prerequisite for and a dependency of every other story.
When you have two things that both depend on the other being done first, you have a recipe for deadlock. If you’ve ever worked on a story like this, you may have experienced a long period of time where the user is asking how things are going and the development team is saying, “Well we have a bunch of setup work to do first before we can start working on the actual application.”
There is another way. If you write your stories from the user perspective you can build just the parts you need in order to create some value for the user. This likely will mean building some of the database, but only the pieces you need as you need them to complete each story.
It may seem counter-intuitive for developers to build software from the users perspective because such an approach means you may have to rework some of the things you’ve done in then past as future stories become clear. However, software projects that fail usually do so because they weren’t focused on delivering actual usable business value to the user on a regular basis. Building the application the way the user thinks about value minimizes this risk. If you are following the other Agile principles, the cost of some rework is trivial compared to the benefits it provides in delivering business value sooner rather than later.
