Scrum estimation unit [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

My team estimate tasks with hours, which is related to the TFS SCRUM Template nomenclature, however I've heard recently that tasks should be estimated in some abstration unit and using of hours is evil, what is the recommended way?

Answer 1

You can estimate in hours provided your team velocity is also based on hours since that's how you decide how many backlog items are likely to be delivered in a sprint.

But it's not necessary to use hours and it can sometimes give a false sense of exactness.

If you use an abstract unit for both estimating and velocity, you (or, more correctly, stakeholders and others who don't understand Agile) won't be confused into thinking that hours is an exact measure.

The confusion will stem from the fact that velocity is work-units-per-sprint and "hours-per-sprint" will be unchanging if your sprints are always a fixed size (say, four weeks for example, which will always be expected to be four weeks by forty hours by some number of workers).

However, your velocity is actually expected to change over time as the team becomes more adept, or experienced people get replaced with those with less experience, or half the team takes a month off on holidays.

That's why the whole concept of story points exists. They provide such an abstract measure so as to avoid this confusion. You simply estimate your backlog items in story points and keep a record of how many points the team delivers each sprint (the velocity).