Why I'm not a big fan of Scrum

In the real world, there are externalities that have an impact and require some estimation. Maybe we have to provide new support materials to customers, or finish a contract with a third-party data provider, or change our infrastructure. It's exceptionally hard to do some of these things without being able to make commitments of some kind. Estimates allow us to create a guideline, and subsequently alter either the thing we are going to deliver (i.e. dropping lower-priority features) or the time we are going to deliver (i.e. missing the deadline).

If I hired a builder, and he told me that he refused to estimate the amount of money or time it would take to construct my property, you can be sure I'd move on. I have no idea why we'd consider it appropriate for an engineer to do this.

For example the only purpose for points and velocity is to give product owner idea of how much time will have to pass before a thing might even have a chance of being done. It tells him that you, for sure won't get this thing and that thing in next 2 weeks.

The only utility of points for the developers is when doing planning poker. If something gets a lot of points then this means people are not sure how to do it and the thing needs to be discussed and broken down.

After that, points have no use for the team and team shouldn't even be aware of its velocity and how much they burned so far this sprint. Those are the tools just for the product owner and scrum master.

If product owner is satisfied with "it's going to be ready when it's going to be ready" then points after planning poker can be forgotten and you don't even need to calculate velocity. It's still worth to do the planning poker for the sake of the team discussion and so the product owner can deprioritize task that are hard but not crucial.

But turning points and velocity and performance measure is dumbest thing you can get, because then it get's screwed and loses all utility. Same thing in estimations. If manager is going to negotiate estimates then you can as well not do it at all because they no longer carry any real information and are becoming just the reflection of managers hope slightly skewed towards developers hope (which was already overly optimistic).

I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7".

"Oh, since we're adding new email features, we'll need to clean up some of the old email code. That will add additional complexity to this task, so we will estimate it higher."

It works, allows us to still track the impact on velocity, keeps everyone informed, and makes technical debt clear and trackable.

* The prediction is made in a meeting while your head is "out of the code".

* The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink.

* The prediction is made up to 2/4 weeks in advance of actually doing the work.

* The prediction is made without risk of overshoot attached. Risk is critical metric which scrum conceals.

And the main defining characteristic of scrum that leads to pressure, after all of that unwarranted optimism:

* The prediction is designated as a commitment.