My favorite recent story on estimates comes from a previous company. (I've written about them before. There are reasons I am not working for them any more.) Be

My favorite recent story on estimates comes from a previous company. (I've written about them before. There are reasons I am not working for them any more.) Before I was unceremoniously shown the door, we had been discussing a rewrite of our main customer-facing website. It was basically a bank website, but for a bank that only served a few hundred clients internal to the company. The most recent version had been written a few years ago in a Python web framework that was now defunct. This time we were going to do it right using Rails. We had been talking about a 6-8 month timeframe for release of the minimal viable version once the dev team got started. We had been talking about getting started for about 3-4 months while we got sidetracked with other spot fires, upgrades, and all the other workaday delays. The team used Agile Scrum, mostly in the ways you aren't supposed to use it (meandering voluntary standups that some developers would attend at their whim, perfunctory retrospectives in which process issues were swept under the rug, systematic disregard for the definition of done and best practices, an unhealthy focus on burndown charts). There was no special business urgency behind the upgrade as far as I knew other than the old application was getting long in the tooth and looked a bit out-of-date. It was still floating beneath the surface of the backlog when I was finally walked from the building. A year or so later I got together for lunch with a couple friends still with the company including a project manager from the old team. I asked her how the big bank site rewrite was going. "Oh, it's about where it was when you were still working there. Except now it's urgent." She was not happy. The banking unit had signed up some new customers who were outside the bank and the dev team's boss said executives were eager to integrate them into the new online system. So he asked my friend, as product owner, to give him an estimate on when the new site would be ready. My friend told him she'd get back to him on it. She logged into their project management system, filtered out all the non-essential user stories for the project, added up the sizing on the essential ones that were left, and then formed an estimate based on the team's average velocity over the last few sprints. Then, just to be safe, she removed a couple more stories that probably were essential to the MVP, added up the new total, bumped up the team's velocity a few points on the reasonable premise that they were inveterate slackers, and updated her final estimate. She then met with her boss to present her results. She premised her estimate by outlining her methodology. She reminded him that the last version had taken over a year to complete. Then she dropped the number: "Six months." "Too long. We need to have it ready in three months." My friend looked at him slack-jawed. "I don't think that's possible." She started to review her methodology. He stopped her. "It is possible." "How?" "Double the team's velocity." This guy had been the one who had championed scrum to the company. He had hired the consulting firm that ran the three-day scrum on-site workshop that had introduced the principles of Agile Scrum in detail to the company. He had attended the workshop. We all had. Twice! My friend found a new job and left the company within a month.