Estimating tasks using points

Question

I recently started working in an environment where task estimation is done using points. I failed to find any resources that underline the benefits of this process so I must turn to SO community to figure out what they are. If any of you have worked in a Scrum environment that uses points to estimate tasks, what are the main benefits over using hours?

Answer 1

tl;dr The difference in naming is semantic, it's to help you think about estimates differently/properly.

When I worked on a Scrum team, the Scrum Master explained to me, that the point of points (pun intended) was that they are supposed to be an indicator of scale of the problem. If do your estimates in terms of time, then (non-technical people, PHBs especially) people will start thinking of your estimates as deadlines. If an admin page is estimated at 32 hours, those kinds of people will want "just" that page by the end of the week... despite the fact that it depends on other behind-the-scenes stuff which may take a 100 hours and might be part of a separate task or even story. Also, you could be wrong (and probably are) so it's important to think of these are scale indicators rather than how long it will take.

Answer 2

Scrum doesn't specify how you estimate the remaining work of a sprints plan. Sounds like you're using tasks to create your plan. Some teams I've been part of successfully used the number of tasks as their sum of remaining work. Some used hours. Some teams simply use the remaining number of Product Backlog Item story points as the measure of what's remaining.

I have not worked with teams that estimate Tasks and Stories (PBIs) with points, but if they've come to understand the difference in economies I imagine it can work for them.

Answer 3

One of the tenets of Agile is feedback: measure and adapt. The benefit of using points over hour is that it's much easier to answer the question "is this task twice as big as this other", rather than "how long will it take the team to deliver that task", especially in the beginning of a project. As the project progresses, you observe how many points get shipped per unit of time, and you can easily determine if tasks can be done in a certain timeframe. In essence, this is equivalent at that point to estimating hours, but the estimates are based on the observed past of the team, including all the intangible factors that make estimation difficult (do people work well together, non coding activities that eat time) - and you avoid "time haggling".

Answer 4

Estimation in Scrum is a critical aspect to understand and do effectively. It's very common for engineers (especially) to have come from more traditional estimation practices that are based in hours. And we all know just how error prone these have been historically.

The premise behind points is that they are an estimate of the relative weight (basically, effort) of one story compared to another. So if I say a particular story is weighted as a "2", and another story is weighted as a "5", I'm really saying that story #2 is roughly twice the size of story #1. It turns out that humans are extremely well adapted to comparing items against each other - "this is bigger than that", "this is a lot bigger than that", etc. We're not so good at assigning absolutes - "this is exactly 3 cubic meters in size". Thus why assigning arbitrary #'s of hours to work items has typically yielded very poor results in practices.

Where points come into play is in the velocity for a sprint. This is simply a measure of how many points a group of people have typically completed in a given block of time, usually 2 - 4 weeks. After a short number of sprints and assuming the team members stay together, the velocity tends to stabilize regardless of what types of stories the team is working on. However, it's critical that the team members create the point estimates themselves and not a Scrum Master, Manager or other non-team member. Otherwise the whole process breaks down and sprints will likely fail.

Points are also a reflection of the complexity of a story. The farther you move up the points spectrum to say, 20, 40, etc, the more risky and complex that story really is for that team. So although you could say that a story of size 20 is roughly 4 times the size of a 5 pt story, it's also true that a 20 pt story may in reality be really 25 or 30 points in size; the complexity and scope of the story is leading to an estimate that is likely less reliable. So typically a team will work with the Product Owner to size stories at a 2-5 point size where possible; not too big, not too small.

Finally, as a team becomes more skilled with Scrum, it's possible to begin to perform projections into the future of when a suite of stories, typically called an epic, would be completed. This gets to setting target dates for products or features. If a set of stories is estimated in points by a team, and that team's velocity has stabilized, you can project out the # of sprints it will likely take to complete the work assuming no further changes to the backlog. I do this with my teams on several projects from new products to maintenance releases and it can be quite accurate, far more accurate than when we relied on hours in the pre-Scrum days.

The benefit in moving to points from hours can be summed up thus:

• Estimating in points is faster.
• Estimating in points is more accurate.
• Estimating in points is easier.