Planning any large project, and by large I’m speaking of projects that last 3-8 Months, is often viewed by many as a shot in the dark. Nearly two-thirds of projects significantly overrun their cost estimates and the average project exceeds it’s schedule by 100%.

Any project with one hundred plus features, or one which dives into unknown territory, is going to produce obstacles which will threaten the plan. Clashing features, unknown API’s, growing database complexity, or a lack of understanding of the complexity of a feature will all push out the project’s time line and jeopardize the schedule.

However, with a story based planning and development strategy it is possible to see these risks coming and plan accordingly with very little overhead.

The Traditional Method

Many project estimates boil down to a bullet point document that lists out all the features your site may contain with estimates on each denoting the features price and or time to implementation. These project plans are often accompanied by Gantt Charts or other visual time lines and conclude with a final estimation on the total cost of the project.

An Example

• User System
  • User Login (0.5 days)
  • User Account Manager (3.5 days)
  • User Profile (4.5 Days)
  • User Profile Manager (6.5 days)

While at first glace this may seem comprehensive, there are many issues with this method.

• Information overload makes it difficult to identify all the features
• It’s difficult to tell how removing a feature would impact the price and time line
• No priority is provided to features making it difficult to identify high priority items
• The difficulty in implementing the same task (like accessing a user’s account) in different features is not represented
• It makes it impossible to gain a solid understanding of complexity at the feature level
• It’s far too easy to inject functionality thus inviting scope creep into the project

After thinking about this list of features you might ask yourself “Why will the account manager take so long?”, “What is included in the profile manager?”, “How will the user profile display information and what will be included?”, “This will take too long, how can we deliver these features faster?”.

The Story Method

The Story Method replaces the bullet point feature lists with definable business objectives. Each story contains:

• A point value which denotes the stories relative complexity versus other similar stories.
• A defined user or actor who would interact with the system.
• A theme which defines larger functionality.
• A business objective statement which defines the desired outcome of the functionality.

Let’s extend the examples above into stories:

User Login Theme – 3pts total

(2pts)	As a User, I want to provide my login and password information in order to access restricted areas of the site
(1pts)	As a User, I want to instruct the system to remember my login information so I can be automatically logged in on my next visit.

User Manager Theme – 7pts total

(3pts)	As a User acting on the User Manager, I want to access my account information in order to change my login, password, and email address
(3pts)	As the System, when a User changes his email address I want to send a confirmation email to verify the address is valid.
(1pts)	As a User, when I change my email address I want to click a link in a validation email to confirm my email address.

User Profile Theme – 12pts total

(2pts)	As a User, when I view my profile I want to see my profile photo
(3pts)	As a User, when I view my profile I want to see my contact information
(8pts)	As a User, when I view my profile I want to see my personalized list of content

User Profile Manager Theme – 17pts total

(3pts)	As a User acting on the Profile Manager, I want to edit my own profile so I can change my profile photo
(2pts)	As a User acting on the Profile Manager, I want to edit my own profile so I can change my personal contact information
(12pts)	As a User acting on the Profile Manager, I want to edit my own profile so I can select my preferred list of content

The stories above provide a wealth of information on the proposed features. We know who will be interacting with our system (The User). We know why the feature is important to the user through defined business goals. We know what the user is trying to achieve, thus we have begun to define our acceptance criteria.

We can also see that the personalization of content in the User’s profile is quite an intensive task, it makes up roughly 3/5ths of the total point value. Should the client wish to speed the delivery of this feature set, eliminating the content customization from the next project release would be a great way to speed delivery while maintaining a rich feature set.

Further, if our team knows that we have been averaging roughly 17-21 completed story points every 2 week iteration of the project, we can accurately set expectations with the client. The client is then able to quickly prioritize the features that will be desired.

More control, better communication, faster estimations.

The story method allows us to focus on the features which will be seen as most useful by the customers of the applications. Client’s get a hands-on approach to the development of the project. They are able to quickly prioritize items they see as high value and easily see the impact on the schedule as they move items between iterations.

As the developers, we are able to see how features interact with each other and communicate this to our clients. We find this communication invaluable to keeping the client engaged and active in the creation of their project.

And finally, the use of story points rather than calendar days allows us to stay flexible. Should on