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?

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.*