←back to thread

When did estimates turn into deadlines?

(domainanalysis.io)
317 points alexzeitler | 2 comments | 19 Nov 24 20:03 UTC | HN request time: 0.403s | source
Show context
redleggedfrog ◴[19 Nov 24 22:06 UTC] No.42188611[source]▶
I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.

So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good.

Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes.

Also, just made meetings a lot more fun.

replies(14): >>42189183 #>>42189189 #>>42189248 #>>42189402 #>>42189452 #>>42189674 #>>42189718 #>>42189736 #>>42190599 #>>42190818 #>>42191841 #>>42194204 #>>42194310 #>>42200625 #
genghisjahn ◴[20 Nov 24 00:50 UTC] No.42189718[source]▶
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day.

Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points.

I would snapshot the sprint each day, so each day I could see how many tickets got removed/added. The end result being I could show my manager, look, when volatility is low, we almost always finish the sprint. When the volatility is high, we don't, it doesn't matter if we are over/under velocity because we don't have the time to properly plan and get clarity on asks. Have our product team think more than two weeks out and we'll deliver. That worked to a degree.

replies(3): >>42189916 #>>42190521 #>>42191256 #
Izkata ◴[20 Nov 24 03:12 UTC] No.42190521[source]▶
> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points.

Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.

replies(2): >>42191421 #>>42194423 #
1. wolpoli ◴[20 Nov 24 07:02 UTC] No.42191421[source]▶
In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.
replies(1): >>42193050 #
2. genghisjahn ◴[20 Nov 24 11:56 UTC] No.42193050[source]▶
After I presented the volatility findings, that changed. Sprints largely had to stay as they were and the team decided what we’d take on after the sprint started. It got better. But the whole sprint/scrum/agile thing is still weird. It can be helpful but in a large org it’s never easy. I hope for further improvement in the area of scheduling/estimation in software development.