Having used "days" as the unit for estimation of tasks in Scrum I find it hard to change to using Story Points. I believe story points should be used as they are more comparable to each other - being less dependent on the qualifications of whoever addresses the task etc. However, it isn't easy to make a team start using Story Points when they're used to estimating in days.

So, how to make a team change to Story Points? What should motivate the team members to do so, and how should we apply the switch?

  • 1
    Are you sure you mean estimating tasks? My experience indicates that estimating Product Backlog Items (User Stories, if you use them) is done with Story Points and Tasks are estimated in hours (and often required to be 8 hours or less to ensure we have thought the tasks through) May 2, 2014 at 8:25

2 Answers 2


What should motivate the team members to make the switch to Story Points?

Are the team good at estimating using days? Do they accurately predict what how long a task will take in elapsed time? If so, then keep using days!

If not, then what is the point in calling them days? If they aren't accurate then it is kind of meaningless.

how to make a team change to Story Points?

Adopting story points is easy if the team is sufficiently motivated. Just make the switch, start doing the process.

If you want to make a more gradual transition, as an intermediate step between days and story points, you could try using Ideal Man days.

The team try to predict the relative effort required to implement a story. One ideal man day, is the work you can get done, in one day, with no distractions, email, interruptions or unpredictable problems.

There are a number of drawbacks with Ideal Man Days. The biggest being the idea that it is possible to achieve this perfect day. It can be used as a stick to beat the team, for example, with management saying that, "0.3 Ideal Man Days isn't enough!", and, "you need to take away distractions so that they can achieve this Ideal Day".

In theory, using Ideal Man Days, requires more prediction than Story Points, because it means you have to extrapolate ahead. Whereas, Story Points should be estimated based on the complexity that you see. However, in practice, Stories can also have hidden complexity that is not discovered until you attempt to implement them.

Story Points are usually assigned by grouping stories of similar complexity together. The point value is supposed to be proportional to effort required to complete a story.

You can use a very similar process for estimating with Ideal Man days. Take examples, preferably from completed stories as benchmarks for each estimate then group the new stories.

Do a second pass over the stories to ensure that their complexity is relative to each other, that is a 1 Ideal Day Story is half as complex as a Two Ideal Man Day story.

When you're estimating your stories relative to each other and checking their relative complexities, it is just a name change from Ideal Man day to Story Points.


Excellent answer from Dave; I would like to add, from my personal experience, how you might be able to start to do the switch.

  1. Get one or two medium sized, but well specified and clear user story
  2. Set them to a medium value (e.g. in the classical scheme at about 8 story points)
  3. Estimate the other user stories relative to above values

Personally, I don't like the approach of using ideal person (not man :) days. You add another uncertainty to the estimation process.

In my experience, with a new project and motivated team, the advantages will become clear soon enough: Estimation gets easier and people commit, in the end, to a sprint goal (e.g. 90 story points) and not to single story estimates in days.

Assuming that the people are still reporting real time on the stories or their subtasks, it helps to calculate after 4 or 5 sprints how many hours are in a story point. Not to attach a number to a story point, but to analyze deviations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.