Evidence Based Planning

#EvidencePlan #EstimatesAreBS
slides.com/scottconnerly - more talks
 

A Practical Guide to #NoEstimates

Pre-req: Great Product & BA Team

• Stakeholder requests a feature, provides a brief if we’re lucky.
• Level 0 (L0) Estimate: Based on our meager understanding, we find similar shaped features in our past, note their L0 guesses.
• Product team does all their Envisioning, Definition, & Translation phases to turn the request into workable tickets.
• We count those tickets and kick off development.
  

A Perfect Storm of Needs

• Sales need dates
• Managers need staffing plans
• Project managers need to assign epics to teams
• Devs need room to dream, brainstorm, and solve problems
  

Look for

• The word “and” 
• A list? Bullets? Commas?
• Tech Debt pre-req? “Make the change easy, then make the easy change.”
• Multiple major data models. Scope epics as if you’re designing for a microservice system, even if you aren’t.
• System actions downstream of user actions.

Build a list of historical gotchas

• Empty states
• Loading states
• Error handling for every user event
• Handling legacy data
• Timezone & DST considerations
• Deployment considerations
• etc

Example 13-point ticket from a snail mail mail-merge epic from 2014

“Label size & repetition handling”

Several 1-point tickets

• Establish Avery label size ENUM for FE
• Layout label size selection dropdown on create/edit views
• Enable label size selection dropdown on create/edit views
• Display error if no size selected
• Write migration to add label size field to `mailing_label` table
• Establish Avery label size ENUM for BE
• Add label size to MailingLabel model (property, getter, setter, update)
• Return label size in mailing label REST responses
• Display label size in mailings list view
• Calculate number of pages based on recipient list and sheet capacity
• Layout label contents of recipient name and address
• Select fittable font size based on line length and label size
• Loop through pages that loop through labels

???

COUNTING

Evidence

• Epic burndown stuff
  • Kickoff total / Current total
  • Remaining count

Evidence

• Track the epic growth rate (53% currently)
  • Standard deviation of growth (1.14)
  • Confidence interval of growth (34%-72%)

Evidence

• Dynamic epic size projections
  • Projected total (kickoff * average growth)
  • Projected remaining (remaining * average growth)
    

Evidence

• Team’s 8wk average Epic ticket resolution rate

Evidence

• Epic date projection
  • Today + Projected remaining / Team’s 8wk average
    

Evidence

Epic ticket count

x Average epic growth rate

= Ticket projections

Ticket projections
÷ Team’s 8wk average Epic ticket resolution rate
= Epic date projection

Updating the Projection

Update the the date projection weekly.

As you hit development thresholds, communicate updated date projections to stakeholders:

• At 10% complete, call it a “Level 1” projection
• At 50% complete, call it an “L2” projection
• At 90% complete, call it an “L3” projection