What's the Point?

Anyone who has worked in an agile team will be familiar with the concept of agile pointing, seeing everyone in the team holding up cards and declaring an item of work to be 5 points, 8 points, 13 points....

But why do we estimate like this? Wouldn't it give more certainty to the business if we gave an estimate based on time?

Well we do have our reasons, there is a point to pointing.

I'm Almost Done

People are generally bad at giving absolute estimates, developers will often be overly optimistic about how long something is going to take to code.

We are however much better at relative estimation, we can identify that one piece will require more effort than another and we may even be able to apply some kind of scale, its half as difficult or twice as complicated.

Moving towards this unit-less relative approach concentrates the mind on blockers or issues that are causing this increase in points.

This relative measure will also carry more historical significance, knowing that a similar task took 5 days to complete six months ago has very context in the here and now as the team may have been operating under very different conditions.    

Velocity towards Success

Using points based estimation forces all planning to be based on measuring the teams past performance, what we usually deem their velocity.

This focuses the mind on how the teams performance can be improved and the longer the team work together the more accurate this measure of their performance will become.

Two week sprints always contain two weeks worth of effort from the team, the focus should be on how the amount the team can deliver in that period can be optimised.

Estimating in days can very quickly lead to the flawed mathematics of man days.

A scrum team should be viewed as a team and not a collection of individuals, the team achieve things and this can be made to add up to more than just the number of hours they spend in the office.  

Playing as a Team

A scrum team will very often be made up of a mix of individuals with differing experience, ability and skill sets.

Given this mix the amount of time a task takes an individual in the team may vary but team members are more likely to agree on the relative complexity between different work items.

This focus on relativism helps turn planning sessions into opportunities for education and debate and allow the team to come up with an estimate every member is comfortable with.

Once again adoption of agile requires a certain amount of truth to be swallowed.

Ideally a team would be able to give a precise time based estimate to aid business planning but this will simply never be the case, there are too many variables.

Agile is also about continual improvement, not just of the code but also of the team.

Pointing provokes debate and provides a metric to be optimised, it recognises the fact that individuals can run into problems or miscalculate but a team is stronger and can flourish into an effective code producing machine.