2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2025 To Be Agile
- September 17, 2015
- Rants
I consider myself a supporter of the #NoEstimates hashtag. It’s not that I think estimates are evil, it’s just they’re often unneeded or misapplied. If the effort to estimate a task is equal to the effort required to complete the task then is an estimate worth it?
Estimates can be useful for measuring capacity or how much work a team can accomplish in a short period of time. In the past, I’ve estimated work in terms of ideal days. An ideal day is how much work can be accomplished in a day with no interruptions. Because we’re human we can’t utilize every moment to be productive so we generally say an ideal day is equal to about two real days. This may seem reasonable but there’s a major flaw with it that I didn’t realize until just recently.
When estimating in days (ideal or otherwise) we put an upper limit on how much work we can get done. When I say a task will take me seven days to complete, I’ve locked myself in to how long it will take.
Instead of sizing the time to complete a task, try sizing the *effort*. Find the easiest story in your backlog, what everyone agrees is trivial, and give it a value of 3. Then rank other stories relative to that one in terms of effort to complete. Use the Fibonacci series (1, 2, 3, 5, 8, 13+) to rate relative effort. You’ll find the amount of effort to accomplish a 3 will change over time and that’s fine. As a team’s abilities improve what was an 8 may become a 3. It doesn’t matter. What does matter is how much work the team can accomplish in this iteration.
By estimating effort instead of time to accomplish a task we increase our short term accuracy. At the same time, we decrease our ability to compare estimates through time or across teams. We should never do those things anyway. Estimates can be used to measure capacity and should never be used to measure productivity. It’s easy to misuse estimates or treat them like commitments but they shouldn’t be used in this way.
I was at a presentation recently that was filled with XP developers and the presenter showed two burn down charts from two different teams. Despite the fact that we all should know better we couldn’t help but compare the two teams. Then someone noticed that the scale on the charts were different. “Can we compare trends?” someone asked.
Let’s face it, we’re inference machines, we can’t help but find patterns, draw conclusions, etc. It’s what makes us human and it’s not so easy to turn off when we know we shouldn’t try. Some of the top teams I know don’t track velocity. How about your team? Do you track velocity? Do you use it in any other way than to measure how much work can be done in the next sprint? Is it worth it?
Previous Post: « Requirements Aren’t Required
Next Post: What Managers Must Understand »