7 ms·

Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers).

• ozim 2y ago
  I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points <> time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".
  • throw310822 2y ago
    If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.
    • ozim 2y ago
      That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time". *Properties of Whole Numbers: Whole numbers are closed under addition and multiplication. Zero is the additive identity element of the whole numbers. 1 is the multiplicative identity element. It obeys the commutative and associative property of addition and multiplication. It satisfies the distributive property of multiplication over addition and vice versa. *
      • recursive 2y ago
        Why use a measure that creates this footgun? Why should our task estimation require this much abstract thinking? Why not invent the measure so that it's not misleading? Numbers generally have well-understood properties. Using them in a way where the properties don't apply is asking to be misunderstood.
      • Viliam1234 2y ago
        And this is how the entire math gets done in 5 simple JIRA tasks. :D
    • 1xdevnet 2y ago
      I like this, I'd advocate for a fruit-based task system - although I suppose the exact fruit ranking would depend on the team. - easy peasy: lemon - easy but needs careful handling: kiwi - regular but boring: red delicious - regular, who wouldn't want to take one of these?: mango - large task, risk of splash damage if mishandled: watermelon - tough to crack, needs time or a hammer: coconut - technically we'll do this, but not really our job: tomato Edit: I am sad that emojis aren't allowed in comments, though it's understandable.
    • icedchai 2y ago
      If you try this (and I have, just not with fruits), someone will complain they can't graph fruits. You'll tell them that's the point. They won't listen, so they'll map fruits to numbers, and now you have the same problem anyway. My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most.
      • wolpoli 2y ago
        > My personal preference is to use time estimates with some uncertainty. A day or less. 2-3 days. A week at most. In the project management world, there is an assumption that tasks that are overestimated and underestimated would even themselves out so that the total estimate would equal the actual time needed. Sad to say that accuracy of estimates don't follow normal distribution in software development.
        • SoftTalker 2y ago
          I had one manager who used time in orders of magnitude. He’d ask, “is it a day, a week, a month, or a year?”
          • jon-wood 2y ago
            I've done exactly this in the past, and then when someone asks how long the project as a whole is going to take it's easy enough to give a range. If someone says a task is going to take hours that's a range of 1-6 hours, if they say it's months that's 1-12 months. If you want more certainty in your estimate then you're going to have to give us some time to break things down.
    • vannevar 2y ago
      Just because they're not time, doesn't mean you don't want to add them. Imagine you have an empty basket, and you're not sure how much fruit you can toss in it. So the first time, you just start tossing stuff in until it's full. The exact number of lemons, coconuts, etc will vary. But after a few rounds, you'll get a feel for how much of each you can get into the basket. That's story points. You feel your way into a groove where the team gets a more concrete sense about how much it can get done in a sprint, given the variability of the work, external projects/distractions, and the makeup of the team. Story points get a bad rap because a lot of engineering managers don't get scrum and just see a convenient way to measure productivity. Which story points are absolutely not meant to do, outside of the team itself setting its own sprint goals.
      • tsimionescu 2y ago
        My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. There's no way to say in reality "this task is small" unless you have some idea of how long it takes. Additonally, this concept of velocity makes no sense because a task that's big for me might be small for someone else in the team, so then we either pre-assign tasks and set points based on assignment (and then have problems if we switch the assignee for any reason), or we assign "generic points" and that ends up not meaning anything at all if the team is not very uniform (e.g. all seniors with similar skills and ownership of most of the same code, or all juniors). Additonally, all methodologies tend to discourage correcting point values after the fact. That makes the process of deriving time estimates (velocity) even more error prone, because it conflates uncertainty with mistakes. That is, you can correctly estimate a task at 8 points and finish it in four weeks; or you can incorrectly estimate a task as 3 points and finish it in 4 weeks. That doesn't mean that the team has a velocity of about 1.35 points/week, it means it has a velocity of about 2 points/week, but made a mistake with one task.
        • vannevar 2y ago
          >My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. So when you shop for clothes, Small/Medium/Large are useless? You require precise measurements for every item, and they have to be exactly the same size across manufacturers, or else sizes have no utility for you? The reality is that a Large can be large on you in different ways, even if it's a t-shirt. And software complexity has a lot more dimensions than a t-shirt. The utility of story points is that they allow a team to create a rough idea of their capacity over a sprint, so that they don't consistently under- (or more commonly) over-commit. If you try to use story points purely as a uniform proxy for time, of course they're going to be useless, because you can always just use time instead.
    • candiddevmike 2y ago
      I use Halo difficulty levels: Easy, Normal, Heroic, Legendary.
  • wewtyflakes 2y ago
    Ultimately, we are bound by time, not complexity. Why does it matter how complex a task is? The product managers and customers wont care how hard we as engineers have to think or reason about a problem; to them, the only thing that matters is time until delivery.
    • robertlagrant 2y ago
      Story points aren't useful outside the team. They're for the team to help it figure out roughly how much stuff it can do each sprint. They shouldn't leak out of the team.
      • throw310822 2y ago
        A sprint is a unit of time, how does measuring a "complexity"- whatever that is- helps in figuring out how much stuff you can put in *time*?
        • robertlagrant 2y ago
          I understand what you're saying - of course in some sense they're convertable. But the point is to not think about time when estimating, because if you estimate time you don't factor in things like other tasks, or holiday, or anything else. Or if you do you have to spend ages trying to account perfectly for time. Instead, if you estimate complexity (e.g. I think this task is a 3, just as a starting point, then this task is roughly the same, so it's also a 3, then this one is similar but will take almost as much testing due to its difficulty, so we'll call it a 5, then this one is very simple, not even half as difficult as the first one, so it's a 1, etc), then try and keep that up for a few sprints, then figure out how many points fit into a sprint, you automatically factor in other factors (like "I have to log into Okta ten times a day", or "people keep getting pulled into meetings") through practical observation of what got done, and you get better at predicting what you'll be able to achieve in a sprint. It's not perfect; it just removes the need for certain entire jobs devoted to accounting for time, which you can spend on another developer instead, while also being a reasonable measure of what you'll get done, and only takes about an hour every two weeks.
  • recursive 2y ago
    I continue to treat story points as a measure of time, despite being told repeatedly they're definitely not time. I will continue doing this until someone can explain to me, in a way I can understand, what they actually are that is not time.
    • pests 2y ago
      Difficulty level? You can't promise you can beat a game on hard 2x as fast as you can on normal, or 3x as easy.
      • recursive 2y ago
        Estimates never represented a promise in the first place. If you have someone who is holding you to your estimates, you have to address that. Regarding difficulty, easy things aren't even expected to be faster than hard things. I'd rate a backflip as much harder than counting to 100,000, even though it wouldn't take nearly as long.
    • JohnFen 2y ago
      Because in the end, they are a proxy for time. We can call them "complexity" or whatever, but that doesn't help much with planning a time-boxed period of activity. So they end up meaning "time".
    • steelframe 2y ago
      The identity of story points depends on what information you have. If you don't know your team's velocity then story points are only relative complexity. Once you have your team's velocity you can use that information to convert to time.
      • tsimionescu 2y ago
        What is relative complexity? How can you compare the complexity of <changing the colors of one button> with <implementing a sorting algorithm>, other than by how long they might take?
  • pizzafeelsright 2y ago
    Points are almost worthless as they can be gamed. We're judged on delivery. Measured by time. Complexity is arbitrary. If points aren't time bound why am I limited on the amount of points I can take? Every team had a max point load. If there's no stick for rollovers then you're Kanban.
• xboxnolifes 2y ago
  Yeah, it seems like it's fairly common for people/teams to follow the idea that any story that is 8 or more points should be broken down to tasks of 5 or less. This simply doesn't make sense to me. If the most simple task is 1 point, is your most complex task allowed really only 5 times as complex? Story points usually follow an exponential increase for a reason, enforcing staying in the mostly linear portion is just pretending the complexity and uncertainty has been decreased.
  • IanCal 2y ago
    The idea is that if a task is that large can you really not break it down into smaller steps? Do we understand the problem well enough to implement or are we hand waving over likely areas of complexity? Maybe if you tried to break it down you'd realise that the 21 point card is actually more like 10+ 5 points tasks and you had just though "big" not "I know what needs to be done and can size this accurately". Doesn't mean these cases never occur but it's worth seeing if it's actually smaller related pieces of work.
    • brightball 2y ago
      > Do we understand the problem well enough to implement or are we hand waving over likely areas of complexity? Nailed it. That is exactly the right question to ask.
    • xboxnolifes 2y ago
      > Maybe if you tried to break it down you'd realise that the 21 point card is actually more like 10+ 5 points tasks It didn't even occur to me think of it this way, because the times I've been exposed to breaking down tasks the total number of points stayed constant. 13 pointers becoming an 8 and a 5, and the 8 pointer becoming a 5 and a 3.
• danparsonson 2y ago
  > Story points aren't time... > ...burndown chart... The x-axis of a burndown chart is time, right? So if you create a chart that measures points/time then you encourage the idea that a certain number of points can/should be completed in a day, ergo that points are a proxy for units of time. Otherwise what's the point in the chart?
  • drewcoo 2y ago
    If you're measuring foo/time, then foo is probably not time. Unless you're measuring some kind of acceleration. Charts are supposed to be pretty and reassuring and go up and to the right. That keeps the managers happy!
• klysm 2y ago
  The use of the Fibonacci sequence is so pseudo-intellectual. It's completely arbitrary, but use of the Fibonacci sequence makes it sound smarter or justified somehow.
• deleted 2y ago
  [deleted]
• SoftTalker 2y ago
  I haven't done story points estimating in years, but at the time, an 8 was rarely acceptable, a 13 surely was not. Estimates that high were basically saying "this story is too big or too poorly defined to estimate accurately" and we'd try to break it down into several stories of 5 points or less. The vast majority of our stories were 2, 3, or 5 points.
  • Too 2y ago
    Now you are doing exactly the same mistake the article starts out with. Comparing story points outside your own team, of which you have zero context about how much 8 point represents. How big your points are make no sense at all outside your own team. It is a relative measurement. 8 could mean 8 lines of code, 8 rest endpoints, 8 database columns or 8 interviews with customers. It certainly should not mean 8 days.
    • IanCal 2y ago
      Not really. The point there is the granularity. If 8 points to you is fixing a minor spelling mistake in your docs, what value is there in having anything smaller than 8? If 1 is "build the entire backend" then how can you represent anything smaller?
      • siva7 2y ago
        You're just proving their point
    • deleted 2y ago
      [deleted]
    • SoftTalker 2y ago
      I guess I am, but the point I was trying to make is that there was a fairly small number of point values that we were fairly confident in, and above that it was quickly into the "we can't even take a guess" territory. Correct that the absolute point values aren't relevant, but it would seem odd to me with Fibonacci increments that teams would find values such as 13, 21, or higher to really be useful unless they put a lot of research into their number. For us, it was "read the story card, and give your estimate" so it was entirely a gut feel sort of thing. And yes, when you really boiled it down (though rarely admitted), for most people 1 point = 1 day. So anything over 5 was unlikely to get done in a week, therefore it needed to be broken down as we ran one week sprints. I'm not endorsing any of that, by the way. I thought planning poker was pretty arbitrary, but it was the gospel and not to be questioned.