stories – Agile Dialogues

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.

Successes
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)

Successes

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.

Failures
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

Failures

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