ADN Columbus 2013 - Agile Estimation

592584d72beaaf975fd22f241870fbfc?s=47 Improving
August 20, 2013

ADN Columbus 2013 - Agile Estimation

592584d72beaaf975fd22f241870fbfc?s=128

Improving

August 20, 2013
Tweet

Transcript

  1. Agile Estimation? I guess. Elevating the art of guesswork

  2. When can I have it? How much will it cost?

    What will I get?
  3. But They’re Really Asking Can we get this to market

    before … — The competition does? — Customers ask for something else? — I change my mind? — The market shifts?
  4. They Need Options

  5. Our 1st Reaction

  6. Our 2nd Reaction

  7. Fear of Commitment

  8. How DO We Answer?

  9. The Challenges

  10. The Cone of Uncertainty 100% 200% 400% 50% 25% Time

    Actual Completion Realistic Projections Typical Projections
  11. The “Confidence” Factor Earliest possible 200% Confident 50% Confident

  12. Precision 3.1415926535897932 384626433832795 3.14 3

  13. Precision vs Accuracy Precise, but … WOW, Both!! On average,

    accurate
  14. Predicting the Future

  15. Ever Moved Before?

  16. How Many Boxes?

  17. Whew, we’re done !!!

  18. Or, are we?

  19. Projects Can Be Much Like Moving

  20. Agile

  21. Agile Software Manifesto Fundamentally it is the application of continuous

    improvement and common sense to methodology www.agilealliance.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: –  Individuals and interactions over processes and tools –  Working software over comprehensive documentation –  Customer collaboration over contract negotiation –  Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
  22. Agile Software Development Manifesto Individuals and interactions Processes and tools

    over Working software Comprehensive documentation over Customer collaboration Contract negotiation over Responding to change Following a plan over That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: http://www.agilemanifesto.org 22
  23. What is “Agile” all about? — “Agile” is an umbrella term

    used to describe a variety of methods that encourage continual alignment of development with the needs and expectations of the customer. —  Extreme Programming (XP) —  Scrum Development (Scrum) —  Software Development Lifecycle (SDLC) —  Dynamic Systems Development Method (DSDM) — The Agile Manifesto provides a concise statement of beliefs held in common by the developers of these varied methods. 23
  24. How Agile Works Product Backlog Iteration Plan(s) Release Chart Iteration

    Chart(s) Release Cycle Preliminary demonstrations occur here Product release occurs here Finished work items appear as accomplishments Product
  25. Agile Planning — There are two major approaches to controlling any

    process: —  A “Defined” process model which assumes every piece of work to be completely understood. —  An “Empirical” process model which expects the unecpected by frequent observation of results. —  Agile is an empirical process model which recognizes that software by its nature cannot be completely known in advance. —  Research shows an average of 20-40% requirements change over the course of product development. 25
  26. Estimation Exercises

  27. Seats in Here?

  28. Collective Years of Experience?

  29. Conference Attendees?

  30. Different Methods Intuitively Analytically Empirically

  31. A Brave New World

  32. Agile Programming 32

  33. Inverting the Iron Triangle Fixed Estimated Resources Time Features Requirements

    Resources Time Waterfall is Plan Driven Agile is Feature Driven 33
  34. 5 Levels of Planning Daily Sprint Release Roadmap Vision

  35. Roadmap Planning Release Planning Sprint Planning Themes Epics Stories Tasks

    Daily Planning Finer Levels, Finer Detail 35
  36. Themes Epics Stories Tasks Finer Detail, Finer Estimates 36

  37. Estimating Stories

  38. User Stories 38

  39. User Stories as Units “A user story is a software

    system requirement formulated as one or two sentences in the everyday language of the user.” As a guest I would like to book a cruise. As a guest I would like to book a cruise. 39
  40. Independent Negotiable Valuable Estimable Small Testable INVEST in Stories As

    a <user>, I want <functionality> so that <benefit>. Verify that: - <condition / acceptance criteria> - <condition / acceptance criteria> …
  41. Estimating Volume

  42. Estimating Circles

  43. Estimating Squares

  44. All Shapes & Sizes

  45. Theory of Relativity

  46. Our Scale

  47. Planning Poker

  48. Why Fibonacci?

  49. Evidence

  50. Stacking the Deck

  51. Scope of Estimation

  52. Agile Practices Performed By The Team Collaborating Defining Planning Tracking

    Developing Testing Releasing Whole Team Sitting Together Stand-Up Meetings Information Radiators Sustainable Pace Ubiquitous Language Incremental Requirements User Stories Executable Requirements Estimating Vision Planning Game Release Planning Iteration Planning Risk Management Schedule Buffer Reporting Iteration Demos Root-Cause Analysis Spike Solutions Retrospectives Coding Standards Pair Programming Refactoring Simple Design Test-Driven Development Collective Ownership Acceptance Tests Test First Performance Optimization Exploratory Testing Unit Tests “Done Done” No Bugs Version Control Ten-Minute Build Continuous Integration Post-Hoc Documentation 52
  53. You Need a “Done” Checklist —  This is NOT the

    same as Acceptance Criteria —  It applies to ALL stories —  It should start with … —  All tests to confirm the story have been agreed —  All tests to confirm the story have been written —  All tests to confirm the story have been passed —  The story has no defects —  It should end with … —  The code is production quality —  The product is ready for production, if the Product Owner accepts it —  It should include … —  Whatever the team agrees is necessary to produce a quality product —  Whatever the business team agrees is necessary to make it operational
  54. Estimating Tasks

  55. Task Planning As a <user>, I want <functionality> so that

    <benefit>. Verify that: - <condition / acceptance criteria> - <condition / acceptance criteria> … <size> a Story card Task cards
  56. As a <user>, I want <functionality> so that <benefit>. Verify

    that: - <condition / acceptance criteria> - <condition / acceptance criteria> … Stories & Tasks Task #5 Task #4 Task #3 Task #2 Task #1
  57. As a <user>, I want <functionality> so that <benefit>. Verify

    that: - <condition / acceptance criteria> - <condition / acceptance criteria> … Well-Defined Tasks Task #5 Task #4 Task #3 Task #2 Task #1 Specific Measurable Achievable Relevant Time-bound
  58. Task Sizing

  59. Task Sizing

  60. Are You Gonna Be Done?

  61. Re-Estimate

  62. The Ideal Leading Indicator Knows how much work remains Knows

    how many work hours remain
  63. Forecasting the Future

  64. Velocity

  65. Yesterday’s Weather

  66. Release Burnup Chart 6.25 11 18 25.5 24 28 36

    40 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 8 Points Sprints Release Progress Cumulativ e Points Description Simple tool for Team to track progress during a Sprint. Key Characteristics "   Shows work remaining, not work completed "   Allows analysis of true Team capacity Managed by Team, ScrumMaster 66
  67. Story Point Burn-up Story Points 67

  68. A Very Cool Tool

  69. Audience Feedback 69

  70. Jack.Carter@ImprovingEnterprises.com