How to measure estimate and story points in Scrum? [closed]

Question

Lets take an example suppose we got 5 stories A,B and C,D,E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

The stories are ordered based on their importance (priority). How do you estimate them? Is it estimated based on the size of the feature? For example I have given them estimate values:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Let's suppose it is a 2-week sprint. This is 14days time size=5,14x5=70 man-days. Now what does the value 10 mean? Does it mean amount of time (hrs or days) a team should spend? And what are story points? Suppose this is the first sprint; how will you estimate the number of sprints when you don't have the last sprint's velocity?

Procedure

more info on #2098057 – Wahoo

I'm voting to close this question as off-topic because it is not about programming. – Mirthless

I'm voting to close this question as off-topic because it belongs on pm.stackexchange.com – Separative

Answer 1

Argh! Serves me right for writing from memory.

A story point is related to the estimate of course, and when you try to figure out how much you can do for a sprint, a story point is one unit of "work" needed to implement part of or a whole feature. One story point could be a day, or an hour, or something in between. I've confused the "estimate" and "story point" below, don't know what I was thinking.

What I originally wrote was "estimates" and "story points". What I meant to write (and edited below) was "story points" and "velocity".

---

Story points and velocity goes hand in hand, and they work together to try to give you a sense of "how much can we complete in a given period of time".

Let's take an example.

Let's say you want to estimate features in hours, so a feature that has an estimate of 4 will take 4 hours to complete, by one person, so you assign such an estimate to all the features. You thus consider that feature, or its "story", worth 4 points when it comes to competing for resources.

Now let's also say you have 4 people on your project, each working a normal 40-hour week, but, due to other things happening around them, like support, talking to marketing, meetings, etc., each person will only be able to work 75% on the actual features, the other 25% will be used on those other tasks.

So each person has 30 hours available each week, which gives you 30*4 = 120 hours total for that week when you count all the 4 people.

Now let's also say you're trying to create a sprint of 3 weeks, which means you have 3*120 hours worth of work you can complete. This is your velocity, how fast you're moving, how many "story points" you can complete.

The unit of your velocity has to he compatible with the unit for your story points. You can't measure stories in "how many cups will the developer(s) consume while implementing this" with "how many hours do we have available".

You then try to find a set of features that together takes close to, but not over, 120 points, ranked by their priority. This would simply be to sum accumulative from the top and downwards until you reach a task that tips the sum over, or equal to, those 120 points. If it tipped it over, don't include the task.

You could just as easily estimate in days, or cups of coffee consumed by the developer, just as the number is representative for the type of job you're doing, and it can be related to the actual work you will perform (ie. how much time you have available).

You should also evaluate your workload after each sprint to figure out if that 75% number is accurate. For instance, if you only managed half of what you set out to do, figure out if your feature estimates was wrong, or if your workload estimates was wrong. Then take what you've learned into account when estimating and planning for the following sprints.

Also note that features should be split up if they become too big. The main reason for this is that bigger estimates have a lot more uncertainty built into them, and you can mitigate that by splitting it up into sub-features and estimating those. The big overall feature then becomes the sum of all the sub-features. It might also give you the ability to split the feature over several people, by assigning different sub-features to different people.

A good rule of thumb is that features that have an estimate over 1 days should probably be split.*

Talented

So if estimates denote the effort to be spent on a task, what do story points denote? – Procedure

Argh, I've messed up the terms :( Let me rewrite – Talented

Thanks for the update :) then again it looks like story points(denote the time required to complete part of the whole feature) mean the same thing as estimate points(effort needed to complete a task) or is it like estimate point is overall point for a feature and for the sub-tasks within a feature will have story points?? – Procedure

Answer 2

Remember that Points are just ROMs(rough order of magnitude) established through the use of "Planning Poker" as a common practice. The first few Sprints are when you start to identify what the points mean to the team and the longer you go the more accurate the team gets.

Plus look to use points that are a bit more spaced out. A practice I've seen and used is to use the fibonacci sequence, it makes sure that you don't have too many 1 point differences.

Also don't forget testers, when pointing a story anyone doing testing needs to weigh in as sometimes a simple development task can cause a large testing effort and if they are true Sprints the idea is to have everything completed as it could be shipped (built, tested and documented). So the estimate of a story is determined by the team not by an individual.

Overcritical

I like the fibonacci idea, never come across that suggestion, but I can see how it might help. – Preform

Commercially available planning poker cards are often in Fibonacci, or something like it... I think the ones I got as a freebie from a consulting group were 1 3 5 8 13 20 40 100, or something like that. Reduces arguing over trivial differences. – Australian

My team used some commercial cards, I had received them at a technical conference. Companies that supply agile training or consulting are usualy willing to give you some with the company brand if you ask them. I have to say the commercial ones were better than the hand written index cards we had been using. – Overcritical

Answer 3

The value 10 is merely a value relative to the other estimates, e.g. it is half as hard as a 20 or slightly more difficult than a 9. There isn't a specific translation of 1 point = x hours of effort is something to point out.

Where I work, we have what we call "epic points" which is how hard is some high level story,e.g. integrate Search into a new website, that will consist of multiple stories to complete and then we estimate hours on each story that is created from breaking down each epic,e.g. just put Search in for support documents on the site. The "epic points" are distributed in a variation of Fibonacci numbers(1,2,3,5,8,13,21,28,35) so that broader, more vague epics merely get a large value, e.g. anything greater than 8, is an indicator that it can be broken down into more easily estimatable stories. It is also worth noting here that where I work we only work 5 days a week and within each sprint a day is lost to meetings like the demo, iteration planning meeting, retrospective and review so there is only 9 days to a sprint. Adding in pair programming for some things, time for fixing bugs and other non-project work like support tickets and it becomes rather hard to say how many hours will be spent by the handful of developers in the sprint.

The first few sprints are where the values start to become more concrete as based on the experience gained, the estimates can become clearer in terms of how to guess the value.

Swaggering

Answer 4

With a new team or project we always start out by assuming a story point is a single "ideal day", and we figure each developer getting around 3.5 ideal days per week, which is how we calculate our likely initial velocity.

Once you've gone through the "planning poker" stage and balanced/compared all your stories, the actual real-world duration of a story point is really unknown - all you really have is a pretty good idea of relative duration, and use your best judgement to come up with a likely velocity.

At least, that's how I do it!

If you are also aiming your story points at being roughly equal to an ideal day, then I'd suggest breaking your stories down into smaller stories, otherwise you're not going to have a good time in planning and tracking iterations.

Preform

then what does estimate points mean?? – Procedure

that's your team's collaborative estimate of relative duration compared to all other stories. The rationale is that humans are crap at estimating actual duration, but we're pretty good at comparison, "X is going to take twice as long as Y". During the planning poker stage, you start comparing your estimates for X,Y with other stories A, B, C and adjust your estimates so that you wind up with the relative duration of each story. – Preform

Answer 5

Good answers all around.

One point I would like to add is that it's not really important what you choose as a base for your points value (hours, ideal days, whatever else). The important is to keep it consistent.

If you do keep it consistent it will allow you to discover "true velocity" of your team. For example lets say you had few iterations:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

And now you are starting iteration 4 and you have the following in the backlog (sorted on priority):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

Now assuming your points estimations are consistent you can be reasonably sure that the team will finish items 1,2 and probably 3 but definitely not 4.

You can apply the same to release backlog to improve your prediction of release date. This is what allows Scrum teams to improve their estimations as they go along.

Maleeny

Answer 6

JB King has the best answer, but no votes which means incorrect information is being propagated and contributing to the generally poor interpretation of scrum. Please see the real answers from one of the people who designed Scrum here:

http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Remember, it's about effort, not complexity.

Now read about and watch a video here:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points

Lune

The link to the video is no longer valid. – An