In the world of software development, one question rules everything: when will your project be ready for release? Unfortunately, this also turns out to be one of the most difficult questions to answer, and there are countless books on the topic of project management that attempt to lay out methods for estimating "how long it will take."
Most methods, like classic waterfall, try to describe every possible task for a project, estimate the time required for each, and then lay them all out in a gigantic Gannt Chart that, at the very end, tallies up the time and gives you an answer, plus or minus six months. But the real key to being able to answer this question is not based on being able to accurately predict duration, but velocity. The difference is that the first is based on someone, usually external to the development team, coming up with an estimation of how long a task should take. The second is based on the team's experience and understanding of what they can reasonably accomplish within the two week sprint cycles that are typical of Scrum development.
The mechanics of calculating velocity for any team are pretty straightforward. In Scrum, large projects are called Epics, which are made up of Stories that represent the major tasks that need to be accomplished. A team looks at the stories assigned to them, and provide an estimates of the effort that each would require on a numerical scale. At Sauce, we use the scale 1, 2, 3, 5, and 8 points, from "really easy" to "so hard we're not sure how hard it is." Then, over the course of a two week sprint, you find out how many points the team "burns down" from the overall estimate. Over the course of several sprint iterations, you will be able to estimate the average number of points that a team can burn down within a sprint, which is the velocity for that team.
Velocity is the key to answering "when will it be ready?" Once your teams have learned how to gauge what they can reasonably achieve in one sprint, and how to accurately estimate the amount of effort that a single story will require, they can provide you with very accurate answers. Of course, in the beginning, many of their estimates will be off; it takes multiple iterations for a team to understand their strengths and their dependencies, but practice makes perfect. When we started Scrum at Sauce, we discovered many things that impeded the progress of our teams, but as we dealt with each one, the teams also improved in their abilities to estimate how much effort each story would require, and improved their overall velocity.
Understanding the velocity of your teams over two week sprints is the only way you can build a product roadmap with confidence. In the course of every major project, something will come up that blocks your efforts. If that happens in the midst of a long project that you have timed out by days over the course of months, this will lead to a major train wreck. If it's something that slows down the velocity of your team, you move on with what you can get done, and deal with the blocker as its own issue. Ultimately, velocity helps your teams become truly agile, so that when a problem comes up, they can respond in a way that doesn't drive the entire enterprise off the rails.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the eighth post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Start from the beginning and read the first post here, or read the next installment in the series.