Defense against the dark art of estimation bargaining (2014) | Hacker News Reader

Defense against the dark art of estimation bargaining (2014)

monkeyandcrow.com

136 pointsdredmorbius71 comments

> Bargain scope, not time

I've started applying this and it's amazing how well this works.

Of course sometimes it's just not possible to reduce the scope any further, but the key point is that the stakeholders just want something, anything and as soon as possible at that.

You give them that and suddenly there's much less pressure and you can focus on delivering the rest, or sometimes dropping it entirely because in hindsight it wasn't that important.

There's a similar phenomenon occuring when playing planning poker - often the estimate is not what anyone wanted, but the one that the most could agree on, which is usually way off. I thought of solving this by having a single transferable vote, but I hadn't had a chance to play planning poker for over a year now, so I have no data on its effectiveness.

"or sometimes dropping it entirely because in hindsight it wasn't that important." yes for that multiple times. usualy people want results without thinking about oportunity costs. and when you have multiple tasks and ask to sort them by priority you get the answer that everything is important.

It somewhat sinister, because what we're doing is essentially pitting the stakeholders' past priorities against the current ones. But it's effective and I wish they were aware of this more.

One other trick I have up my sleeve is to do an, ahem, quick sort of tasks with the stakeholders. There's a degree of cunningness required to pull this off, but it works.

Hilariously enough insertion sort is less effective, because it's too obvious.

Can you elaborate more on quick sort? What does that achieve? Why does insertion sort not work, and why does it require cunningness?

No op, but I think I understand what they are getting at.

With a quicksort you take one item and compare it one at a time to every other item by just asking this question "does this come before or after". Then you repeat that process with each side.

But with insertion sort you take each new item and ask the question "where does it go in this already ordered list".

Although these are logically essential the same thing, and certainly have the same result, it's the way the question is framed that makes the quicksort approach often the easier question to answer when trying to decide on a priority order.

Both require a little cunning because you have to get the other person to "forget" that they are essentially prioritising a large list and focus on the easier question of the individual step in the sort algorithm. That's easier with quicksort because the question is very small and isolated, but with insertion sort you are constantly looking at the larger list in order to find the insertion point.

Not GP, but I assume they mean "choose a random task, partition all other tasks on more/less important than it, recurse (probably only for the 'more' taskset)".

This doesn't really feel like a full sort of tasks. Insertion-sorting the tasks does, and so would trigger the "oh no all of these are important" reflex sooner.

The other replies explained this really well, but I'd add that the effect typically is dropping requirements which only seemed important at the time. Often happens once the reduced scope is delivered and new tasks arrive and it occurs to the stakeholders that the current state is "good enough for now".

I usually do one comparison per meeting - regardless of the topic at hand.

When I play the tech lead role, I try to view my job as the business/PO's "counselor in the art of the possible." Two things that help in estimation:

1. Help your development team make explicit the assumptions in their estimate. This is part of bargaining scope instead of time -- when you make explicit that your estimate includes e.g., authentication and responsive design and reusable component development, your business stakeholders will sometimes say "No no no we don't need those things now, we only need X and Y" and suddenly the team has a much more feasible effort in front of them.

2. Don't argue beyond a certain point, occasionally resolve disputes by giving the story to the person with the lowest estimate. Sometimes it's a learning experience for the developer who underestimated. Sometimes it's a learning experience for the rest of team that overestimated. I have taken 1 point stories that the rest of the team swore would be an 8 point story, then used it as an opportunity to pair program with one of my developers to show my approach. (If the business wants an unstyled link to open an email message to your support address, that's not a reflection of your skill as a developer -- you don't need to solve for the full-function feedback popup modal with input validations and error states, it's work you can do as iterative enhancements later, if ever at all.)

This is also a good way to understand the priorities of the buyer or decision maker. Forcing someone to stack rank priorities in the scope negotiation separates must haves from nice to haves. This is even more important when you deal with Requirements By Committee.

In my experience, management digs its heels in on scope and time anyway by bringing in more people. Usually lots of them, and the cheapest people they could get.

True. I've been to enough such projects to start actively avoiding them. Also I've found that in a team numbering in the teens my bargaining power is next to none.

I don't envy anyone put in such a situation.

Just tell them they are falling into the 9 ladies can make a baby in one month process. That usually gets their attention.

Under a huge number of common scenarios, adding manpower to a project INCREASES the delivery time. This has been well-understood since 1975[1].

[1] https://en.wikipedia.org/wiki/Brooks%27s_law

We all know that, but it seems management didn’t get the message.

Yeah, that was my point.

When I did consulting we used the PM Triangle and STR [1] where

Scope = Time x Resources

and could add people to the project when scope and time were sticky (say a project had to be ready for a trade show, or stuff had to be at distribution by August to be in stores by Christmas).

[1] https://en.wikipedia.org/wiki/Project_management_triangle

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 the deadline to 2 weeks and then we can revise it. Me: whatever. 4 weeks later the feature is delivered to prod, nobody bats an eyelash.

The thing is most of the time these deadlines are totally artificial and simply a psychological trick to induce a sense of urgency. Moreover, PMs know that deadlines will slip and are prepared for this , they just want them to be slightly unrealistic so that you feel pressured (even better if you yourself suggested the deadline under their intent stare, then the pressure is higher).

> PM: well, I’ll provisionally set the deadline to 2 weeks and then we can revise it. Me: whatever.

A PM doing that would be a red flag for me.

Clearly the PM isn't trying to manage the project in a tranparent, sustainable manner. They're trying to politic, manipulate, and pull the wool over everyone's eyes. This will only erode trust on all sides over time.

I've seen this poison tech orgs in the past. It turns them into a soured marriage where nobody seems to understand the other side and feels like actual communication is impossible.

Fix the incentive for the PM to play the games. TFA somewhat addresses this (bargain scope, not time), but it doesn't really address the underlying political forces the PM is acting under.

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”)

4 weeks later the feature is delivered to prod, nobody bats an eyelash.

What do you do when eyelashes get batted?

Seems like you'd get accused of "not being a team player" or some such bullshit if you say the truth, which is: "The PM set that deadline after consulting with us, and us telling the PM that 2 weeks wasn't feasible."

In a good environment, you do something like give your boss a flag "hey, this PM is putting a two-week deadline this thing which we can't do by then because of all this other scheduled work" so they can have a chat with that PM's boss and then the two of them can potentially rope in whoever else is needed if re-prioritization is really necessary.

That's what middle management is for. The PM isn't your boss (I'm assuming). And they have a boss too who's job is to keep them in check, and the other middle managers are supposed to have relationships with each other. If there's any sort of middle management at the company yet things like that still either fall on the individual developer or dev team, that's a pretty bad environment (which then falls on the CTO, for having a tech management team that can't navigate the company, but in a different way that it would be on them than in a tiny company with devs reporting directly to the CTO.)

If PMs set developer schedules or are managing devs, it's a pretty big red flag for a company.

If the other person isn't even bothering to listen, there's no point talking. It's not a good-faith attempt to get estimates, it's not a two-way conversation, it's them trying to play dictator over time and space (or else play machiavellian politician). The only thing you can do is try to limit the amount of damage to yourself caused by the mess that they're going to make.

(I mean, you might be able to limit the damage to the company, too, but that would take exposing and undermining the PM now, rather than once the damage shows up. This is difficult, for two reasons. First, upper management really wants to believe what the PM is telling them, because it sounds better. Second, it's a political battle, and most coders aren't equipped to fight those successfully. One reason not to bother is the "nobody bats an eyelash" - if everybody knew it was a BS estimate, so there wasn't any damage to the company because nobody relied on it.)

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 is that the motivation is built on fear and are very poor at actually achieving quality outcomes.

One of two things is likely to happen with deadlines as your main motivator (a) they are ignore completely with very little impact on a workers motivation, this is likely a very disengaged workforce or (b) they are feared and drive an individual to try to hit the deadline not matter the cost either in quality or their well being, both are ultimately bad in the long run. Also we're also susceptible to Student Syndrome [0] which can exasperated scenario (b).

I believe that we are constantly stuck in rewrite cycles because we are forever rushing to meet arbitrary sprint deadlines.

Leadership should be using development metrics to try to estimate delivery velocity and understand the selected priority order for delivery, but don't turn those into deadlines, keep the system in control so that you can be accurate to your projection.

[0] https://en.m.wikipedia.org/wiki/Student_syndrome

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.

From what I've seen that's a "this is the last thing I want from this team, and I fully the best people to leave immediately after" option.

There is a away to set goals and these can have a time component, daily todo list, weekly goal. But as you mentioned this works when they are a personal tool, and best when broken down into small achievable increments.

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.

A method that works wonders is to unpack exactly what has to be done in July and why. That involves gathering information about the business.

Just as a good estimate requires some modelling, so does a good requirement. By July they might not need an overhaul of the whole billing system, but there might be a few small things that would have a huge impact that could be done. Maybe you can deliver 60% of the functionality in June and another 30% in August.

My experience is that this kind of thinking plays well with upper management, C-level kinds of people. That is, they make trade-offs on this level all the time and are glad to be engaged in this way. In fact, if everybody thought this way, the company wouldn't have any problems.

My experience also is that some middle-managers are highly offended by this approach for reasons I can't understand, other than they feel like they've lost control. It seems like a small price to pay for "getting things done" for the business, but they don't like to get bypassed.

Here's my approach:

"Look, there's two ways I can respond to this. I can be honest with you, and tell you the truth about how long I think it's going to take. You might not like the answer, but at least you will be in a position to make properly informed decisions about what to do, such as reducing the scope or adjusting the launch date.

Alternatively, I can lie to you and give you an answer that will make you feel satisfied when you leave the meeting, but is inevitably going to cause trouble for both of us a few weeks/months from now when the expected deadline is missed.

Tell me which kind of response you'd prefer, and we can proceed from there."

What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?

Quit (yes, seriously).

The extreme toll that burnout can take on your mental health simply isn't worth it. There are greener pastures out there and these days I only work with clients that prioritise quality over speed.

I’m genuinely interested because I’ve miserably failed at it so far.

When I inquire about the speed vs quality trade off in interviews or during discovery, the answer is always that quality is paramount. But a little later, when it comes down to the brass tacks, we’re asked to make the trade off and put speed over quality. Every time. Even when it was the company’s motto/yearly objective to “focus on quality”, even there, eventually speed was more important when pressed.

So I’m wondering: how do you find out whether quality is just lip service? It seems like a simple answer but over the last ten years I’ve always gotten it wrong and the project ended up being a pressure cooker with overtime to “fix” it.

The instant that bargaining begins, it's not an estimate you're discussing anymore, it's a commitment.

Very few people want estimates, they want commitments. They just frame the conversation around estimates to get people talking.

> At this point you might think, “Okay, just double your estimate”. Don't, this just leads to an arms race of deceit, and encourages more bargaining in the future.

It's not deceit, it's conversion of an estimate into a commitment.

Early in my career I thought an estimate should be my guess of the most-likely completion time. Trouble was, if I got those estimates right, it meant I was late half the time, and management hated that. And they kinda had a point. They were making promises to customers. They looked bad if we were late.

So after a few years I started giving estimates that I was at least 90% likely to meet. And, as you say, I committed to them. In the minority of cases when I ended up on the bad tail of the bell curve, I worked extra to meet my commitment. Management was much happier.

In compensation for those occasional bursts of extra work, on average I had some free time. I used that time to learn stuff, or clean up code, or automate some of my work. That made my work easier, allowing me to shorten my estimates while still maintaining the 90% rule.

Sure, all of this is easy when working with good people and difficult when working with people who constantly lie both up and down the management hierarchy.

Essential I feel this stuff only works when results are a by product of earned trust from management on delivery. If there isn’t that trust built up people are likely to try to appease whoever is going to give them a raise.

Yeah a lot of these approach only work if applied to the perfectly spherical manager and engineers.

You don't have to be perfectly spherical to not be a manipulative liar.

Hey there, I'm a bit surprised to see this reposted. I'm the original author.

I don't think it requires perfectly spherical humans in a frictionless office, but it does require everyone to have the same incentives in place.

When I wrote this, I worked on a pretty well aligned team with a very short power distance. If you're in a truly adversarial position, you probably need to take a different tact, or find a new role.

> I worked on a pretty well aligned team with a very short power distance

then whatever management style would likely have worked; where I work I've the ultimate word on who works with me and I only allow hires that are well motivated and aligned and just set them in the direction of the goal and they barely need anything but some technical guidance every now and then. the downside is that we have a interview failure rate of about 98%, we're short of people and I'm under immense pressure from above to grow my team with whatever fit the job advert keyword.

> you probably need to take a different tact, or find a new role.

that is great personal advice, but to management, the golden egg is how to make dishomogeneous people work, even in face of adversarial behavior.

they managed to do it on the factory floor, and there's good money for whomever manages to bring some of the line working hell to creative workers, money which is currently being scooped up by scrum masters and the like, so the bar isn't even that high

An older IBM gentleman told me back in the eighties. 'Don't accept the invitation to fail.'

Sometimes getting your foot in the door is all that counts, and you can renegotiate from there.

Way back, the company I worked for and this other company where bidding for a job. They wanted a lot of work done on a ridiculously short deadline (3-4 month), we said "can't be done", the other company said "sure". Anyway the other company completely failed to deliver on time, but since they already had the contract and had already started the work the company that hired them figured it was easier to just renegotiate an extension to the contract than replacing them. Long story short, the other company got a solid 18 month of good steady work out of their 'failure'.

> getting your foot in the door is all that counts

Keep in mind that the quote you're responding to was from an IBM old-timer.

That context, back then, was that IBM was well-past having its foot in the door and was walking around in all your business! There's wisdom in "not accepting an invitation to failure" in that context.

You're right though, estimation is all head-games, especially when bids are involved.

I don't understand how to handle this. In my experience this is what happens:

  - You start with a PM/PO/Someone handing out tasks
  - You learn the system
  - You start doing more work
  - They start giving you harder work
  - They start asking you to manage the tasks/trace down AC for new tasks
  - They start asking you to fix bugs or change AC mid-sprint
  - No amount of logic gets through

We can have discussions all day about the three variables, or agile, or maintenance, but at the end of the day if it's just a free for all it's up to how much they like you/how much you can delegate/how much you can say no effectively (and on an ongoing basis) to.

We have agile/jira/all these systems. Why not use them? Why not plan 2 weeks of work... and do 2 weeks of work? Why do they always need to try to squeeze more? It's exhausting and unnecessary and annoying.

Edit: I've worked extremely hard to do everything management asks, and I think this is the problem. I always do. How do you say no? Is it in private? Does the "scope talk" work? Do you do it for every story? Do you end up doing a lot of the planning work and always know what's on your plate as things are added so you aren't overloaded?

I really don't want to be the "make a ticket" guy, but it seems management can handle little less.

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 :)

Chapter 2 “saying no” of “the clean coder” book has the best treatment of this topic i’ve read. It’s just the most realistic based on my experience.

He also addresses the common push backs - e.g. “you don’t understand, i can’t say no in this position right now”

Quick summary?

Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong.

He rounds out the short chapter with an appeal to professionalism.

This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster.

Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rather than trying to make a system that hums forward quickly. They demand speed, but don't want to improve process to get that, they just want you to work more and harder.

Is there a way to build trust or consistently set boundaries or protect your time? Some of my co-workers say "I'm almost out of hours for this week", which I think is one of the only things they understand, but then you really have to close the chat client and not help other devs, lest you miss your "estimates".

We’re all chronic under-estimators by default so I wouldn’t beat yourself up over that one! The old planning fallacy is very well studied and documented. Humans are terrible at estimating by default unfortunately :-( but it’s not that hard to be conscientious about getting more accurate. For me, the secret is to just delegate to a tool that gives me estimates based on my past performance. The cost to me is nothing more than logging an estimate up front and recording what it ended up after the fact. Doing that for a few weeks rapidly steers you to breaking your work into small chunks because it’s too hard to make the recording work otherwise. Turns out small chunks of standalone useful outcomes are optimal anyway for 1001 other reasons.

As for saying no - one way could be to find a role model somewhere close around you, it should be easier to copy what they do if they’re in the same org structure and facing the same struggles. You can’t just assume to flick a switch and behave like them, everyone around you has an expectation of how you behave right now, so you have to be fairly active about signalling to people they should update their perceptions.

The trap isn't bargaining, the trap is allowing someone to shift the responsibility from demand to creation.

What I mean is that the role of demand hasn't fully defined exactly what they want, it's nebulous, once the demand role accepts the responsibility for developing a timeline for a non-defined project it also accepts the responsibility to develop the requirements.

I simply never accept shift in responsibility.

Howdy, I was the author of this a lifetime ago.

Having been on a nebula project with a timeline once or twice, you're right, this is definitely a trap to avoid.

I'd love to hear an example of how you've negotiated it.

I get this a few times, but my conversation goes something like:

Peter) how long will it take to do "an action that you don't know how long it will take"

me) I don't know, at a complete guessminate X weeks

Peter) ok, you can do it in X/2 weeks then

me) I'll need to triage the request and understand the requirements then at a guess it "may" least Y days to investigate what's needed - that's if It can be done, assess the amount of work needed, governance to go through, assess the priorities and get back to you with the order of magnitude costs for you to sign off - How soon can you set up the triage with all the relevent SMEs to answer my questions?

Wow, hey folks as the author here, I'm really surprised to see this pop up on HN.

It's been a long time since I wrote this, and I've come to appreciate that there are a lot of nuances, a lot of different teams, and a lot of different ways incentives are aligned in different environments.

I'd love to hear some illustrations of ways y'all have navigated these issues. What factors made it successful? When would it not have worked?

What I tend to do is take a good estimate and triple it. So, at the end, I'll still have some leeway for things I didn't anticipate even after negotiating. But you method is definitely a step up.

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.

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

> rephrase the discussion in terms of scope

I've tried that before, many times, and found it similarly futile. They just start negotiating what the "scope" means until they've negotiated it back up to what they were originally asking for... because that's what (they think) they actually needed in the first place. Scope is just too vague to be used this precisely.

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

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.

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.

Right. That's required velocity to make equation balance. Much different than actual velocity.

It’s (scope/time)/person_or_team

Scope is sometimes fixed too, ie through contractual obligations. Velocity can be increased by pulling more resources in - to a certain point.

Agreed. Identifying what is fixed and what is negotiable is key. Most often I see that scope is the only one that is not fixed when it comes down to it.

Even more important is not letting your team get boxed into fixed scope and fixed time as you can increase velocity some but increases to velocity are usually the most over-estimated in my experience.

I have started to tell people that you can’t defeat reality. If you want you can have a shorter deadline but we will just miss it most likely.

Reply on news.ycombinator.com