4 ms·

> pretending point estimates are in units of abstract complexity solved this one by enforcing estimates in time duration. you can easily convert to SPs for any

by kmlx 3y ago

> pretending point estimates are in units of abstract complexity solved this one by enforcing estimates in time duration. you can easily convert to SPs for any SP-specific metric.

paulryanrogers 3y ago
I think it's supposed to go the other way. One adjusts the sprint point capacity based on recent point completion trends. The abstraction should make it harder to over promise because it's disconnected from discrete units of time. Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.
- Scarblac 3y ago
  Because they need an estimate in time units. E.g. marketing needs to plan their campaign for when the new release comes out; management needs to know whether we can finish that potential new project in the time frame the customer needs or not. Developers sometimes don't think about the rest of the business.
  - OJFord 3y ago
    It's the pretence that it's not time that I don't like - not that people try to use it for or need something for time estimations. I often find myself saying things like 'well it's trivial, but it's going to be quite a slog because xyz' - leave it up to someone else how they want to point that. E.g. every single endpoint needs to be reviewed and updated to use appropriate status codes, where previously responses have all been 200 with potential error message. API is already versioned, this will be a breaking change but no need to worry about that or the clients at all. -- low complexity, very time consuming. I suppose high complexity tasks are less often quick, or at least not that you would know in advance (optimise SQL query, identify cause if & fix bug) but certainly low complexity tasks can be very slow.
  - paulryanrogers 3y ago
    The purpose of the ambiguity is to keep engineers involved in the time estimates. Otherwise folks may naturally compare the visible portions of some new shiny to previous old shinies, not realizing some massive, hidden differences. If they cut out the engineers then the estimates are guaranteed to be way off. Pointing and T-shirt sizing aren't meant to make planning impossible. Just impossible to do without involving the workers closest to the work. Directly using time units could work, yet in practice are too easily misinterpreted as more precise than they really are.
- kmlx 3y ago
  you're right, but in sales-led companies this is a bit harder to do.

by kmlx 3y ago

> pretending point estimates are in units of abstract complexity solved this one by enforcing estimates in time duration. you can easily convert to SPs for any SP-specific metric.

paulryanrogers 3y ago

I think it's supposed to go the other way. One adjusts the sprint point capacity based on recent point completion trends. The abstraction should make it harder to over promise because it's disconnected from discrete units of time. Of course it may not work well or at all. I know managers and executives still try to convert them to units of time.

Scarblac 3y ago
Because they need an estimate in time units. E.g. marketing needs to plan their campaign for when the new release comes out; management needs to know whether we can finish that potential new project in the time frame the customer needs or not. Developers sometimes don't think about the rest of the business.
- OJFord 3y ago
  It's the pretence that it's not time that I don't like - not that people try to use it for or need something for time estimations. I often find myself saying things like 'well it's trivial, but it's going to be quite a slog because xyz' - leave it up to someone else how they want to point that. E.g. every single endpoint needs to be reviewed and updated to use appropriate status codes, where previously responses have all been 200 with potential error message. API is already versioned, this will be a breaking change but no need to worry about that or the clients at all. -- low complexity, very time consuming. I suppose high complexity tasks are less often quick, or at least not that you would know in advance (optimise SQL query, identify cause if & fix bug) but certainly low complexity tasks can be very slow.
- paulryanrogers 3y ago
  The purpose of the ambiguity is to keep engineers involved in the time estimates. Otherwise folks may naturally compare the visible portions of some new shiny to previous old shinies, not realizing some massive, hidden differences. If they cut out the engineers then the estimates are guaranteed to be way off. Pointing and T-shirt sizing aren't meant to make planning impossible. Just impossible to do without involving the workers closest to the work. Directly using time units could work, yet in practice are too easily misinterpreted as more precise than they really are.
kmlx 3y ago
you're right, but in sales-led companies this is a bit harder to do.