4 ms·

Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always unde

Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done. Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%. Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc. Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.

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..

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..