The way of thinking when we try to bring a whole complicated process of software delivery down to a single number, to a single date, to a single measurement is a post-industrial inheritance. If you have a factory, you are more or less able to determine the velocity and capacity of an assembly line or a robot in a given period of time. Creative branch, fortunately or unfortunately, eludes such simplifications. Is a writer able to tell when the inspiration will come or the muses show up? Highly doubt it. Luckily, IT branch is somewhere in the middle. Most of the time we don’t produce highbrow or lowbrow art, but we’re not an assembly line either.
Some people think that Agility has been created to speed up development. Well, it may seem so, but not because things are happening faster. Each project has four basic characteristics: cost, time, scope and quality. It’s implausible to satisfy all of them at the same time. Successful project management requires skillful balancing between these four elements. And here Agility kicks in, as it is a powerful tool thanks to which we know the team’s velocity and the current state of the project. It helps to make well-informed and data-driven decisions. There’s no magical way in which impossible becomes possible; for instance, if a project requires a given amount of time, Agility will not suddenly make it shorter. However, when you know that half of the time has passed and you’ve accomplished only 1/3 of the work, then you can make a suitable decision. Tough as it may be, it’ll save the project as long as the situation isn’t desperate.
Putting that aside, let’s focus on the crux of the matter - estimation. First of all, you need to answer the fundamental question how important the estimation in the context of your project and organization is. Second, an equally important issue is the required accuracy of the estimation.
Think about this: you work for a company which is about to sign a new contract, with a fixed timeframe and budget which will be based on your estimate. Thus, your estimate is key as it can either sink or swim the project. Or, you work for a product-based company which is crazy about quality and can even accept delays and/or exceeded budgets in order to keep its high reputation.
Each project new context, and so different needs and expectations.
The same goes for accuracy. In some cases, simple expert estimate is enough. A developer who knows a project reads a draft of requirements and 5 seconds later provides an estimate. It is probably one of the most inaccurate ways, but in many cases it may be good enough. For many projects the margin of error is quite high. At the same time, it is one of the cheapest estimating methods. Having said that, it is important to emphasize that expert estimate works well for smaller projects, more granular tasks, and not so well for big items with many question marks.
In another situation, a much more accurate estimate is necessary. It could require much more time and money, but even more money is at stake. Sacrificing four weeks to prepare a blueprint, to collect a list of detailed requirements, to create spikes and to do necessary R&D, all of that performed by good - but pricey - professionals, can be worthwhile. Mind so it doesn’t turn into Waterfall!
No matter what, there’s always a margin of error. The question is how much of this margin is acceptable?
Remember, any practice taken to the extreme can become harmful. And, we shouldn’t be doing anything without fully understanding why we’re doing it. Ask yourself, what kind of problems you’re trying to resolve by doing estimations, and what way of doing it is good enough? Any other will just be a money loss.
Latest comments (0)