How to change to use Story Points for estimations in Scrum [closed]

Question

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?

Cobden

See #414846, and all of these: stackoverflow.com/search?q=[agile]+estimate – Junk

Answer 1

If you want to change to using story points instead of duration, you just got to start estimating in story points. (I'm assuming here you have the authority to make that decision for your team.)

Pick a scale, could be small, medium, large could be fibonacci sequence, could be 1 to 5, whatever pick one and use it for several sprints this will give you your velocity. If you start changing the scale from one to the other then velocity between scales is not going to be comparable (ie dont do it). These estimates should involve all your Scrum team.

Having said that you still need an idea of how much this is going to cost you. There arent many accountants who will accept the answer "I'll tell you how much this is going to cost in 6 months". So you still need to estimate the project in duration as well, this will give you the cost. This estimate is probably going to be done by a senior person on the team

Then every month your velocity will tell you and the accountants how accurate that first cost estimate was and you can adapt accordingly.

Supraorbital

Answer 2

When I switched to points, I decided to it only if I could meet the two following points; 1) find and argument that justify the switch and that will convince the team 2) Find an easy method to use it.

Convincing

It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.

This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.

Putting Points in the Backlog

This step is done with the participation of the entire scrum team.

Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.

Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.

NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.

That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.

Velocity & Estimation

To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.

That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value

Garfieldgarfinkel

If you need more info on the process, I'll answer any question – Garfieldgarfinkel

Answer 3

Start by making one day equal one point (or some strict ratio). It is a good way to get started. After a couple of sprints you can start encouraging them to use more relative points (ie. how big is this compared to that thing).

Visitation

Answer 4

The problem is that story points define effort.

Days are duration.

The two have an almost random relationship. duration = f ( effort ). That function is based on the skill of the person actually doing the work.

A person knows how long they will take to do the work. That's duration. In days.

They don't know this abstract 'effort' thing. They don't know how long a hypothetical person of average skills will require to do it.

The best you can do is both -- story points (effort) and days (duration).

You can't replace one with the other. If you try to use only effort, then you'll eventually need to get to days for planning purposes. You'll have to apply a person to the story points and compute a duration from the effort.

Junk

Yes, but you need a way into estimating effort, and duration is a good first approximation. The trick is to use it to bootstrap and then move away from it. See "Agile Estimating and Planning" by Mike Cohn which describes this technique. Also velocity (Story Points/Time) gives you a way of measuring duration which averages this over the team. Over time velocity becomes very stable and can be used to plan fairly accurately. – Visitation

Pragmatically, you still need both. The ratio of duration to effort, even assuming a very stable team, isn't simple or linear. Further, the "very stable team" assumption is rarely satisfied in practice. It isn't clear what the "velocity" estimation is. Is it a duration used to trim down the effort into something deliverable? Is it effort used to drive toward an expected duration based on current team composition? It seems to be both: effort and duration mushed together. – Junk

You get duration from velocity, the rate at which your team can implement functionality. But this begs the question: why do you need to know duration? Is it for sprint planning? Then you don't need duration, you need effort because you can derive velocity from effort and sprint work is measured in terms of velocity (points per sprint). Is it for release planning? Then you can derive duration from velocity; the release will take (Total Points / Velocity) sprints times the length of a sprint (+/- for the Cone of Uncertainty that will narrow as you progress). – Recurved