Why estimating?

If our estimates are always wrong, and most of the time they are, why should we even attempt estimating in the first place?

I can easily identify at least four reasons why we still do estimations:

• Arrive at a shared understanding of the user story

• Split user stories into smaller deliverables

• Organize Product Backlog based on value and effort

• Plan upcoming work

Estimation problems start when used to set project deadlines and team performance.

Why not estimate in hours?

If you estimate in hours, you run a risk of having a lot of discussions based on the seniority of the developers doing the job

People generally underestimate obstacles they might face and consider only the best-case scenario.

If one developer estimates a project, but another completes the task, the estimate becomes invalid.

Why estimate in story points?

The Story Points approach compares the story being estimated with one or more other stories. “This story is a little bigger than that story.”

The comparison allows the team to understand the difficulty of a particular feature and lets them assign a numerical value that indicates its complexity.

There is evidence that we are better at estimating relative size than we are at estimating absolute size.

Why can the Scrum Velocity metric be evil?

Do you know what a team usually does when management uses velocity to measure productivity? What would you do?…. Yes, “story points inflation.”

From here, you are only a step away from broken trust, frustration, and culture damage.

Software quality will deteriorate and make things much more difficult in future sprints.

Bad intentions aren’t even required for this to happen. It’s natural human behaviour.

Metrics that matter

Based on research, programmers spend 35% of their time on understanding code, 5% on writing code, 10% on other coding-related activities, and 50% on other non-coding activities.

None of those activities above can be measured upfront. What should we measure, then? As we learned from Agile Principles, we should hold up to what truly matters: frequently delivering value to our stakeholders at a constant pace.

Value delivered - defects = customer satisfaction; Those are the metrics that matter at the end of the day.