BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Do Story Points Relate to Complexity or Time?

Do Story Points Relate to Complexity or Time?

This item in japanese

Bookmarks

Many Agile teams use the terms Story points and Complexity points interchangeably. Agile teams believe that they are better than hours just because they are based on complexity and relative size. Mike Cohn suggested that it is wrong to use story points to depict the complexity of developing a feature, they are all about the effort.

Mike mentioned,

I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it’s wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.

Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

In a similar discussion on the Scrum Development group, Adam Sroka mentioned that in order to have a stable enough measure for velocity, teams need something which is close to time. Likewise, stories should correlate to relative effort and effort is comparable to time.

This however does not mean that teams should start estimating in hours. Estimating in hours has been found to be wasteful and inaccurate by many. Mark Levison commented,

Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.

Jeff Sutherland too, strongly supported story points as compared to estimation in hours. According to Jeff

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

Mark Kilby commented to make sure that people new to Agile do not assume that Story points = effort = hours. According to Mark while making a decision on the story point, though effort is important, however enough consideration must also be placed on uncertainty. Mike agreed that there is no equivalence relationship between points and hours.

Mike furher added,

Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.

Thus, story points should be based on effort and the effort should be able to take into consideration factors like risk, complexity, doubt etc. The key is to realize the question that story points help in answering. As Mike put it,

The goal of estimating is to answer questions such as “When will you be done?” or “How much functionality can we have by the given date?” If that is true, then whatever unit we estimate in and whatever approach we use will need to be about time.

Follow the discussion thread on Mike's post.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Duration is the not the same as effort

    by Kevlin Henney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There seems be further confusion added by saying that story points are an indication of effort, while still assuming that they are an abstraction of duration. Effort and duration are not the same thing. Watching an episode of Battlestar Galactica and running a 10km race take comparable time, but the former takes a lot less effort than the latter (even for non-BSG fans).

    It also pays not to confuse the idea of duration with risk and uncertainty. And furthermore, not to confuse risk with uncertainty: risk relates to exposure to uncertainty. At the start of the World Cup it was not certain who would make the semi-finals. As I placed no bets, I had no risk. Had I bet any money on an outcome, my risk would have increased, but the uncertainty would have remained the same.

    The effect that risk has on estimate is that it skews the probability of an outcome. In other words, risk is something that affects viability and schedule and in a way that may not be easily anticipated, in a way that does not respect a normal distribution and certainly not in a way that should be confused or conflated with a single value that is used to represent a mean/mode/median/... estimate of either duration or effort.

  • Do Story Points Relate to Complexity or Time?

    by Bill Leech,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So if Story Points are about time and since most companies/projects need to estimate the time/features/resourcing questions, why not just estimate in hours. The hours will be less accurate for stories that are not articulated, so the complexity, unknown, and risk should all play a role in the given estimate. The benefits in estimating in hours is you don't side-step the major question of "How long it is going to take?" and you can determine for your company/department/team the accuracy of estimates in the early, middle, and late (ie, Sprint) stages.

    Story Points are cute, but don't tackle the sticky question of time. Mature organizations know that early estimates are going to be a rough. Of course the beauty of Agile is that the features of most business value will be completed first and that through regular discussions/communications, adjustments in stories and estimates will be regularly redefined.

  • good point but bad example

    by Felipe Cruz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

    In my opinion, this is a bad example.. A doctor knows exactly what to do on a brain surgery.. software development is much more about creativity than medical procedures..

    Thus, story points should be based on effort and the effort should be able to take into consideration factors like risk, complexity, doubt etc. The key is to realize the question that story points help in answering. As Mike put it,

    Perfect..

  • Re: Do Story Points Relate to Complexity or Time?

    by Greg Willits,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think there's a meaningful difference between saying stories should be estimated in hours and stories should be estimated in time.

    IMO stories should be estimated in an escalating scale of time, but not in hours. The entire conversation in the article is a delicate dance of trying to say that story estimates should correlated to time, and yet trying very hard to avoid hours. After all the fancy "effort" dancing, I think people just need to admit story estimations are about time. Period. Like someone said, it all comes down to _when_ can I have these features.

    Estimates in hours is dangerous. Some of the comments hinted at why. The tendency of people to waste too much time debating details. That's because the unit of time is much too fine for the purpose, and has no flexibility to deal with the valid concerns of uncertainty, effort, etc.

    A comparable example: How many minutes will it take to walk to the nearest street corner? How many minutes to drive across town? How many minutes to drive across the state? You don't get to specify a range, only a single integer answer. The problem with these questions is that minutes is too fine a unit for the latter two.

    What makes the most sense to me is that we make estimations in time, and we still use points, but in an escalating scale that corresponds directly to known times not vague effort. I like to use the following scale:

    1 = < 2 hrs
    2 = < 1 day
    3 = 2-3 days
    4 = 3-5 days
    5 = 5-10 days (potentially the whole iteration)

    The correletion to time ranges gets rid of the debate about whether the estimate is 12 hours or 16 hours. It eliminates the false sense of specificity so managers can't say "we have a total 365 hours of work to do," and it still allows the whole estimation system to perform it's job of defining what 3 points really means based on previous iterations.

    For me this method gives devs the wiggle room they need in estimations, allows us to abstract stories in points, and yet has clear correlations to real time.

  • Compexity Drives Effort

    by Dan Bergh Johnsson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I do agree that Effort is the interesting parameter to track (and estimate)

    However, the effort for "thousand stamps" is probably not 1000 times licking one stamp. Rather it is the effort of building a stamp-licking machine - and that effort depends directly on how complex that machine need to be.

    In software it is the complexity (essential or accidental) that is the major drive of how much effort we need to put in to solve the problem.

    So, yes - it is Effort that is interesting, but complexity drives that effort.

    Elaborated this in a post.

  • Re: Do Story Points Relate to Complexity or Time?

    by Imran Bohoran,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    IMHO the direct answer to the question on this post is No. That's because Story Points are relate to (Complexity & Effort & Risk) (as Mike Cohn as commented on the matter). When assigning points to a story, we like to relate it to some unit of measure (time in most cases and as suggested by previous comments). As much as this is desirable, I think its difficult to think of a UOM because it doesn't give a fair representation to its purpose. A size IMO should take into consideration how long it feels like it takes to implement it, how much of testing needs to be done, what kind of complexities (functional and non-functional) and uncertainties it has and what kind of risks it pose. Thinking about each of these, and picking a number from the fibonaci series (which has a good spread) has worked out well for us so far. But what's important is that, points on stories needs to be relative. So we've ended up revisiting stories after one pass of sizing to ensure that the stories represent points on a relative manner. And this (if possible) should be done across previous iterations as well. At first this can be confusing, but when you have other stories to compare, it becomes a bit easy.

    These relative story points, and a calculated velocity of the team (based on previous iterations) help resolve situations where quick estimations need to be provided. Which then helps the business to plan early and accordingly as well.

    I still feel that the estimation in hours is useful. But done as a seperate excersise from sizing. Tracking estimates against actuals does give a good basis for decission making in future work. I feel an estimate in hours is not useful if actuals are not captured. An estimate is an estimate after all. With actuals in the picture we can make good use of the estimates in future iterations on planning decissions. The seperate excersise of estimation I feel is best fit during the initial designs a team would do on different stories. These are not fully-fledged documented UML based designs. These would be few white-board or scratch-pad sessions. But you can come up with a basic list of tasks based on this initial design. An estimation on these tasks is helpful for tracking purposes. They do present the figure of "X amount of hours of work to do". As much as this not being "accurate", it does present an indication of how the work is flowing.

  • Re: Do Story Points Relate to Complexity or Time?

    by Assaf Stone,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The reason that estimating in hours (as opposed to story points) is twofold.
    First, though managers ask for estimates of the time it will take to implement each feature in a list, 9 times out of 10, what they really need to know is either how long will it take to implement the entire list of features, or, how many of features on this list can you implement in time for the release. It is worth trying to dig for the root-cause of the question; Managers come down with a bad case of "angry monkeys" as often as anybody.

    Second, concrete estimates in hours are based on individual experiences; The same task may take a less experienced developer twice the time it would take me, while a guru on the subject at hand might do it four times faster than me. This means that when you estimate and commit in hours, you are really also deciding who will develop the feature! More often than not, you are actually committing to an impossible schedule, because you implicitly built a Gantt chart with tasks assigned to individual developers - a project plan that you didn't even verify is feasible!
    Story points on the other hand are relative, not concrete, so it is more likely that a senior and junior developer can agree on the estimate that one task is twice as difficult than the next, even if the same tasks will take four times more for the junior to develop.
    The team then, as a whole can commit to the amount of SPs that they empirically proved to be capable of handling.

    Hope this helps,
    Assaf.

  • Re: good point but bad example

    by Daryl Antony,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I feel that example is completely ridiculous and stupid.

    I think the point of using complexity points is to build up a calibration of understanding between the developer team about what is more or less complex.

    We then use time recorded data; to build the case for 'how long it takes to achieve complexity X'

    Obviously we're not going to have Brain Surgeons and Stamp Lickers on the same development team; so what's the god damn point?

    The Complexity metric _does_ get very interesting if we combine Brain Surgeons; as a means of a collaborated effort to analyse the complexity of brain surgery procedures.

    They can then ask insightful questions like: "how long did it take us to do this surgery procedure before? given that the sets of circumstances are somewhat similar?"

    Isn't that the point?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT