When will the product be done?

“When will the product be done?”

That question will always plague the minds of any technical leader and for very good reason. “Publish or perish” used to only apply to professors and researchers but today it applies also to Information Technology. In Agile, getting a clear estimate of “when will the product be done?” can be a very frustrating exercise to CTOs, CIOs and IT Leadership.

Today we live in a world of uncertainty and having a clear scope, schedule and budget is needed as much as ever when all businesses are pressed to come up with the next best thing to propel themselves ahead of their competition. However, history of project delivery has taught us that having an accurate estimate of the future for products built with a level of uncertainty is an expensive waste of time and budget. So how can an estimate be made with any degree of confidence of the unknown?

For Agile, that answer is via story pointing and velocity.

Scrum and ScrumXP are the most popular Agile-based delivery implementations, dominating over two-thirds of those methodologies[1]. An estimate of time and cost can be made using story pointing and then by dividing the team’s velocity. It’s that simple in concept.

First a requirements backlog must be established with a clear end, often called the Minimum Viable Product (MVP). From there an overall point value is determined by those experts that know the best on what is being built and the delivery team that shall build the solution. The MVP is the minimum set of highest priority features needed to release the product. Nothing more can be taken out without breaking the core product. Velocity is the measure of the team’s performance in terms of story points completed within a given set of time.

Story pointing is a method to help the Product/Business Owner identify which of the top priority stories in the MVP will fit into the next iteration based upon the team’s performance or “velocity” in past iterations. Knowing the stories level of effort to complete gives the PO another element to consider in their selection. Ideally, points are a measure of effort between different types of work. They are kept as a relative measurement because how the story will be completed has not yet been figured out. Hence, without knowing how you will build something, how can you accurately estimate how long it will take to finish?

When hours-based estimates are used, we humans have an immediate tendency to place our own perceptions into what it would take for us to complete the work, what it would take on our best day to do the work or even what we believe the rock star developer that everyone envies will take to complete it. The worst part is these can vary from person to person and even for the same person based on their mood and perspective! This leads to heavy variation in the quality of the result and usually leads to much wasted time on coming up with the “right estimate”. For here, “perfect is the enemy of good enough” in order to stop over estimating and start building.

Story pointing is intended to even the playing field and look at work without incorporating those human factors. People are very good (and quick) at comparing two different buildings and say “that building is three times farther away than that other building” without perceptions modifying their view. The same idea goes with the effort of building a product.

Now back to “when will the product be done?”

At the beginning, a general estimate for the schedule would be derived from the total story points. It is highly recommend that at least 80% of your total requirements backlog have been broken down to enough detail for the delivery team to determine how to build it. With that baseline, your initial cost and schedule can be derived.

However, due to the level of uncertainty at the start and the principle that the uncertainty decreases the more you build the product, it is then prudent to check the total story points after the third or fourth delivery sprint (typically 2-3 months). This will be your new schedule and may be twice the size of your original estimate. That’s when the MVP must be closely scrutinized and if necessary, decreased for meeting delivery constraints.

Remember, the goal of any software delivery project is to deliver software. Nothing else matters! If too much time is spent on estimating, precious development time is lost. If not enough time is spent on estimating, the project may run out of budget or time and get cut! Story pointing and velocity-based estimation bridges that gap. This is the balancing act and will improve from experience.

 [1] VersionOne 10th Annual State of Agile Report