Estimating software projects, feature delivery dates, and even task completion times are notoriously difficult and unwieldy even for experienced teams. Guessing the future in terms of gut feeling or past experiences is a hit or miss practice that often leaves teams working overtime to meet unrealistic deadlines. Some simple metrics tracking borrowed from Lean software development can help. In this session, you'll learn very simple techniques that enable you to project timelines and determine probabilities that are based on a team's actual performance instead of a guess.

1. LEAN METRICS
HOW TO PREDICT THE
FUTURE
Phil Ledgerwood
PowerPoint is Terrible and I‟m Sorry

2. PLATINUM SPONSORS
GOLD SPONSORS
SILVER SPONSORS

3. Phil Ledgerwood
Application Developer
Netchemia, LLC
www.Netchemia.com
Twitter: @pledgerwood
LinkedIn: http://www.linkedin.com/in/philledgerwood

4. The Estimation Process

5. Let‟s Play a Game
 How long does it
take you to go to the
store to buy
bananas?
 Traffic?
 Accident?
 Johnson County
moms talking in
aisle?
 Person in front of
you pays with check
and has no id?
 Yes, we have no

6. Your Estimates Suck
Because…
 They are based on your view of your own
productivity.
 They assume all unknowns take zero time.
 You have never written that software before.
People are terrible estimators.

7. Stopping the Foolishness
Here Come Metrics!

8. Metrics are Awesome
Because…
 They are based on your actual productivity.
 They factor in unknowns, divergent sizes, and
when Steve goes on vacation, but he didn‟t tell
anyone he was going on vacation until like two
days before he did, and he‟s gone for two weeks
and it‟s like, oh great, thanks a lot, Steve.
 You can identify impediments visually.
They are eerily accurate
because Math.

9. Estimates vs. Metrics
 Estimates
 Based on guessing
 Deviate over long
timespans
 False sense of
security
 Can easily be
gamed
 Take a long time to
generate
 Up for debate
 Pretty much useless
 Metrics
 Based on actuals
 Become more
accurate over long
timespans
 Cold, hard reality
 Can‟t be gamed
 Take almost no time
to generate
 Not up for debate
 Ignore at your peril

10. Scatterplot Diagram
The Control Chart

11. Lead Time
 Record the date something enters your
workflow and the date something leaves it.
 This amount of time is called “Lead Time”
 End points need some agreed definition
 When an item is ready for work?
 When you start work on an item?
 When an item is ready for release?
 When an item is actually deployed?
 Typical Lead Time: Ready for Work >>
Deployed

12. Control Chart Data
 Dates (or day # of project) along the X axis
 Number of days along Y axis
 Lead times are plotted on chart as items are
completed
 Median Lead Time
 Standard Deviations
 Percentages of Lead Time values (ex. “75% of
our lead times are 10 days or less”)

13. What Can This Tell Us?
 How fast we‟re
delivering
 The likelihood of an
item taking a certain
amount of time
 Predictability
 When events occur
that screw everything
up
 Trends in velocity

14. Hey Let‟s See One

15. CFD (But you could probably figure that out)
Cumulative Flow Diagram

16. Value Stream
 How things get from “idea” to “delivered”
 For developers, it usually looks something like
this:
 Analysis (Acceptance Criteria)
 Design (Automated Tests)
 Code
 Test
 Deploy
 “To Do,” “Doing,” and “Done” is ok for chore
lists, but not so good for organization workflow
management

17. Cumulative Flow Data
 Dates (or day # of project) along the X axis
 Number of work items along Y axis
 Plot stacked series of # of items in each “value
stream state” from day to day

18. What Can This Tell Us?
 Horizontal distance: Lead Time
 Vertical distance: Work in Progress (WIP)
 Slope of Top Line: Average arrival rate
 Slope of Bottom Line: Average completion rate

19. LOL WUT?
 Where are our bottlenecks?
 Where are things flowing smoothly?
 What is our predictability?
 Do we have too much WIP? Are we starting
more than we‟re finishing?

20. And I Care About This Why?
 “Improvement comes by managing flow, not
trying to get faster.” –Phil Ledgerwood, Just
Now, 2013
 Improve the flow, and the speed will come.
 How do you improve flow?
 Limit WIP
 Give love to the area that needs it most
 Look at what is skewing the lines and respond

21. Hey Let‟s See One

22. What Metrics Don‟t Tell You

23. Metrics Tell You What, But Not
Why
 Charts and numbers are a catalyst for
conversation, not a substitute for it
 You cannot manage “by the numbers”
 Data is not a substitute for cultural analysis,
critical thinking, people‟s stories, or just being
in the trenches.
 Data can show you your trends and provide
fodder for discussions, but productivity and
workflow is ultimately a people issue.

24. Appendix A: The Retrospective
 Are you tired of retrospectives being free form
whine sessions? I am also tired of it. Your
whining, I mean.
 The metrics represent your current state.
 Ask the team what a better state would look
like.
 Ask the team for ideas on moving closer to
that state.
 Pick one, try it, and see if the metrics change.

25. I‟m Phil
 Phil Ledgerwood
 I work at Netchemia
 Blog: http://thecuttingledge.com/
 Twitter (rare): @pledgerwood
 LinkedIn (often):
http://www.linkedin.com/in/philledgerwood
 Ask me for a business card or something,
because, man, I‟ve got a ton of „em.