Introduction to #noestimates
We all have been in situations where we have given estimates, and they were wrong, and management held us accountable. And on the news, we hear every day that how big projects are overrun or cost many times more than originally estimated. What is the point of doing estimates as they are just a guess and this is what Woody Zuill and Neil Killick are campaigning about.
Pro #Noestimates
Estimating software development is a waste of time
The #Noestimates camp claims that estimates are a waste of time as you are not adding any value. Taking time to add estimates to each task or story adds no value to the business. This time could be better spent towards delivering the working software, the main objective of the Agile Software development team.
Estimates are generally wrong and management holds the team accountable for them.
Firstly, estimates are merely a guess, and at the time we are making estimates, don’t fully know the requirements. Also over the time requirements change, but we still need to fulfil the commitment of estimates we had given. This leads to pressure from management and forced to do overtime. All which are terrible practices and go against the core fundamentals of the Agile manifesto.
against #noestimates
Project delays are not always caused by bad estimates
Generally speaking, major project delays are not always caused by wrong estimates. In both Agile and Waterfall projects, if the project is managed properly and communication with stakeholders is transparent than issues like underestimates are dealt with as soon as it becomes apparent. Most of the time when major project delay takes place, and it is a complete shock to the stakeholder and sponsor is because something more fundamental has gone wrong with the project, or within the project team.
Estimates help team define the requirements
Using the planning poker estimation help the team understand the requirements better and bring the assumption being made by each team member. After each round of estimation, the team would discuss the reason and assumption behind their estimates. It will give the team better understanding of the story they are estimating. Also, the story point estimates are only for the team to understand the requirements and also to see how much they can commit to in each sprint. With the story point estimation, the management cannot try to micromanage the team and hold the team to the estimates. Also, the t-shirt sizing is another estimation technique that Agile teams can you that would protect them from management’s micro estimate management. Note: #noestimates camp doesn’t have an alternative way to highlight the assumption the way planning poker does.
Estimates help business and Product Owner
Estimates help business and Product Owner assign priority and help them decide if the effort is worth the value. When the Product owner knows the estimate for a user story or feature he/she can decide if the value delivered by the user story is worth the effort. Feature estimation and user story estimation is generally being done in story points and overall is quite accurate.
Customers demand the estimates
If you are working on a customer project, then they will, of course, ask you for an estimate. No company has an endless budget so they will want to know, how much it is likely to cost to deliver the project. Also, the timing of the delivery is critical; the customer needs to know that the product will be delivered within a timeframe that is acceptable to them. Without doing a high-level estimate then both of these two critical points for your customer would be unavailable.
My viewpoint on #noestimates:
#Noestimates are useful in certain conditions, and it should be the whole team with Business stakeholder to decide if the #noestimates can be the way forward. #Noestimates are probably useful in a team that is using Kanban as estimates are not part of the process. Also, DevOps teams generally can get away without doing the estimations, and #Noestimates might be the way forward for them.
Basically: If you are not required to produce estimates then don’t.
#Noestimates is useful but not practical for every agile software development team. #Noestimates is not a silver bullet to use for every Scrum / Agile team.
Here are some thoughts:
▪︎ Estimating software development is a waste of time – a waste for whom? Developers possibly, but those paying the salaries of developers, expecting some value to appear in exchange for that cost likley have a business need to know something about cost and when that value might appear.
▪︎ Estimates are generally wrong and management holds the team accountable for them – estimates have precision and accuracy. “Wrong” is only that case when the needed precision and accuracy are not defined before the estimating process starts. Management has an expectation that those contributing to the estimate are sufficiently knowledgeable of the work to provide an estimate that can meet the needed precision and accuracy, or make it clear that they are not capable of producing an estimate with these attributes. Management expects this information be conveyed in a professional manner.
In the absence of skill, expecience, information, and tools, developers will have a hard time providing the needed information to management. Find the Root Cause of this condition and work on improving it.
Then the benefits of estimates you state will start to appear, and it will be a win-win situation.
All project work operates in the presence of uncertainty. Reducible uncertainty and irreducible uncertainty. Making decisions in the presence of these uncertainties requires making estimates
Uncertainty creates risk.
As Tim Lister advises us – “Risk Management is How Adults Manage Projects.”