Seattle Software Developers


Pugetworks Blog Archive!

As a consulting firm, I want to define user stories so that I can provide a more accurate budget.

Many of my conversations with new clients revolve around the question of cost.  But, this can’t be figured out until you know what it is you are talking about.  My favorite tool for defining a product is the humble user story.

A user story is a simple one sentence definition of some feature.  It looks like this.

As a ____ I want to ____ so that I can ______

You fill it in so that it looks like this

As a user I want to log in so that I can see my account

The trick here is to start listing these and you will start to notices several things.

  1. First, in defining who is going to do what, you start defining all the roles for the product.  This could be the administrator, visitor, customer, etc.  These roles provide the development team with a great perspective as to what needs to be done for each group and lets them understand how to organize the permissions.
  2. Second, you are forced to define all the missing functionality.  For instance, if the user can log in, then you assume that the user can log out.  So define that.
  3. Third, you are essentially creating a checklist to tell you when the product is functionally done.  After development is underway you can uses these user stories to figure out how far away the finish line is.  

Finally, you have a definition of scope that can be reviewed with a client to make sure you plan on building the right thing.  Although it is true that feature creep tends to happen on a project, these initial features usually stay stable.  No where on these stories does it explain how these tasks are accomplished.  Based on budget and time, they could be very differently addressed.  But, you have created a common starting place from which to create a budget and define what is going on.

There are some advanced things you can do with user stories as well.  I personally, like to group them by role.  That way all the admin features are in one place.  I also like to have the client define which are to be done in the first phase, second phase, and future.  Usually I use colors to do this, but the end result is understanding the priority of each feature.  This tends to lead to great conversations that let me understand what is driving the project and what success means to them.

If you have never used these before, you should try it.  It is a great way to get a group on the same page as to what is being defined.  Usually I take about half an hour to write it out and then share it with the client.  They can then help me fill in the missing stories and correct me where I didn’t understand what they wanted.  The end result is usually about 1 or two pages of user stories that give us an idea of where the end of the product is.