I'm not going to judge the author's transition to kanban, it may very well be a better fit for what they do. But there are two significant misstatements about t

I'm not going to judge the author's transition to kanban, it may very well be a better fit for what they do. But there are two significant misstatements about the sprint-based process that need to be corrected: 1) Scrum tries to drive productivity by imposing a time limit on work. No, reality imposes a time limit on work. Scrum just provides a framework for partitioning work to improve visibility so that time limits can be rationally traded off continuously against goals, instead of in the context of sporadic self-induced crises. 2) Scrum assumes you’re good at estimation. Scrum assumes that you are relatively consistent at estimation, as a team. There's a reason that scrum uses story points and not person-hours---every team is unique, and if you track velocity for a few sprints your team should converge on a velocity that they fairly consistently achieve. A good scrum master is also cognizant of the granularity of the tasks in the backlog, so that the team is wary of accepting a story whose point value is a large portion of the target velocity.