[jdavid]

This might work in StarFleet, but the problem is that if you promise a manager something repeatedly, by overestimating, they will start to assume you are padding your results.

Having worked on scrum teams before, I find its a good structured way to have a dialog about how much work is left, and how long you expect it to take.

So rather than saying an hour. You would say this is as easy as changing a diaper, or its as hard as navigating through an asteroid belt at the speed of light ( having or not having done it ).

I would appreciate it if managers ask:

Have you done this before? (yes, no)

How similar is this to something you have done before? ( very similar, kinda similar, totally new )

What concerns you about the task, or what risks do you see coming your way? ( detailed answer )

What can I do to get you the resources you need to help you deal with the risks you can foresee now?

[zedshaw]

> the problem is that if you promise a manager something

The real problem is thinking of "estimates" as "promises" when really they're rough guesses. If you go around holding people to a guess as if it were some kind of gospel biblical contract then yes, they will lie their ass off to protect themselves. Combine that with the fact that most organizations attempt to control the platform used, computers used, monitor size, operating system, IDE, editors, revision control tools, languages, documentation systems, testing methodology, meeting requirements, pairing, and nearly everything they can, and you start to see the real problem is....

managers who don't know programming, motherfucker. :-)

[johngalt]

My favorite is when conflicting estimates are asked for, then BOTH taken as promises. Manager ADD

Manager: "How quick can you get this done?"

MFer: "3months (assuming price is no object)"

Two weeks pass...

Manager: "Our budgets changed. How much $$ can we trim out of this project?"

MFer: "We can cut it in half, but that will triple our timeline."

Manager: "cut in half! Great!"

3months pass:

Manager: "Hey why are we behind? The big guys want an explanation why you aren't meeting your targets!"

[chopsueyar]

Who are you?

[jclaassen]

Managers want promises because execs need promises because the board is critiquing their job performance based on when they ship the next product.

The board wants promises because they want to know when they get paid.

If you find it stressful that people are turning your vague estimate into a promise, imagine having to make promises on other people's vague estimates.

[heresy]

Sometimes they are promises. To customers. Who've already paid for it. :S

[zedshaw]

Ohhh, my bad, I totally forgot that people like selling things that don't exist but telling everyone else they do exist.

[pessimizer]

famous case:

http://www.itworld.com/waste-management-sues-sap-080327

"At that meeting, SAP AG executives and engineers represented that the software was a mature solution and conducted a demonstration consisting of what they represented was the actual SAP Waste and Recycling software," the complaint states. The company later discovered that the software was a "mock-up version of that software intended to deceive Waste Management," according to the complaint. SAP has admitted to this in "internal documents," the complaint states.

"From the beginning, SAP assured Waste Management that its software was an 'out-of-the-box' solution that would meet Waste Management's needs without any customization or enhancements," the statement reads. "Unfortunately, Waste Management ultimately learned that these representations were not true."

[Semiapies]

Or promises to customers for custom software. They don't pay except on acceptance, but they won't pay more than the estimate.

Of course, then you run into some of the same situations as described.

shrug

[Groxx]

I suppose the epitome of this would be pre-orders for Duke Nukem Forever?

[ThomPete]

Only when scrum is extended into the overall strategy of the company can it solve that problem.

It makes no sense if only the developers and designers are doing scrum when the rest of the company is expecting deadline deliveries.

[NY_USA_Hacker]

You are in part outlining the start of some standard methodology for project time estimates. That's the good news. The bad news is that, for cases of never done this before and this is totally new, the methodology makes no estimates!