We currently allocated story points the following way:

  • 0.5 very simple (approx 0-30 mins)
  • 1 simple (approx half a day)
  • 2 Medium difficulty (couple of days)
  • 3 Hard (3 days)

This works well for us, sometimes though if we are doing infrastructural work - integrations, dev ops, we cannot use the above metric properly because the task is just too big. At which point, my approach is to try to break the user story further to make it easier to estimate it's complexity, but then find that we cannot since the story is the task.

How do you accurately apply story points to very big tasks? thanks

  • 4
    "Have more than 3 points" seems to be the trivial answer. Is there a reason you limit your estimations to 3 days max instead of estimating complexity of a story?
    – nvoigt
    Jul 14, 2017 at 14:56
  • 5
    Don't equate story points to hours. Story points are a measure of both effort and complexity and are only relative to each other. There should not be a mapping from points to hours.
    – Thomas Owens
    Jul 14, 2017 at 15:00
  • We measure the complexity based on the approximate time it will take to do relative to other stories. Since I run weekly sprints, I need to have some idea of how long the user stories are going to take, otherwise you end up getting into a 'how long is a piece of string' situation.
    – bobo2000
    Jul 14, 2017 at 15:01
  • @ThomasOwens they are loosely mapped, an approximation at best. If something takes longer to implement, it is fair to say that it is more complex than other tasks for that particular developer.
    – bobo2000
    Jul 14, 2017 at 15:02
  • 2
    Any mapping should be avoided. Also, effort and complexity are not related to each other.
    – Thomas Owens
    Jul 14, 2017 at 15:37

3 Answers 3



Mapping story points to time is an anti-pattern. If you must do this because your work environment requires it then you have work to do to educate and evangelize agility at your workplace. Q.E.D.

To be successful at agile estimation, make sure that the whole team and the stakeholders within the organization all agree on what your estimating techniques actually measure. Furthermore, be sure to routinely sanity-check the results of your planning techniques to ensure that the iteration time box is being respected!

Story Points Measure Effort

So, what do story points measure? They measure effort. To a lesser extent, they also measure complexity, risk, and uncertainty insofar as those things may influence effort, but the metric itself is only about the level of effort involved in completing a deliverable. For example, in his blog post "Don't Equate Story Points to Hours," Mike Cohn says:

Complexity influences an estimate, but only to the extent the extra complexity affects the effort involved in doing the work. Walking to the one-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain one.

If you're only going through the motions of treating relative-sizing as an unanchored level-of-effort estimate, then stop doing it and just measure time directly. You won't be any more accurate in your planning activities, and in fact may be less so, but at least you won't frustrate everyone by calling a comb a "dinglehopper" as Princess Ariel does in The Little Mermaid.

Measuring Time with Boundaries

Even Mike Cohn admits that story points indirectly measure time, but only indirectly. That's because in agile frameworks like Scrum, we really only care about two time boundaries:

  1. The daily standup. We care about whether coordinated tasks are on track or not, and can use the 1-2 day rule of thumb for tasks to determine whether or not a story is on track or at risk. However, the standup-to-standup timebox is a process control, not a measure of velocity or a benchmark for team accuracy.

  2. The Sprint or iteration size. In the final analysis, all that matters is whether the Sprint Goal can be met. If the goal can't be met within the timebox, then the the level of effort exceeded the team's capacity and the work was improperly planned.

The only essential measure of time within Scrum is whether or not planned work is done or not-done at the end of the Sprint. Ideally, you use your velocity to ensure that the team doesn't take on more work than can be done in a single Sprint and to do release planning, but these measurements are about per-Sprint capacity for work, not directly about time.

Scrum is about using forecasts of team capacity to manage the scope of work to fit into predictable time boxes. It is not about highly accurate task-level time estimates, or about flogging the team to work harder or faster. The key is to develop a predictable cadence!

Sanity-Checking Workloads Using Sprint Boundaries

Okay, so pretend for a minute that you're actually drinking the Kool-Aid. That means that you accept the following a priori:

  • Story points yield better per-Sprint estimates of capacity than "accurately" measuring task time.
  • Scoping work to fit team capacity yields a sustainable cadence that is successful roughly 80% of the time.
  • Measuring success by goals met rather than number of tasks performed is the organization's measure of success.

Given all that, how do you validate your relative sizing? Again, we go back to the key unit of time measurement in Scrum: the Sprint.

Story points are really just an intermediate value to estimate capacity. They work well, but there are other estimation techniques. On of my favorites is TFB/NFC/1, which is a system where you determine if a story or set of stories:

  • fits into a single Sprint (1)
  • is too big to fit into a single Sprint and should be decomposed or refactored (TFB)
  • can't be estimated as-is or with the team's current knowledge (NFC)

You can use this type of technique alongside traditional story points, too. By looking at the Sprint Backlog as a gestalt and determining whether the whole book of work can reliably be done within a single Sprint, great! If your other estimation process yields a backlog that results in a gut check of "too freakin' big" for a single Sprint, or (worse yet) "no frackin' clue," then you should revise the plan until the planned goal and associated work do fit within a single Sprint.

Whether you use use TFB/NFC/1, a gut-check, or another estimation technique isn't what's important. They key strategy is to ensure that the team (and the rest of the organization) respect the time box. Plan only enough work to fit the iteration, and continuously refine your planning and estimation process until you can do that reliably most of the time. That's the essence of agile planning!

  • +1 for the "TFB/NFC/1" concept. Wasn't aware of it and looks pretty useful!
    – Tiago Cardoso
    Apr 15, 2019 at 8:03

I am trying to answer this and considering the comments above.

Story Point to Time Mapping

I understand the desire to map complexity (story points) to time / money (hours / dollars), but as Jeff Sutherland puts it:

Story points give more accurate estimates, they drastically reduce planning time, they more accurately predict release dates, and they help teams improve performance. Hours give worse estimates, introduce large amounts of waste into the system, handicap the Product Owner's release planning, and confuse the team about what process improvements really worked.

Meaning that time estimations are mostly wrong and gives you a false feeling of safety. As @vander-lauriano-da-silva mentions, there are tasks that are very complex (in a way you have think much about it and hard to implement) but may be done in a short time AND there are tasks that are really simple, but take a lot of time to implement. So the mapping is dangerous (@ThomasOwens). Approximate complexity should be "good enough" to work with (@codegnome).

What's above 3SP (Hard)?

If you insist on mapping, I see no problem using 5SP (Very Hard), as @nvoigt also mentioned. But this should be something that can be made in 5 days (= 1 week = sprint duration)!

Splitting Stories

Maybe you re-think the way you cut your stories, to make sure the story is NOT the task. From my experience, Stories greater than 3 can be mostly splitted somehow (of course that depends from team to team).

There are several sources how to do this:

Other ways to split

If your Story is too big, you may also convert it to an Epic and add Stories to them. That may not solve your problem in the first place, but you have Stories fitting into one sprint, without losing the context of the feature.

Sprint duration

You may also think about sprint duration, why does it have to be 1 week? Most teams I know run good with 2 weeks (also reduces the number of Plannings, Reviews and Retrospectives).

"So how do you do your sprint planning for say a weekly sprint?"

I have a look at the velocity (story points / sprint) for the last 3 sprints and estimate how many story point can be "burned" in the next one

Infrastructural / DevOp work

Maybe these links may also help:

  • That is what I have said, my mapping is a 'good enough' approximation based on the skillset of the team doing similar work. I do agree trying to put time onto a task is ridiculous and never works since software tasks require investigation, implementation, testing - how do you measure investigation time?. But if you are dealing with stakeholders you need to do some mapping, my CEO will ask me roughly how long it will take x thing to deliver, since he needs to relay that information back to potential customers for sales. If I say, 'I don't know but the complexity is 3' it isn't going to work.
    – bobo2000
    Jul 15, 2017 at 11:08
  • I think this one of the biggest point for debate when between scrum and business people. I would say: "the complexity for this 3SP and if our velocity will stay stable and we priorize it on top of our backlog, it may be approx. done within the next sprint." - knowing that this is not an all to satisfying answer. But if you say: "This task will take 3 days" but needs 5 or more days at the end, there will be more frustration on the business side, as they might take this statement as a fact.
    – ppasler
    Jul 15, 2017 at 11:17
  • Looks like we are on the same page...When dealing with my stakeholder, I normally tell him that it will take x amount of sprints relative to the complexity of the task. But I can't make the statement it is going to take 1 sprint instead of 2 (7 or 14 days respectively) if I am not certain that 5 or 14 days reflects the amount of effort needed to do y task. It is harder to evaluate this when you are working on dev ops tasks or infrastructural than say a less complex feature using Javascript from experience.
    – bobo2000
    Jul 15, 2017 at 12:02
  • So the key is, for normal (well known) tasks, your way of estimating works fine. Your problem are dev ops tasks that aren't usually done and have a lot of uncertainty. Could you give some examples which tasks are meant and what happend in the past?
    – ppasler
    Jul 16, 2017 at 17:53
  • Basically yeah, a good example is right now where the task is to add an additional production server to the stack. We have to create a stack script to do this, but that alone takes 2 sprints. I do not know how many points to allocate it, and it cannot be broken down further. It is literally a task.
    – bobo2000
    Jul 17, 2017 at 14:55

Just a thought if anyone wants to build it... Median hours * inverse scale probability range multiplier N hr with d/d average deviation (not standard). On entering N and d a range calculator will write it in english for confirmation. Where the d is the distribution range half the time because half is simplest. e.g. 1hr *3/3 (3 hours to 20 minutes, normally 1 hour) or 1hr *1.5/1.5 (1.5 hrs to 40 minutes, median 1) Then give the lowest bidders first option to prove their estimation correct delegating the task. Thus, the delegator, not the performer, is the one judged. Most will delegate to themselves or those they trust. This will require partner programming for skill sharing. Anyone refusing to do a task should say so, before estimations are given. A gamma distribution is a maximum entropy probability distribution with an inverse scale rate parameter. Complexity distributes entropy. So they need to guess at the median (not average) and the inverse scale probability deviation (not +/- time). This is then subject to a chi squared test over repeated trials for accuracy which can feed back as a trending accuracy multiplier. This also provides more accurate burn down charts as the predicted variance can be displayed and also burn down. Individual chi squared progress (predicted time taken minus the actual time taken, squared, then divided by actual time) can also be trended as experience will tend to a norm. https://en.wikipedia.org/wiki/Gamma_distribution#Median_calculation

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.