I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt.
In Thinking Fast and Slow, Daniel Kahneman offers my favorite object lesson on the topic:
This embarrassing episode remains one of the most instructive experiences of my professional life. I eventually learned three lessons from it. The first was immediately apparent: I had stumbled onto a distinction between two profoundly different approaches to forecasting, which Amos and I later labeled the inside view and the outside view. The second lesson was that our initial forecasts of about two years for the completion of the project exhibited a planning fallacy. Our estimates were closer to a best-case scenario than to a realistic assessment. I was slower to accept the third lesson, which I call irrational perseverance: the folly we displayed that day in failing to abandon the project. Facing a choice, we gave up rationality rather than give up the enterprise.
The suggestion that the enterprise should have been abandoned all together can be misinterpreted as fatalistic, even nihilistic. I take it to mean that you've got to do your research (the outside view), rigorously define your MVP, and then work from there. If your deadline is fixed, be ready to scale back.
His distinction between the inside and outside view is the key. For a project to have any hope of realistic timelines, it needs to be understood and the outside view needs to be applied.
> If your deadline is fixed, be ready to scale back.
True. Honestly, what else can you do if a deadline is approaching than to cut scope? Even enforced death marches aren’t necessarily going to solve it...
You have the four knobs to turn. Resources ($, FTE), scope, deadline, quality. The dilemma typically is that the one calling the shots wants to fix three of them and does not accept the fourth knob has to be turned. Another is that close to a deadline the resources knob doesn't matter anymore unless the deadline knob is turned. And when the deadline knob is turned it makes the scope knob feeling very attractive suddenly to the same kind of people.
In such situations having people skills helps. You can say no in many ways but you have to try and understand their problems as well. That big conference, competitors having announced something recently, you name it.
It's not a problem if sizes are different. That's why they are scored.
Points are only mean something with a constant team anyway. No point in comparing between different companies, teams, projects.
Also, you can estimate time based on points. After you have some baseline velocity for the given team-project setup.
...
I don't know what kind of estimation meetings you had to suffer through, but the ones we did were the usual SCRUM poker, and then the PM tool just gives you the estimate based on the team's past velocity. No hand-waving. It's data driven. And anyone has any problem with the date can talk to the PM and decide which features to cut/change.
Mine have always had no forewarning, no list of items we'll be potentially estimating (so I could, for example, inspect the codebase and see how much work a 1-line description might be hiding) and then immediately afterwards someone more senior usually rides in and throws a bunch more items at the wall.
In Thinking Fast and Slow, Daniel Kahneman offers my favorite object lesson on the topic:
http://txti.es/kahneman-outside-view
He sums up:
This embarrassing episode remains one of the most instructive experiences of my professional life. I eventually learned three lessons from it. The first was immediately apparent: I had stumbled onto a distinction between two profoundly different approaches to forecasting, which Amos and I later labeled the inside view and the outside view. The second lesson was that our initial forecasts of about two years for the completion of the project exhibited a planning fallacy. Our estimates were closer to a best-case scenario than to a realistic assessment. I was slower to accept the third lesson, which I call irrational perseverance: the folly we displayed that day in failing to abandon the project. Facing a choice, we gave up rationality rather than give up the enterprise.
The suggestion that the enterprise should have been abandoned all together can be misinterpreted as fatalistic, even nihilistic. I take it to mean that you've got to do your research (the outside view), rigorously define your MVP, and then work from there. If your deadline is fixed, be ready to scale back.
His distinction between the inside and outside view is the key. For a project to have any hope of realistic timelines, it needs to be understood and the outside view needs to be applied.