NRWConf 2013 - Effort Estimation in Agile Projects
•
4 gostaram•2,769 visualizações
Last week I travelled to Wuppertal to participate in the community conference NRWConf 2013. With time cockpit we have been sponsors and speakers for this event for years. At NRWConf I did a conference about effort estimation in agile projects. This is the slide deck I used. Sorry for mixing up German and English. I combined two existing talks for this session and by now I couldn't find the time to translate all the slides to German.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a NRWConf 2013 - Effort Estimation in Agile Projects
Semelhante a NRWConf 2013 - Effort Estimation in Agile Projects (20)
NRWConf 2013 - Effort Estimation in Agile Projects
- 1. NRWConf 2013 Rainer Stropek Aufwandsschätzung software architects gmbh Web http://www.timecockpit.com Mail rainer@timecockpit.com Twitter @rstropek in agilen Projekten Saves the day.
- 2. Warum agil? Kunden wollen Planbarkeit!
- 3. The Problem Introduction It„s hard to plan a nontrivial project upfront Unclear requirements New technology Project complexity Limited estimation skills Stakeholders want/need upfront effort estimations Project budgets Resource planning Release planning Source: http://xkcd.com/
- 4. Waterfall Model …or variants of it (e.g. V-Model); read more in Wikipedia Requirements Specification Big Design Up Front Design Document Design Implementation Testing Product & Doc Acceptance Detailed Product Planning Requirements elicitation Software Design Carefully think through and design the end product. Testing Make sure that implemented product works how it was designed in product planning stage Maintenance Documentation Documentation Reduce dependencies on certain people/teams
- 5. Traditional Process Goal: Predictable, repeatable process It is simple, logical, and easy to understand Before you build something, you have to know what to build Save money by emphasizing up-font planning phase „Show me how you started your project and I can tell you how it will end“ Bugs found in early project stages are less costly to fix
- 6. Traditional Process Goal: Predictable, repeatable process Reduce risk by taking enough time to plan Predict features, quality, milestones, costs, etc. Well researched techniques for requirements elicitation and management including prototypes Documentation is very important Specification might be part of a contract Get independent of people/teams
- 7. Traditional Process It seams logical - what‟s wrong? All good ideas must come at the beginning A great idea in a late process cycle becomes a threat Written documentation only makes us feel safe It proves that we have worked hard, it preserves knowledge even if people change Will it be read? Is it complete? “It feels that we are spending more time writing documents than producing software” “Aha” effect Best ideas often appear during first hands-on experiences Deliver what has been asked for (“written in stone”), not what is needed
- 8. Traditional Process It seams logical - what‟s wrong? Times are changing Planning (or guessing) what the future will bring is hard, if not impossible Requirements often already change during (extensive) planning phase There is a cost in being able to repeat in a world that changes fast It is not much fun for a team A rigid, change-resistant process destroys team work “If it does not work, we just have to do it better!”
- 9. Traditional Process Many organizations are turning away from waterfall "There are two approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability... software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development.“ US Department of Defense, Acquisition Strategy Considerations, Source: Wikipedia
- 11. Reduce „Waste“ with Lean Overproduction Don„t produce more than you need Too complex, too general, too extensible, … Solution: Frequently reprioritize work based on business value Image Source: Lacey M.: The Scrum Field Guide
- 12. Project Type Stacey‟s Agreement and Certainty Matrix
- 13. Agile Myths Myth #1: Agile = Scrum There are many agile methods, Scrum is one of them Myth #2: In agile projects there is no planning „What XP teams find valuable is the collaboration, elicitation, and balancing of priorities in the planning act itself. The plans that result have a short half-life, not because they are bad plans, but because their underlying assumptions have a short half-life.” (Kent Beck, co-creator of XP) Myth #3: Agile means no documentation Remember the agile manifesto: “while there is value in the items on the right, we value the items on the left more”. Essential documentation is still valuable for customers, partners, and cross-team dependencies
- 14. Agile Myths Myth #4: Agile means no up-front design Technical excellence and good design are key. However, value responding to change more than sticking to your original plan. YAGNI (You ain‟t gonna need it) is dangerous if change is forseeable (see also Boehm B., Turner R.: Balancing Agility and Discipline)
- 16. Planung in agilen Projekten Methoden, Tools und Tips
- 17. Release Planning Adaptive vs. Predictive Process Very detailed plan about short-term work Shared across entire team We know exactly what we are going to do next week We have an idea of where we are going to invest time in the following month Mid-term: Committed stories/features We have a mission statement for the release in six months Regularly shared/revised with business Time Iterative approach instead of big up front planning Long-term: Strategic level, range of functionality Continuously revised throughout the project
- 18. Tools Sprint Planning Tools Whiteboard Software support for backlog management Easier to use if not collocated
- 19. Team Foundation Server/Services Work item management integrated with source control, build, and test
- 22. Effort Estimation Principles User Stories „As a […] I want to […] so that […]“ Story Points „T-Shirt Sizing“ Use a XS story as a reference Estimation Remaining work in hours How long does it take to build something moreor-less unknown? Use story points to express relative complexity Try to learn about the team„s velocity „Done“ story points per sprint If necessary use a small reference story for velocity prediction Constantly track project„s progress
- 23. Burndown Chart Monitor Progress Burndown chart not a mandatory artifact in Scrum Still popular in many Scrum teams Source: Lacey M.: The Scrum Field Guide
- 24. Definition of „Done“ „Done“ Checklist Shared understanding of what it means for work to be complete Definition of “Done” will expand to include more stringent criteria for higher quality over time Source: Lacey M., How Do We Know When We Are Done?
- 25. What„s a Story? Source: Lacey M.: The Scrum Field Guide Story Decomposition Epics Importance of grooming Describes the smallest action that a user would typically want to do, or it is the smallest piece of functionality with business value Tasks should be completed in no more than two days
- 26. Release planning Planning the Unknown Inputs An estimated, ordered, and prioritized product backlog The team velocity A sprint timeline Source: Lacey M.: The Scrum Field Guide
- 28. Schätzen Die Grundlage für Planung
- 29. Begriffe Unterscheiden Sie zwischen Schätzungen, Zielen und Zusagen
- 30. Ziel planen „Wir schätzen, das Projekt in zwei Monaten fertig zu stellen“
- 31. „Die Zentrale will, dass das Produkt Weihnachten am Markt ist. Wir planen, das Projekt bis dahin abzuschließen“ Zusage, keine Planung oder Schätzung
- 32. Begriffe „Wir schätzen, das Projekt zu 75% in zwei Monaten und zu 15% in drei Monaten fertig zu stellen. Zu 10% dauert das Projekt länger.“ Entscheidungen im Geschäftsleben sind oft Wetten Messungen und fundierte Schätzungen reduzieren Unsicherheit Wir „wetten besser“, reduzieren unser Risiko
- 33. Schwarze Schwäne Geschichten sind keine Tests oder gar Beweise! Narrative Verzerrung (narrative fallacy) Das nachträgliche Schaffen einer Erzählung, um einem Ereignis einen plausiblen Grund zu verleihen. Das unbekannte Unbekannte Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
- 34. Schätzen Experiment Wie breit ist ein Airbus A380 von Flügelspitze zu Flügelspitze? Glücksrad, auf dem 9 von 10 Feldern gewinnen Bildquelle: http://www.flickr.com/photos/larssteffens/9330768928/
- 35. Schätzen Experiment Ein Haus, das so hoch ist wie ein Airbus A380, gilt in Deutschland als „Hochhaus“ Bildquelle: http://www.airbus.com/aircraftfamilies/passengeraircraft /a380family/a380-800/specifications/
- 36. Estimation Quiz How good are your estimation skills 40,007km 9.58s 30.2 million km² 1929 8,611m 354,7 million km³ $94 million 6,758km 42 years 9.8m
- 37. Schätzen
- 38. Schwarze Schwäne Wir sind in Hinblick darauf, was wir glauben zu wissen, nachweislich arrogant. Epistemische Arroganz = Überschätzung des Wissens und Geringschätzung des Nichtwissens und der Intuition Überschätzen wir unseren Einfluss und unterschätzen wir den Faktor Zufall? Experten können ihr Wissen oft noch schlechter Einschätzen, als Amateure. Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
- 39. Schätzen Fermi-Methode Wie groß (hoch) ist ein Elefant? 3-4m, largest one was 4.21m large and 10.39m long (Source: Wikipedia) Bildquellen: http://www.flickr.com/photos/moe/1981942682 http://www.flickr.com/photos/travel_aficionado/22 00003879/
- 40. Schätzen Beispiel: Messen des Erdumfangs durch Eratosthenes Alexandria und Syene, bekannter Abstand von 5.000 Stadien Durch den Winkelunterschied der Schatten ermittelte er den Erdumfang auf 3% genau Oft stehen einem mehr Daten zur Verfügung als man braucht, weitere nützliche Daten sind leichter zu ermitteln als man denkt. Bei großer Unsicherheit sind bereits grobe (aber fundierte) Schätzungen eine große Hilfe Bildquelle: http://de.wikipedia.org/wiki/Eratosthenes
- 41. Schätzen In Schätzmodellen beeinflussen oft wenige Variablen das Ergebnis massiv Ein Mess- oder Schätzwert kann dann von hohem Wert sein, wenn der Grad an Unsicherheit hoch ist und eine falsche Entscheidung teuer wäre Hier ist Messaufwand gerechtfertigt! Prototypen, Machbarkeitsstudie n, externe Experten
- 42. Value of Information Eine Information hat keinen Wert, wenn... ...man davon überzeugt ist, dass sie sicher falsch oder ganz sicher richtig ist ...eine falsche Entscheidung keine Kosten verursacht ...man sowieso keine Optionen hat Eine Information hat einen geringen Wert, wenn... ...man relativ sicher ist, dass die Information falsch oder richtig ist. ...eine falsche Entscheidung wenig Kosten verursacht ...man nur wenige Optionen hat Eine Information hat einen hohen Wert, wenn... ...der Entscheidungsträger sehr unsicher ist (wirft eine Münze) ...eine falsche Entscheidung ernste Konsequenzen hat ...mehr Optionen man zur Verfügung hat
- 43. Statistik Ein wenig Statistik ist (richtig angewendet) sehr hilfreich… Bildquelle: http://www.flickr.com/photos/marfis75/2957215903/
- 44. Hubbards „Rule of Five“ Hubbards „Rule of Five“: Mit einer Wahrscheinlichkeit von 93,75% liegt der Median zwischen dem größten und kleinsten Messwert eines zufälligen Samples aus fünf Elementen einer normalverteilten Grundgesamtheit Abschätzung des Risikos
- 45. Hubbards „Rule of Five“ Wie groß ist die Chance, dass ein Messwert auf dieser Seite der Kurve liegt? 50% Wie groß ist die Chance, dass fünf aufeinander folgende Messwerte auf dieser Seite der Kurve liegen? 50% * 50% * 50% * 50% * 50% = 3,125% Wie groß ist die Chance, dass auch der zweite Messwert auf dieser Seite der Kurve liegt? 50% * 50% = 25%
- 46. Schwarze Schwäne Die Zukunft ist nicht vollständig berechenbar Auf kleinster Ebene wegen Heisenberg, auf großer Ebene wegen Komplexität großer Systeme) Statisch ermittelte Wahrscheinlichkeiten sind kritisch zu hinterfragen. Wir leben nicht in der Asymptote sondern in der realen Welt. Ludische Verzerrung Glaube daran, dass der strukturierte Zufall, wie er in Spielen anzutreffen ist, dem unstrukturierten Zufall im Leben gleicht Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
- 47. Estimating Costs Operational Costs/RGU [€] Statistics Statistics can be dangerous Endless potential for e.g. unforeseen problems Natural minimum How to estimate when agile?
- 48. Statistik Mediokristan Extremistan Zitat: Taleb: Der Schwarze Schwan Bildquellen: http://www.flickr.com/photos/akc77/3370167184/ http://www.flickr.com/photos/thomashawk/337323578/
- 49. Schwarze Schwäne Als Menschen tendieren wir dazu, Zusammenhänge zu sehen, wo keine sind. Unser Bedürfnis nach Ordnung führt uns in die Irre. Positive schwarze Schwäne suchen und negativen aus dem Weg gehen. Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
- 51. EVM Earned Value Management You have to “earn” your project‟s budget by completing scheduled work Definition of Done Backlog PV
- 52. EVM Earned Value Management You have to “earn” your project‟s budget by completing scheduled work Definition of Done Backlog PV
- 53. Tipps Aufwandsschätzung in agilen Projekten
- 54. Estimation Tips Agile does not work without trust Build trust with honest communication Importance of a „done“ checklist Establishing a good project reporting practice is important and many teams struggle with it Agile project management does not eliminate the need for upfront planning Build Engineering into Product Backlog Make sure that all stakeholders (including budget owners) understand the idea of agile development
- 55. Estimation Tips Learn to Say "I Don't Know“ If you have very limited data, try to resist the (internal or external) pressure to set estimation intervals too narrow If you are forced to estimate, answer with a range where you set the interval wide enough Don't Do the Opposite And Always Say "I Don't Know“ Evaluate Your Estimation Accuracy „Software companies provide estimation training opportunities through their database of completed projects” (Jorgensen, 2002)
- 56. Estimation Tips Become a Domain Expert and Benefit From Economy of Scope Try to withstand the tendency to over-estimate your ability to predict the future Be Prepared Avoid penalties for late delivery that can ruin you. Try to benefit from being unexpectedly productive, don't lose too much money if you run into unexpected problems. Avoid agreements where you can win a little and lose a lot.
- 57. NRWConf 2013 Rainer Stropek software architects gmbh Fragen? Mail rainer@timecockpit.com Web http://www.timecockpit.com Twitter @rstropek Danke fürs Kommen Saves the day.
- 58. is the leading time tracking solution for knowledge workers. Graphical time tracking calendar, automatic tracking of your work using signal trackers, high level of extensibility and customizability, full support to work offline, and SaaS deployment model make it the optimal choice especially in the IT consulting business. Try for free and without any risk. You can get your trial account at http://www.timecockpit.com. After the trial period you can use for only 0,20€ per user and month without a minimal subscription time and without a minimal number of users.
- 59. ist die führende Projektzeiterfassung für Knowledge Worker. Grafischer Zeitbuchungskalender, automatische Tätigkeitsaufzeichnung über Signal Tracker, umfassende Erweiterbarkeit und Anpassbarkeit, volle Offlinefähigkeit und einfachste Verwendung durch SaaS machen es zur Optimalen Lösung auch speziell im IT-Umfeld. Probieren Sie kostenlos und ohne Risiko einfach aus. Einen Testzugang erhalten Sie unter http://www.timecockpit.com. Danach nutzen Sie um nur 0,20€ pro Benutzer und Tag ohne Mindestdauer und ohne Mindestbenutzeranzahl.
Notas do Editor
- Beispiel Investitionsentscheidung in einem Stearing Board Meeting:Innovationsprojekt, das vage von „Erhöhung der Kundenzufriedenheit“ sprichtInvestition in eine neue Maschine, die Stückkosten für Produkt X um 7% reduziert
- Ziele verkleiden sich oft als „Einpunkt-Schätzungen“
- Versprechungen sind keine Planung.Versprechungen, Schätzungen und Planung beeinflussen einander.
- Schätzungen sind mit Wahrscheinlichkeiten zu hinterlegen.