Successes and Failures

We explored the success behind our approaches, both when we estimate and we decided not to…  We posted where we saw these work (and not) and told stories about them, pulling out key characteristics for future thoughts.


With Estimates Without Estimates
  • Incremental change to existing functionality
  • Clear visibility to team on what and how they do things
  • Teams are normally good at point estimates of complexity
  • Provided useful tool to the business to negotiate priority
  • Estimated branch’s annual budget with a low fidelity estimate
  • Discussion of size can lead to a better understanding of complexity
  • Predicted lead-time and cost based on actual data
  • Embedded team:
    • project plan
    • estimates
    • hitting dates regularly (team built in a good amount of slack)
  • Stronger focus on business priority
  • Faster turn-around of issues
  • Faster planning sessions
  • Kanban team:
    • established rate (stories/week)
    • decomposed release backlog into stories
    • determined release date by applying rate
    • hit date within reason
  • Delivered on time and under budget
  • Team raising more questions and uncovering issues
  • Saved time and effort not using estimates of time/effort in maintenance (using Kanban)
  • Keeps customer engaged with team; holds customer accountable
  • Teams establish a mental model faster
  • Shorter release planning sessions without any true loss in fidelity of the work
  • More time to code & test; fewer meetings (#nomeetings)
  • Release planning; impact identified earlier (before it came to the team)


Likewise we also explored failures on both sides. We had less failures in the #noestimates which we jokingly said proved it was better, but putting the joke aside, it most likely stemmed from the fact most of our audience had not gone that route.


With Estimates Without Estimates
  • Longer than necessary debates about size
  • Estimating line items in an Excel sheet of requirements w/LOE in hours
  • Difficult to Forecast
  • Very bad at estimating time for tasks
  • Estimates happen, but not responded to  i.e. work only gets added, but not removed
  • Estimates get a life of their own – used by business to obligate team, contracts, etc.
  • Disconnect between business value, effort, and time tracking
  • Large teams (16+ members) struggle with estimation
  • Not understanding the value of what is being delivered (and only looking at cost)
  • Underestimating LOE
  • Ambiguity/unclear scope delivery
  • Impact on customer relations when very wrong
  • Asked of team: “when can you have a prototype?” Answer: 2 weeks that turned into a 2 week deadline for a working system for a customer
  • People (mgmt.) wanting to make demands for a schedule rather than accepting a schedule produced by the team
  • Forecasting when a feature set can be finished
  • People don’t understand what’s going on so they jump to (usually worst case) conclusions
  • Low effect on teamwork and lack of transparency
  • Focus on learning can be lost
  • People ask: “what’s a story point?” “What if X is doing the work? Is the story points different?”
  • Acquisition mandates estimates
  • Got bogged down in a feature whose complexity wasn’t well understood
  • Unanticipated work distracting team, preventing effective use of velocity for predictions/planning