Estimating the time it will take to make a software feature can be quite a challenge.  In order to have a reasonable discussion about how long a feature will take, we really need to have a reasonable idea about what the feature is.  Good estimates depend on good software descriptions.

My favorite way to describe software, for the purpose of estimating, is to develop “user stories.”  User stories are short phrases that describe a behavior that the software needs to have.  I have used two different ways of writing stories that seem to work well for me, so I’m pretty sure there are more than I describe here.

I first learned about defining a software product using stories from the book “Extreme Programming Explained: Embrace Change” by Kent Beck.  Later, more definition was added by Mike Cohn who wrote a whole book on user stories.  Cohn has a handy formula for writing them.

He suggests that you follow this form:

As a [user] I can [some behavior]

For example you could write:

“As an ATM customer I can request my current account balance.”

Another one might be:

“As an ATM customer I can enter my PIN before I am given access to my account.”

This form is very popular and I find that it works great.  Before I learned about the Cohn story form, I had developed a form myself.  I still like it because I think I am able to break stories into smaller pieces more naturally and it has a cool side effect.

Simply finish this statement:

“I will know that progress has been made when …”

What you write after this statement is usually a great user story.  The Cohn form fits this method as well.  I also found a similarity with the results of my form and the development of a “User Manual”.  The sum of all of the stories could reasonably become the product user manual.  Check out these three stories:

• I will know that progress has been made when the software provides a place for the ATM user to enter their PIN.
• I will know that progress has been made when there is a way for a user to ask for their account balance.
• I know that that progress has been made when the software provides a way for an ATM user to print their account balance.

Now listen to them without the “I will know…”part:

• The software provides a place for an ATM user to enter their PIN.
• There is a way for a user to ask for their account balance.
• The software provides a way for an ATM user to print their account balance.

Notice that this sounds a lot like a user manual.  Steve McConnell in his book: “Software Project Survival Guide” describes a way in which user manuals can be used as requirements documentation.  I really believe that he was on to something when he wrote that.

The best stories are isolated, meaning they don’t depend on any other story.  This may seem to be too difficult at first, but it is actually quite possible.  Don’t give up on making great stories. Using practices like this can help to make it easier.