There are many misconceptions about time and estimating in Agile teams. One I hear all the time is that story points are no use as an estimation metric unless they are standardised across the organisation. Another is that story points must ultimately equate to time. Another is that story points are the only valid way of estimation. Another is that estimation is always necessary.
Story points are an abstract sizing metric, and are not intended to represent actual time. The problem with abstract sizing is that unless you have a standard applied across the organisation then nobody outside the Agile team can understand their meaning. The problem with standardisation is that it is usually only achievable by equating it with delivery time. The problem with equating story points with delivery time is that it is utterly bananas. The purpose story points serve is to allow for teams to understand the relative sizing of the stories in their backlog. This can allow them to prioritise work and plan accordingly. It can also be used as the basis of velocity calculation, where the number of story points delivered in a sprint will fluctuate over time as the nature of the team changes. I have italicised ‘can’ in the previous sentence because there is a common misconception that story points are required to measure velocity, but velocity can also be calculated by simply counting the number of stories delivered in a sprint. Obviously this approach doesn’t account for the complexity of what was delivered, but a) it usually averages out over time, and b) story points aren’t great at that either. There have been a very high number of retrospectives I’ve witnessed where the reason given for sprint failure was that the estimates were wrong. Complexity often emerges as the sprint evolves, it’s part of being agile! Revising the estimate to reflect the actual complexity of the story after it’s done just so that the velocity accurately reflects what was delivered is an anti-pattern I’ve witnessed on many occasions. The clue is in the word ‘estimate’!
The other thing to be aware of is that some things don’t bear estimation. You may want to time box certain R&D activities, but you can’t usually estimate them. Similarly, analysis work is usually unquantifiable: Rabbit holes often go quite a long way, but until you’ve explored them you don’t know that you know everything you need to know.
By all means estimate work, but don’t let estimates cripple your teams and/or your organisation.