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.
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.
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.
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.