NoEstimates in a Nutshell

[@rl-fg2nf]

00:55 output → backlog 02:40 backlog → work to do 03:25 past → future 04:10 summary

[@bhart89]

Brilliant. Your example could also be used to explain how difficult it is to offer a valid forecast while your wife keeps adding higher priority task to your list while still expecting you to complete peeling the potatoes within the time you initially supplied.

[@nicolastorres5945]

As a BA in Agile, I have a deal with my PO: You can add anything, at any point, whenever you want and whatever you want, it will have the priority you want... but the team will evaluate, estimate and something equally complex will leave the backlog.

[@EmilNicolaiePerhinschi]

there are projects which are like peeling potatoes: these you have a chance of forecasting but your customer should buy off the shelf software if possible other projects are like designing a totally new and unheard of meal which should please guests you have not met yet: no forecasting possible, you have to bring the guests into the kitchen and iterate ideas->prototype->tasting->new-idea->new-prototype->tasting etc. until either you run out of budget, your guests run out of budget or your guests like your last prototype so much they add to the budget to tide you over a few more iterations software development is not manufacturing

[@Jedimaster36091]

On "what problem are you trying to solve by forecasting", consider the scenario: a customer comes to my restaurant and asks me how much would it cost to organize a party for 50 guests, all included (meals, music, entertainment etc.)? And when is the earliest date when they can have the party? How does #noestimates help me, as restaurant owner, close the deal with this customer? So far, I understand it can help me with execution, but that only comes after a deal has been closed with the customer. By which time, I already committed to a cost and deadline.

[@JohnYorke1]

In that context you are controlling the variables and so NoEstimates is not relevant. Software rarely operates that way. More like being asked to organize a party, but the customer doesn’t know the number of guests, the food choices or how long it will last. That gets you closer to software. There are so many variables and unknowns that attempts to control the variables are almost always detrimental to the customer.

[@Jedimaster36091]

@@JohnYorke1 My point was that even in the example I gave, the cost and time estimation is highly subjective and more likely wrong. It is more likely that the numbers are determined following a negotiation with the customer rather than empirical evaluation. Your example takes mine even further into La La land, with adding more unknowns, but it doesn't change my premise that cost and deadlines are decided by sales and not by technical team.

[@JohnYorke1]

@@Jedimaster36091 I wholeheartedly agree with you. Cost and deadlines are determined by sales and often in isolation. But in what is scarily approaching 30 years in the industry I have yet to see a project longer than about 6 weeks where the sales project plan comes even remotely close to reality, there are simply too many unknowns and changes during development. Meeting the cost or deadline generally means poor compromises or extensions. Almost always to the detriment of the user (as opposed to the customer/contract) usually a refusal to adapt to new information because it wasn’t in the original plan.