The Agony & The Ecstasy of Software Estimation

My lessons learned on how to make software estimation easy and painless using agile.

Transcript

1. Web: www.pcampatl.com Twitter: @pcampatl Facebook: facebook.com/productcampatlanta WEB: www.pcampatl.com TWITTER: @pcampatl #pcampatl FACEBOOK: facebook.com/productcampatlanta PRODUCTCAMP 6 SATURDAY 8.18.12
2. The Agony and the Ecstasy of Software Estimation Scott Gardner, @scottcorvus scott@corvusonline.com www.corvusonline.com
3. By following a simple consistent process, estimation can be both painless and productive.
4. But first, a quick show of hands!
5. How much time will it take? How many people will it take? When can I start? When can I finish? What is an Estimate?
6. What were we doing?
7. Estimates taking an inordinate amount of time Little to no visibility into the backlog or release Mixed processes Moving resources Challenges
8. Unit of Work Sometimes User Stories Sometimes Requirements Documents Sometimes Service Orders Challenges
9. Unit of Measurement Sometimes Story Points Sometimes Hours Sometime Calendar Days/Weeks Challenges
10. Method of Tracking Status Reports Spreadsheets Microsoft Project VersionOne Nothing Challenges
11. What really works?
12. Executive Level, Top Down Decision Apply to all teams throughout the business Hire an Agile Coach full time Transition Period Whole team training in a common location First iterations planned together in the classroom Adopting Agile
13. Players Product Owner Business Analyst(s) Scrum Master Team – Developers, DBAs, QA, Designers Fixed teams are able to get better at estimating over time Establish a reliable velocity Changing the team changes the ability to estimate and predict velocity The Scrum Team
14. Activities: Sizing Sessions Release Planning Meeting Sprint Planning Meeting Daily Scrum Sprint Retrospective Release Retrospective Adhering to the activities provides a rhythm and cadence Sizing sessions provide estimates Planning ensures that the team can accomplish the work requested Retrospectives allow introspection and improvement Scrum Activities
15. Unit of Work User Stories and ONLY User Stories Encompasses defects Acceptance Criteria Mixing units of work prevents comparing apples to apples User Stories are doable in a given iteration Small enough to estimate accurately Flexible enough to allow for changes Applying User Stories
16. Unit of Measure Story Points and ONLY Story Points Measure of complexity Definition of Done How does the team know something is complete Focusing on story points allows focusing on complexity rather than time Hours are hard to estimate while complexity is easy Teams develop velocities over time Applying User Stories
17. The product owner has the ability to call sessions whenever estimates are needed Generally 1 hour, 2-3 hours for release planning Involves the entire team required to do the work (Designer, BA, QA, Dev, etc.) Working only in Story Points/T-shirt sizes Ex: Small = 2, Medium = 4, Large = 8, X-Large = 16 Level of Effort can be extrapolated via velocity Sizing Sessions
18. Method of Tracking Rally (similar to VersionOne) Sprint Burndowns Release Burndowns Team Capacity A Scrum specific tool facilitates adhering to process. Everything is transparent Project Plans can be wrapped around the development process as necessary for non-development activities Project Planning & Tracking
19. Agile/Scrum measures progress by working code and working code only Failure to complete committed work in an iteration is visible as a change in Velocity and thus target end date Either change the scope or change the date Measuring Progress
20. Fixed teams are able to get better at estimating, planning and executing over time Picking a process, unit of work and measurement allows consistency Focusing on complexity is easier than focusing on time Measuring progress allows adjusting estimates Retrospectives allow introspection and improvement Lessons Learned
21. Great Books
22. Questions
23. Diamond Sponsor: Platinum Sponsors: Gold Sponsors: Silver Sponsors: THANK YOU!