3 ms·

> tickets were always underestimated Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple

by xxs 4y ago

> tickets were always underestimated Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.

steveBK123 4y ago
Many tickets were also overestimated! They just don't stick out as a problem since they close early and make the sprint look good. Naturally, the ones that don't close are the ones that are underestimated! If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint. The system is seemingly designed to produce this outcome.
- StevePerkins 4y ago
  This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either. The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
  - steveBK123 4y ago
    Yup the other stupid thing that kept happening was sizing the work to fit the model. Medium sized tickets were least controversial in 3 hour backlog refinement meetings. Therefore every ticket began to ranked at that level. Which then beget us chopping up anything larger into these medium sized tickets, and avoiding creating any too-small tickets. So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve". Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint. It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?" This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..

by xxs 4y ago

> tickets were always underestimated Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.

steveBK123 4y ago

Many tickets were also overestimated! They just don't stick out as a problem since they close early and make the sprint look good. Naturally, the ones that don't close are the ones that are underestimated! If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint. The system is seemingly designed to produce this outcome.

StevePerkins 4y ago
This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either. The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
- steveBK123 4y ago
  Yup the other stupid thing that kept happening was sizing the work to fit the model. Medium sized tickets were least controversial in 3 hour backlog refinement meetings. Therefore every ticket began to ranked at that level. Which then beget us chopping up anything larger into these medium sized tickets, and avoiding creating any too-small tickets. So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve". Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint. It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?" This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..