In general I'm openly against Scrum. Whenever I join a team doing Scrum I can immediately notice how the artificial concepts stiffle innovation and productivity. The "sprint" made sense when we used to release software every 2 weeks, not every 2 hours. The "scrum master" is a glorified meeting facilitator, and I've never seen anyone doing both sprint review and retrospective every 2 weeks.
I disagree with 1 thing in the article though: the estimates.
> A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity.
How many days will it take you to do this task? - you can ask the team
* Ben, a junior dev, says a week.
* Carol, a senior dev, new to the company, says 3 days.
* Dara, a team veteran, say 1 day, at most.
That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.
I disagree with 1 thing in the article though: the estimates.
> A simple estimate of “how many days?” would have been easier to think and reason about, while also providing more granularity.
How many days will it take you to do this task? - you can ask the team
* Ben, a junior dev, says a week.
* Carol, a senior dev, new to the company, says 3 days.
* Dara, a team veteran, say 1 day, at most.
That's why estimating using time is wrong, because time depends on an individual. Instead of asking "how quickly can you run to that building?" ask "how far do you think that building is?". The distance is independent of anyone's skills. The complexity of the task does not depend on how skilled you are, that's why we're using abstract units, to measure the size, not the time.