|
|
|
|
|
|
by eterm
3784 days ago
|
|
|
But there's a difference between "production ready" and "customer ready" which Agile practitioners sometimes seem to forget. In many businesses, software is not the core business, you're not building software for yourself, you're building it for other stakeholders. It's not acceptable to say "Well it only does 20% of what you wanted". What happens when things start to slip, so in fact you won't have something the business thinks it can present at christmas? "Don't worry, we'll just keep working on it until it's ready" after having spent 6 months on it isn't good enough. It's not a bad thing to do a lot of estimating up front so the business can make an informed decision about whether it really wants to commit to the effort, rather than finding out during all the sprints about the growing effort required to get it to where the customer or internal stakeholder is happy. |
|
|
You're assuming the estimate is worth much. Which is what much of the industry is doubtful about. To underscore the point, most estimates are single values (eight months), not confidence intervals.
A better answer would be, "There is a 50% chance that we get it done between six and seven months from now, assuming requirements don't change."
...but even that assumes that all along the way, the project stakeholders are keeping in mind how many (how do you quantify?) requirements were added and discovered.