Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defense against the dark art of estimation bargaining (2014)

monkeyandcrow.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Defense against the dark art of estimation bargaining (2014)

#31

Post by ryanianian »

gringoDan wrote: post #29

Deadlines are always negotiable. It's taken me so long to realize that people just want to know you're on top of something. Simply saying "This was deprioritized this week/month/quarter in favor of other work, but I'm still on top of it" buys you a lot of trust. My inclination is to deliver either good news or no news at all – I have to work to fight this.

> Deadlines are always negotiable.

If you already have trust from those who enforce the deadlines. As you point out, a deadline is an accountability mechanism. But if you're otherwise accountable and trustworthy, the deadline isn't really the metric that matters (most of the time).

Re: Defense against the dark art of estimation bargaining (2014)

#32

Post by YeGoblynQueenne »

Peter: This is really important, when is the soonest you can you get it done?

You: Oh, I didn't realise how important it was. Let's say 10 months then, to make sure everything is alright.

Peter: Ten months!

You: You're right, it's really critical work, let's make it 12.

(Wish I had the balls to do that :)

Re: Defense against the dark art of estimation bargaining (2014)

#33

Post by mathattack »

dunkelheit wrote: post #27

I remember a pretty similar dialogue that I had with a PM once, it went like this: PM: so what is your estimate for this feature? Me: 4 weeks to prod. PM: hmmm, that looks like a lot for a small task that is also very important for us, maybe you can do it in 2 weeks? Me: no, considering the amount of additional commitments that we have, I’m pretty sure this will be done in 4 weeks. PM: well, I’ll provisionally set th…

One of the key points you raise is separating the task effort from overall workload. Something I do in similar situations is “Here are the 4 other things I’m working on and their customers. Who do you want to talk to about deprioritizing their work?”

How this gets handled says a lot about an organization. (Priority conversations vs “suck it up”)

Re: Defense against the dark art of estimation bargaining (2014)

#34

Post by chasd00 »

Guthur wrote: post #12

In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc. Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem i…

i feel like everyone in the industry ought to do a couple years in a small eat-what-you-kill consultancy early in their career. When not delivering what you promised when you promised it means the lights don't come on tomorrow you get very good at estimation and delivering on time... or you find a new way to feed yourself.

Re: Defense against the dark art of estimation bargaining (2014)

#35

Post by recursive »

gringoDan wrote: post #29

Deadlines are always negotiable. It's taken me so long to realize that people just want to know you're on top of something. Simply saying "This was deprioritized this week/month/quarter in favor of other work, but I'm still on top of it" buys you a lot of trust. My inclination is to deliver either good news or no news at all – I have to work to fight this.

If TurboTax 2021 comes out in 2023, there's no reason for it to exist.

I don't work on tax software, but I do work on software that has to support externally specified processes that come into force on Specific Dates.

Re: Defense against the dark art of estimation bargaining (2014)

#36

Post by WastingMyTime89 »

Igelau wrote: post #20
lushdogg wrote: post #17

Another way to look at it is that there are three variables. Time, scope and velocity. If time and velocity are fixed variables then it follows that only scope can be changed to make a project fit into the time box.

Velocity is derived. It's scope/time.

That's the necessary velocity to complete in time. It might be very different from the actual current velocity of the team.

Re: Defense against the dark art of estimation bargaining (2014)

#37

Post by funkymike »

geewee wrote: post #24
Guthur wrote: post #12

In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc. Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem i…

I think there's also a third option - that the deadline energizes. I've been in teams, where the team as a whole set a completely arbitrary deadline for the functionality they'd like to have done by a given time - and that worked well to motivate team members to hit it. Granted, this is probably not the norm though, but it's not impossible.

I think there's a large difference between arbitrary deadlines that the team themselves set and buy into as a rallying cry vs. an arbitrary deadline that was externally imposed upon a team, often without full context provided to understand the relative priority of features as well as whether the deadline itself is negotiable.

Re: Defense against the dark art of estimation bargaining (2014)

#38

Post by funkymike »

chasd00 wrote: post #34
Guthur wrote: post #12

In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc. Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem i…

i feel like everyone in the industry ought to do a couple years in a small eat-what-you-kill consultancy early in their career. When not delivering what you promised when you promised it means the lights don't come on tomorrow you get very good at estimation and delivering on time... or you find a new way to feed yourself.

I think a large part of this topic isn't about a team making a promise and not living up to it. It's about a business (management) wanting to make a promise and getting the team to accept responsibility for it. So let's assume the estimate is very accurate but the business wants it done in half the time. When the project runs past that date being able to point to a very accurate estimate and say I told you so isn't very productive. So we need strategies and techniques for dealing with the mismatch between the desires of the business and what can actually be delivered in a given amount of time.

TFA advocates for bargaining on scope, where I prefer to start the conversation by asking about both scope and timelines to understand which parts of the overall request are negotiable. This is also a great opportunity to make sure the business context is well understood so everyone understands what success means from the perspective of the business

You might then find every single feature really is necessary and the timeline can be relaxed. Audit compliance can be an example when it is something new to an org. You are either going to pass or fail the audit, so there isn't really room to reduce scope. But you may be able to negotiate on the timeline.

Re: Defense against the dark art of estimation bargaining (2014)

#39

Post by Sil_E_Goose »

For the most part, everyone is terrible at estimation [0], yet in business we do it all the time and consistently fall into the same traps. I wonder how an organization would be fare if they tried a top down approach to avoid estimation (or at least treat is as dirty process it is). Would this even be possible with the way companies are run today?

[0]https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-f...

Re: Defense against the dark art of estimation bargaining (2014)

#40

Post by gosukiwi »

I always feel like time I spend making estimates is wasted time I could be spending coding, or doing something actually productive. The more time you spend on estimates (breaking it down, detailing, etc) is more time you are not being productive.

Managers seem to love estimates, but IMO it's better to just have priorities, sprints, and just do as much as you can in those sprints.

I understand sometimes you need to know how much sometime takes in order to prioritize stuff, in which case you can just say it takes a lot of time, a little time, or "medium" time.

Estimating is particularly annoying when you have to read someone else's code first in order to estimate.

Post reply on HN