5 ms·

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart h

The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.

yieldcrv 3y ago
I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later and actually doing that made me a star performer, what the hell!?
- flir 3y ago
  That kind of inflation corrects for itself. Because you're supposed to look at the previous sprints to judge how many points you'll get through this sprint.
- inanutshellus 3y ago
  Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". * 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task. * 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3. * 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.") * 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them. * 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.
  - ed_elliott_asc 3y ago
    Meetings are long enough without people spending extra effort doing it right :)
    - inanutshellus 3y ago
      Sharpen the saw, man. It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast. My team's pointing sessions are lightning. Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.
  - Scea91 3y ago
    If you measure velocity then the points are additive, how do you reconcile 3 point tasks doable in a day and 5 point tasks not doable in a reasonable amount of time? Isn't 5 points less than 2 days then? For the record, in my team we don't use story points or measure velocity. I just had a frustrating discussion with a peer team that didn't plan an important task because "its 5 points and does not fit into a sprint".
- steelframe 3y ago
  When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline. At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.
  - pmarreck 3y ago
    Smart. Not all contributions can be measured in points. Some team members do a lot of support/mentoring work, for example.
lowercased 3y ago
"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'. I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work! Slow-paced insanity when taken anywhere near close to its logical conclusions.
- peteradio 3y ago
  Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.
- candiddevmike 3y ago
  I love hearing "points aren't time but you can think of them like days"
  - ed_elliott_asc 3y ago
    My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating. As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate. We normally continue with guesses that are meaningless.
    - bee_rider 3y ago
      What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts? 1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?

yieldcrv 3y ago

I saw this on my last job! I was already adding time to my work like an extra point or two here and there But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later and actually doing that made me a star performer, what the hell!?

flir 3y ago
That kind of inflation corrects for itself. Because you're supposed to look at the previous sprints to judge how many points you'll get through this sprint.
inanutshellus 3y ago
Scrum teams are self-managing, and point values are used for gauging your own team-workload. When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found. Personally: * Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding". * 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task. * 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3. * 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.") * 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them. * 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.
- ed_elliott_asc 3y ago
  Meetings are long enough without people spending extra effort doing it right :)
  - inanutshellus 3y ago
    Sharpen the saw, man. It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast. My team's pointing sessions are lightning. Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.
- Scea91 3y ago
  If you measure velocity then the points are additive, how do you reconcile 3 point tasks doable in a day and 5 point tasks not doable in a reasonable amount of time? Isn't 5 points less than 2 days then? For the record, in my team we don't use story points or measure velocity. I just had a frustrating discussion with a peer team that didn't plan an important task because "its 5 points and does not fit into a sprint".
steelframe 3y ago
When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline. At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.
- pmarreck 3y ago
  Smart. Not all contributions can be measured in points. Some team members do a lot of support/mentoring work, for example.

lowercased 3y ago

"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'. I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work! Slow-paced insanity when taken anywhere near close to its logical conclusions.

peteradio 3y ago
Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.
candiddevmike 3y ago
I love hearing "points aren't time but you can think of them like days"
- ed_elliott_asc 3y ago
  My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating. As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate. We normally continue with guesses that are meaningless.
  - bee_rider 3y ago
    What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts? 1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?