You Shall Know Our Velocity!

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

With apologies to Dave Eggers, this post is not about traveling around the world in a week to give away $32,000, but about measurement and agile development.

One objection to agile development we get sometimes from people who have never done agile is that it sounds too undisciplined, unstructured and risky.

Would they say the same thing about lean manufacturing or six sigma?

They’re confusing agile with cowboy coding.

In fact, like six sigma, agile software development is explicitly about reducing risk, measuring efficiency and continuous improvement.

The old management adage of “You can’t manage what you don’t measure” holds true in software development as well. If you have no feedback loops, and you’re not measuring and improving, you’re not really doing agile development.

The core measurements we use are story points and velocity.

Story Points

Once software features have been broken down into stories and have been compiled into a master story list, we assign story points to them. Story points have a value of 1 to 8 and are meant to convey the relative effort required to complete a particular task. One is the easiest possible effort; eight is the highest effort representing the most difficult task that can be completed in one Iteration. Stories that are estimated to have a value of five or higher get broken into two or more “linked” stories that have a story point value of less than eight and can be completed in one Iteration.

The Master Story List is organized into releases. Each release represents either an internal or external beta or a full production release.

Velocity

Velocity is a measure of how many stories can be specified, designed and coded in one Iteration. A measurement of Velocity is maintained for the production of the design, actual code and unit/regression tests that form the final software product.
Velocity is measured as follows: At the end of each Iteration, we count the number of Story Points that were completed and accepted by the customer in that particular Iteration. This quantity forms the Velocity of an Iteration.

Project Burndown

The Project Burndown of a project is a chart that displays three measures: the amount of work to be performed in story points (obtained from the Master Story List), the work completed in prior Iterations in story points, and the estimated cost and date that the full feature list for the project will be done (derived by comparing the estimated number of story points remaining and the Velocity at which they are being completed).

The Project Burndown provides the earliest warning of any risk that the feature list contains more work than can likely be completed within the specified budget or timeline. The chart below shows an example Project Burndown for a team with a 10 point per Iteration Velocity and 65 total story points in scope for the next release.

Story points, velocity and project burn down charts are key to managing an agile development project. During the course of a project, an agile team strives to increase their velocity by continuously improving how they work.

Next time: How velocity helps you manage changes to features, budget and deadline.