To estimate or not to estimate
Many teams show a reluctance to provide estimates. This is both frustrating and understandable to project managers (PMs) and product owners (POs) who might be asked to provide budgets and timelines to clients.
I have been reading up and listening to casts around ways to estimate when working with an agile team and stumbled onto a No Estimation movement #NoEstimates where some argue there is no value in estimating work required to deliver a project or feature.
Let’s break it down like this. In Agile Scrum, you would use the Scrum Planning ceremony to allow the team(s) to look at the goals as proposed by the PO (Product owner) and compose the User Stories required to deliver that goal through a Sprint.
Agile Scrum provides a form of gamification when estimating, such as Planning Poker or the bucket system, T-shirt sizing etc. those are very helpful ways to breakdown the work into smaller more digestible chunks and gain a holistic understanding of what is required to deliver a feature. However, is the main goal to gain consensus and install ownership? or is it to satisfy the stakeholder paying our checks?
Here are some pros when estimating tasks:
1- Creates team cohesion and consensus [if done correctly]
2- Allows teams a wider understanding of the project scope and helps identify risk at an early stage.
3- Gives teams a target
Estimates can be used to give the team a target. If you are not estimating, you could be in freefall, which could lead to loss of focus [Give a person 5 days to build a fence and he/she will take 5 days to complete, give that same person 3 days …] in other words, the activity you do will expand to the amount of time you give it.
Here are some cons when estimating tasks:
1- All estimates are guesses. This is especially true when working with new technology and innovation. The exception being, if you are estimating exact project requirements to something you have done previously. In which case you are doing waterfall not agile.
2- Less confidant or experienced developers start deferring to their seniors, agreeing to whatever they suggest the effort level should be.
3- Decision makers start holding teams to estimated deadlines.
Estimation used badly, allow PO’s & PM’s to hold a team on an end of a barrel. [but you said this will be done by November] creating a toxic atmosphere. An estimate is what it is, ‘an estimate’ not a date carved in stone of when the project will be delivered.
Conclusion
To counter act the cons listed above, as they are bound to happen, PM’s and Scrum masters should do more to protect teams by being explicit about what those estimates are, and what they are not.
Equally, not every team has the luxury of not being asked to provide estimates, hence, should we not arm our teams with the skills to estimate? After all, it is our duty to help teams grow and learn outside of assigning them to work that takes them out of their comfort zone.
Any thoughts on this topic are welcome, the search for best practice continues