Estimating in Agile projects - breaking down requirements into small stories
The first step after gathering all your requirements for a software project is to estimate the effort required to develop them. The estimates, which determine the size of the project, are your decision factor. Many projects are shelved before they even start, right after the estimation process. This sometimes occurs when the executive sponsor realizes how big the project is relative to what the original guess was. I had this experience once when a client’s reaction after estimation was, “What, $3 Million and 30 months? We thought it would take $1M and 12 months. We will have to think about this one.” Well, time kills deals, our sales manager once told me, and that was the death of that project.
However, for any project, better an early death than a prolonged painful life. You need to know what your project will cost. The common misconception in the software world is that the hourly rates of the consulting firm that develops the application in question, or the size of the team required in-house - determines the cost. Sure enough they matter, but most importantly it is the effort estimates that indicate the size of the project, that tells you the cost.
Estimates are just that, estimates. How do you know that the estimates are accurate? Well, they never are. However, they can be as close to the actual effort as possible, if the estimation process is scientific. Yes, it is a science. Only very good estimates will give you the confidence to go ahead on a project.
The first step in estimation is to break down your requirements into small enough slices (let us call these stories) so that the developers can get their arms around it. This is a Business Analysts’ (BA) job. Working with the Business Process Owners and end-users, the BA’s can break down the requirements into small whole stories. I say “whole” because each story should still hold on its own as a functionality, yet should not be more than a few days of effort by the developers.
There are many ways to estimate the effort of a functional requirement. Different developers apply different methods and many of these could be valid except that there exists a risk that the developers who are estimating may be wrong on the estimates. Now that is scary. How do we minimize these errors? This is where following a scientific process is important. What process do we follow? No one recipe exists, but T-shirt sizing (explained in Part II) is one method that can make things easier and less prone to error.
This post is part of the series: Project Estimation in an Agile World
The estimation process in an agile project before you plan; how to capture stories, estimate with very little information, yet be accurate. Applying science to capture good estimates.
