4 ms·

> 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

• vincnetas 5y ago
  "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.
  • Tade0 5y ago
    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.
    • charlieflowers 5y ago
      Can you elaborate more on quick sort? What does that achieve? Why does insertion sort not work, and why does it require cunningness?
      • SimonPStevens 5y ago
        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.
      • SonOfLilit 5y ago
        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.
      • Tade0 5y ago
        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.
• eastbayjake 5y ago
  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.)
• mathattack 5y ago
  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.
• Igelau 5y ago
  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.
  • Tade0 5y ago
    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.
  • kaiju0 5y ago
    Just tell them they are falling into the 9 ladies can make a baby in one month process. That usually gets their attention.
  • mcherm 5y ago
    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 https://en.wikipedia.org/wiki/Brooks%27s_law
    • ornornor 5y ago
      We all know that, but it seems management didn’t get the message.
    • Igelau 5y ago
      Yeah, that was my point.
• 1001101 5y ago
  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 https://en.wikipedia.org/wiki/Project_management_triangle