Can we allocate time to story points?

I am the scrum master, using the following system loosely:

• 0.2 points approx < 1 hour
• 0.5 points approx > 2 hours but < 3 hours
• 1 points approx > 4 hours (half a day)
• 2 points approx > 8 hours (1 day)
• 3 points approx > 16 hours (2 days)

I use the approximations as a guide for how long the task would approximately take. Using this as a guide to work out a weeks worth of work worth is. My sprints are typically 4 days long. So in that case the team the points will add up for the week equivalent approximately.

After tracking my teams progress after 3-4 sprints, I am finding that allocating time against the points is becoming pointless, since the total amount of story points they can complete increases as the weeks go on. Last week it was 6.2 points, this week that figure has increased to 9, typically this varies and I am trying to find the team's average velocity.

Should I measure the teams performance by the average amount of points they can complete in the sprint or attaching time to the points as an approximation.

Thanks

• Story points can be related to time, just not directly. Mike Cohn describes it as a distribution, so 3 points equals e.g. five days with a standard deviation of X. But to get to the point where you can make that approximation, you first need to have run several sprints without thinking about the time conversion. That way your conversion factor will emerge from experience instead of the other way around. scrumalliance.org/community/spotlight/mike-cohn/june-2014/… May 24, 2016 at 23:09
• If we can map points to time directly, what purpose does velocity serve? What is our evidence based feedback loop for the correctness of that mapping if not velocity? May 25, 2016 at 6:41
• You are clearly confusing user stories with tasks. You can estimate tasks in ideal hours if you want, but if you're trying to convert story points to ideal hours you're Doing Agile Estimation Wrong®. May 31, 2016 at 2:34

Story points are an ABSTRACT measurement for the complexity of a product increment. The idea is that complexity is the same for everyone, whereas the effort needed to complete it varies depending on the skills and experience of a developer. So calculating time from story points makes no sense at all to me. As you are already experiencing a rising velocity while working hours remain stable you can see that there is no direct relation between story points and time. And I would not recommend to measure the performance of a team by either time or story points. Instead I recommend to look at work capacity (how much is the team able to successfully complete within a sprint) and at focus (how much of their time is actually invested towards the sprint goal). You will see much better results if you support the team in becoming more agile instead of calculating time from story points.

• "Instead I recommend to look at work capacity (how much is the team able to successfully complete within a sprint) " - how do I measure that? May 24, 2016 at 16:19
• @bobo2000 You are going to want to look at committed story points versus completed story points. Capacity is generally based on points. May 24, 2016 at 19:40
• @bobo2000 here's one method that works really well for me. Simply measure how much got done and how long it took. pm.stackexchange.com/a/18279/21039 May 24, 2016 at 23:40

So there are potentially a number of things going on here.

First off; story points should not directly correlate to hours because they will fluctuate based on a number of factors. After several sprints, you can take the average of the last few sprints to determine the teams velocity and use that to project work going forward. That projection will also end up being an estimate because some work gets done early and other work gets done later.

Having said that, I have a couple of observations / thoughts.

1. My sprints are typically 4 days long.

I think that your sprints are too short to get an accurate read of your teams performance over time. From personal experience I would expect that you would frequently have carryover or be completing stories that are not being tested. I think best practice is for sprints to be no shorter than 1 week and no longer than 4 weeks; and most commonly sprints are 2 weeks.

1. After tracking my teams progress after 3-4 sprints, I am finding that allocating time against the points is becoming pointless, since the total amount of story points they can complete increases as the weeks go on.

The behavior of story point output increasing from sprint to sprint is normal. It will eventually level out after X amount of time. This can be attributed to the forming, storming, norming and performing phases of team growth. Basically, in summary, your team is figuring out how to be efficient while working together.

1. Your story point scale seems off to me. I would consider using Fibonnaci numbers if you must use numbers, or if you can get away with it [Small, Medium, Large, XLarge] or some variation [Efficiency, Apartment, Condo, House, Mansion] that you are comfortable with. In my opinion anything less than 1 point / half day is too small an amount to estimate and if your team is using those points / scale to estimate, they will likely be off because developers are generally over optimistic about how much can get done.
• Did 'Small', 'medium' and 'large' before - it does not get tracked by the burn down chart. Only points do. Also used to do 1 week sprints, didn't go well with the stakeholder so had to do 4 days, all it meant was that I had to allocate 4 days worth of work. May 24, 2016 at 16:50
• @bobo2000 How many devs are on your team / is the work being QA'd before it's marked as done? Why is the stakeholder adamant about 4 day sprints? You could introduce the concept of a mid sprint touchpoint with the stakeholder. May 24, 2016 at 16:53
• @ dmeel yes and yes. He wants 4 days sprints because it is frustrating him that he cannot make change requests i.e. add things into the sprints once the sprint has started. We have 2 developers and 1 QA tester May 25, 2016 at 8:46
• @bobo2000 It sounds like you need to build up your backlog of work. If you already have a backlog containing several sprints worth of work it sounds like your stakeholder really isn't buying into the agile process. If 4 days in a sprint is the way it has to be, I think you will continue to experience a wide fluctuation in avg story points because of the way your stories will have to be written to account for fitting into a 4 day sprint. May 25, 2016 at 12:49
• @bobo2000 have you considered letting him reprioritize mid sprint? I know it sounds insane, but here me out. Your PO wants to reprioritize mid-sprint, so you walk him over to the board and let him. But you have to make a point that he's not going to add something to the sprint without taking something out and he can't take out anything that's already been started. He'll quickly start prioritizing the backlog better if he directly feels the pain he's causing by interrupting the sprint. Also be sure to keep track of changes in capacity relative to the # of changes in priority. May 25, 2016 at 16:12

"Should I measure the teams performance by the average amount of points they can complete in the sprint or attaching time to the points as an approximation."

I think most people attach a time to the points in their head when estimating. However, if you try and measure performance by story points completed you are encouraging over estimation of tasks. I can do a million story point sprint easy. You wont like my estimates though!!!

Forget about 'team performance'. Story points are about estimating how long it will take to complete the project. Take the average per sprint and divide the remaining by that number to get your expected completion date.

The main reason for story points and other abstract measuring systems is to prevent you from thinking in terms of time. If you are going to associate them with time just get rid of story points altogether and go back to man hours.

By attempting to relate points to time you are subverting the whole system.

You can measure time vs points and figure out how they tend to equate and then use a burn down chart to figure out how many points you need to remove to make a delivery date, but that is supposed to be your only control.

You cannot say things like "we need to make this date with these features, and you cannot assign the points to the features.

Much of the original XP stuff was about fixing project management, not project development and the most important points like this one are the ones that have filtered into the offshoots like scrum. Reading some of the original XP stuff can help get a handle on why some of these processes work.