Estimating a Product Backlog Item (PBI) is not only about providing an estimate but also about creating a shared understanding.
There’s a tendency within the Scrum community to vilify certain practices. Story point estimation is often seen as one of these “evils.” I came across a post that said, “if someone explains story points in a Scrum training, walk out immediately.” Wow, really? Are story points that bad and a waste of time?
It depends on the team’s context and how they estimate. Let me explain; if the team:
🔸 Needs to create a shared understanding of the ‘why’ and ‘what’ of PBIs before starting to work on them,
🔸 Needs to consider the design and dependencies of the PBI,
Uses an unitless number (a number that doesn’t represent days/time, etc.),
🔸 Estimates relatively,
then I would recommend estimating PBIs. Moreover, estimating encourages the team to ask questions to identify the open and/or unclear aspects of the PBIs. Many of you can probably recall at least one instance of this happening within your teams. This in turn reduces the rework and increases the quality.
On the other hand, if your team has very small PBIs by nature and doesn’t need to consider them before starting work—for example, a team that mostly handles operational and support tasks—then I would suggest not estimating PBIs.