Predicting Product Release Dates Using Agile

By Jeff M Nall

If you can't reliably set a project deadline based on hours of work, how do you do it?

Everything hinges around User Stories and the relative effort the team assigns to each. The Product Owner solicits users for the features they want in this new product and captures this information in the form of User Stories. During Sprint Planning (and backlog grooming-another topic) the team gives their best "Snap" judgement of how much effort it will take to complete a story. Effort is reflected in many ways but most commonly using a Fibonacci number sequence (1,2,3,5,8,13,21,44,65, etc). A low effort Story is a 1, increasing in difficulty the larger the number. The Product Owner considers the effort involved along with how valuable functionality is to the customer base and prioritizes the User Stories accordingly. The highest value, lowest effort stories tending to be first in the priority list ending with the lowest value, highest difficulty stories at the bottom.

An Agile team determines it's commitment for a Sprint based on a history of how many Effort points a they complete on average in a Sprint. Let's say in the last Sprint the team completed three user stories. The team came to a consensus that each of the three user stories had effort values of 3,13, 1 and 5. The sum of these numbers is called Velocity.

The team has a Velocity of 22.

With newly formed teams this Velocity number will vary wildly from sprint-to-sprint. Established, well functioning teams will see this number stabilize and increase over time. I'm leaving off quite a bit of info on backlog grooming, technical debt and making adjustments on the fly, but this 30,000 foot view hits the highlights. I'll cover Velocity points in detail in a future post because while they're simple, I've seen them misused as ratios to hours worked and generally something other than the educated "snap" team judgement they're meant to be.

So how do you predict the release date? You do it basically the same way a team decides how many user stories it can commit to completing in a Sprint. At this level, add up the effort points for all of the user stories that comprise Version 1.0 of your product, divide it by the amount of effort points the agile team is averaging in a (typically two week) sprint and look at a calender. You'll get a decent ball park estimate of when the product will be finished. Let's say you've added up the effort points of all of the user stories in Version 1.0 and you've come up with 100. Your agile team is averaging 20 points in a two week sprint. You can plan on about 10 weeks for a rough project completion time.

You can still generally plan your releases in Agile just like you do in any other development model, you just have to learn to rely on different indicators, that's all. The big difference is Agile acknowledges the unknown while other methods try to hide it.