4 ms·

What? My company recently added it to help us measure % of time on bugs vs features, and by section of the code base. This is a very very big assumption to make

What? My company recently added it to help us measure % of time on bugs vs features, and by section of the code base. This is a very very big assumption to make.

falcor84 5y ago
You can do that with story points rather than hours
- pc86 5y ago
  Not if you want it to be accurate.
  - happytoexplain 5y ago
    In my experience, points are more accurate than hours, since most people work with high variability in productivity over time that can't be captured by a mechanism as crude as a stopwatch, so a corollary metric creates a more accurate number than an absolute metric.
    - pc86 5y ago
      We're also talking about measurement after the fact. "How many points did you spend on that story last week?" is not something anyone is going to accurately answer (and it doesn't mean anything, anyway).
      - brianwawok 5y ago
        Yah exactly. A scrum master will also say never try to equate points to hours, its a losing game. But being able to look back in May and say we logged 32% of all development hours on bugs is a very useful metric for me the business owner / dev lead. (In addition we don't do story points on bugs. I am so far away from the by the book agile thing, I don't even know if this is correct or not anymore).
    - xtracto 5y ago
      https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch... Time based software development estimates before the magical "story points" system was in vogue.
      - brianwawok 5y ago
        It’s also more useful when looking back IMO. Points are more meant to be a soft guess for going forward.
- Jenk 5y ago
  Story points are not a tool for duration, they are a tool for relative estimation and should never be converted to time in any capacity. _Especially_ not inter-team. This is the current biggest mistake in the industry, imo.
  - SAI_Peregrinus 5y ago
    I agree, but I'd say story points are themselves a mistake. In the end, what matters is time. Story points don't matter if the schedule slips. So you either get story points and no way to keep a schedule, or story points + time estimates (with useless story points), or just go with time estimates. The schedule may still slip, since estimating time is very difficult, but at least some of the time it will be correct (or estimates will get padded until things happen on time). Either way, it's more useful than giving up on the problem.
    - Jenk 5y ago
      The entire purpose of introducing story points is to move away from time estimating. Time estimating is broken and inaccurate. Complexity estimating is marginally more accurate but still with a wide range of inaccuracy. Instead teams should focus on delivering value incrementally, then using metrics over those increments as a measure for future increments.
      - SAI_Peregrinus 5y ago
        And yet there's still a product, still a date that product will ship to customers, and therefore time estimation is at some level necessary. Often there's a factory building something, physical shipping, late fees, etc. If you're solely responsible for setting all your own deadlines, then there's no need to estimate time. That's very rare. Time estimating is broken and inaccurate. But that doesn't mean it's unnecessary, or that one can just give up on it. Teams should focus on delivering value incrementally, then using time taken as a metric (among others) over those increments as a measure for future increments.
        5y ago
deleted 5y ago
[deleted]

What? My company recently added it to help us measure % of time on bugs vs features, and by section of the code base. This is a very very big assumption to make.

falcor84 5y ago

You can do that with story points rather than hours

pc86 5y ago
Not if you want it to be accurate.
- happytoexplain 5y ago
  In my experience, points are more accurate than hours, since most people work with high variability in productivity over time that can't be captured by a mechanism as crude as a stopwatch, so a corollary metric creates a more accurate number than an absolute metric.
  - pc86 5y ago
    We're also talking about measurement after the fact. "How many points did you spend on that story last week?" is not something anyone is going to accurately answer (and it doesn't mean anything, anyway).
    - brianwawok 5y ago
      Yah exactly. A scrum master will also say never try to equate points to hours, its a losing game. But being able to look back in May and say we logged 32% of all development hours on bugs is a very useful metric for me the business owner / dev lead. (In addition we don't do story points on bugs. I am so far away from the by the book agile thing, I don't even know if this is correct or not anymore).
  - xtracto 5y ago
    https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch... Time based software development estimates before the magical "story points" system was in vogue.
    - brianwawok 5y ago
      It’s also more useful when looking back IMO. Points are more meant to be a soft guess for going forward.
Jenk 5y ago
Story points are not a tool for duration, they are a tool for relative estimation and should never be converted to time in any capacity. _Especially_ not inter-team. This is the current biggest mistake in the industry, imo.
- SAI_Peregrinus 5y ago
  I agree, but I'd say story points are themselves a mistake. In the end, what matters is time. Story points don't matter if the schedule slips. So you either get story points and no way to keep a schedule, or story points + time estimates (with useless story points), or just go with time estimates. The schedule may still slip, since estimating time is very difficult, but at least some of the time it will be correct (or estimates will get padded until things happen on time). Either way, it's more useful than giving up on the problem.
  - Jenk 5y ago
    The entire purpose of introducing story points is to move away from time estimating. Time estimating is broken and inaccurate. Complexity estimating is marginally more accurate but still with a wide range of inaccuracy. Instead teams should focus on delivering value incrementally, then using metrics over those increments as a measure for future increments.
    - SAI_Peregrinus 5y ago
      And yet there's still a product, still a date that product will ship to customers, and therefore time estimation is at some level necessary. Often there's a factory building something, physical shipping, late fees, etc. If you're solely responsible for setting all your own deadlines, then there's no need to estimate time. That's very rare. Time estimating is broken and inaccurate. But that doesn't mean it's unnecessary, or that one can just give up on it. Teams should focus on delivering value incrementally, then using time taken as a metric (among others) over those increments as a measure for future increments.
      - 5y ago

deleted 5y ago

[deleted]