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

11–20 of 73 posts

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

#11

Post by eastbayjake »

Tade0 wrote: post #3

> 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 h…

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

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

#12

Post by Guthur »

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

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

#13

Post by mathattack »

Tade0 wrote: post #3

> 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 h…

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.

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

#14

Post by peterkelly »

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

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

#15

Post by charlieflowers »

Tade0 wrote: post #9
vincnetas wrote: post #7

Earlier quoted context omitted.

"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, becaus…

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

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

#16

Post by avereveard »

andy_ppp wrote: post #2

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.

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

#18

Post by SimonPStevens »

charlieflowers wrote: post #15
Tade0 wrote: post #9

Earlier quoted context omitted.

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, becaus…

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.

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

#19

Post by SonOfLilit »

charlieflowers wrote: post #15
Tade0 wrote: post #9

Earlier quoted context omitted.

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, becaus…

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

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.

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

#20

Post by Igelau »

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.
Post reply on HN