I've spent my career living in sales and engineering camps. I've managed whole sales organizations and written full applications from the ground up. I could not disagree more with the author that time estimates should be eliminated. The business does not exist without revenue, and revenue is less likely to be retained (customers) or acquired (new customers) when the business is unable to anticipate product delivery timelines. Think about all of the other business functions that key their todos and deadlines off of a product release. There is also the question of accountability. I'm intrinsically motivated to be productive, but even I value knowing if I am tracking well on a burn down chart. It gives me daily insight into whether or not I should communicate a need to trim scope or coordinate a deadline change with the other business functions if scope can't be trimmed. Kanban is awesome for bug fixes that are hard to anticipate, but any dev worth their salt should be able to offer a time estimate. If something happens, then communicate why the estimate has to change and keep incorporating the lessons learned from into future estimates.