Hacker News Reader

Comment by Tade0 | Hacker News Reader

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

View on HN

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

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

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

Reply on news.ycombinator.com