Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Agile planning and estimating
Ähnlich wie Agile planning and estimating (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile planning and estimating
- 1. Agile Planning And Estimating Responding to change over following a plan
- 2. About Me • Google Plus: +BrettChild • Blog: www.bmchild.com
- 3. Objectives •Planning in Software •Tools for Planning •Product Mapping •Release Planning •Estimating Effort •Q&A
- 4. Planning is hard 1994 1996 1998 2000 2002 2004 2009 Failed 31% 40% 28% 23% 15% 18% 24% Succeeded 16% 27% 26% 28% 34% 29% 32% Challenged 53% 33% 46% 49% 51% 53% 44% 0% 10% 20% 30% 40% 50% 60% Software Project Failures and Successes Standish CHAOS Reports
- 5. Why Plan? •Reduce Risk •Reduce Uncertainty •Support Better Decision Making •Establish Trust •Convey Information
- 6. Agile Planning •Focus on planning, not on the plan •Encourage Change •Plan is Easily Changed •Spread throughout the Project One of the most destructive things we do is build something that no one wants.
- 8. Product/Project Mapping • Impact Mapping • User Story Mapping
- 11. The Walking Skeleton User Tasks
- 13. User Stories
- 14. Release/Milestone Planning •Minimum Viable Product •Evolutionary
- 15. Minimum Viable Product • Eric Ries, author of The Lean Startup: “A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” • Customer interviews • Demo page • Teaser links • Release 1.0 • Concierge MVP • Wizard of Oz MVP
- 16. BetterUX.it • A Community where startup founders can get expert feedback from UX designers. http://www.smashingmagazine.com/2014/04/10/a-guide-to-validating-product- ideas-with-quick-and-simple-experiments-2/
- 17. BetterUX.it “Bootstrapped startup founders have trouble getting UX feedback because they have no reliable sources to turn to.” • Release 1 • Interview startup founders
- 18. BetterUX.it “Would they pay for an online service to get feedback from UX designers?” • Release 2
- 19. BetterUX.it “Would designers consult with startup founders?” • Release 3 • Interview designers
- 20. BetterUX.it “Would new designers consult with startup founders?” • Release 4
- 21. Evolutionary
- 22. Estimating Effort •Story Points and Velocity •Planning Poker •Affinity Planning
- 23. Story Points and Velocity • Story Points: Relative size/complexity to other stories • Have no other purpose other than planning • .5, 1, 2, 3, 5, 8, 13, 20, 40, 100 • Velocity: how many story points can be completed in an iteration • Historical data -> running average • Generally takes about 3 iterations before the velocity stabilizes for a new team
- 24. Story Point and Velocity • Example: • We have a backlog of these tasks • 6 tasks @ 1 point each = 6 total points • 8 tasks @ 2 points = 16 total points • 36 tasks @ 3 points = 108 points • Grand total of 130 points • Our team velocity averages 50 points for each 2 week cycle • How long will it take us to complete the 108 points? • 130 / 50 = 2.6 iterations * 2 weeks = 5.2 weeks
- 25. Planning Poker • Agree on an anchor • Good to allow in depth conversation about a story • Takes more time
- 26. Affinity Estimating • Useful for large amounts of stories • Generally done silently • Very fast
- 27. Review • Planning in Software • Tools for Planning • Product/Project Mapping • Impact Mapping & User Story Mapping • Release/Milestone Planning • MVP and Evolutionary • Estimating Effort • Story Points, Velocity, Planning Poker, and Affinity Estimating
- 28. Resources • Agile Estimating and Planning by Mike Cohn • Impact Mapping: http://impactmapping.org • User Story Mapping: http://winnipegagilist.blogspot.com/2012/03/how-to-create- user-story-map.html • MVP: http://practicetrumpstheory.com/minimum-viable- product/ and http://www.smashingmagazine.com/2014/04/10/a-guide-to- validating-product-ideas-with-quick-and-simple-experiments- 2/
Hinweis der Redaktion
- Java developer at STGStudent of Agile and process management for about 5 yearsSeen Code and product quality improve + people’s attitudesThis presentation + notes will be on STG’s training blog and my personal blogFeedback on the presentation but also watching it over G+
- Planning in software is inherently challenging because it is complexFactors of complexity:Abstract Ideas: not tangible, generally not measurableRequirements: not fully known upfront, change as project progressesIT Systems: software + hardware. Complex and prone to failurePeople: no 2 people are equal, our performance varies day to dayPossible points of failure: late, overbudget, not valuable
- Reduce RiskProvide insights into risksWhat is unknown? Spend time learning about itIs it too risky?Reduce UncertaintyMake sure we are developing the right thingAgile helps up use what we learn to reassess our directionDecision MakingEstimates and plans help us know which projects are worth pursuing and which ones may not beTrustReliably delivering as we planned helps build trust with our customersIt also builds trust with developers and better quality productsConvey InformationDescribes a potential outcome and the reasoning behind itA single date is not really enough information
- PlanningA plan shows you what you knew, planning shows you what you now know and what you need to knowExample of driving to the grocery storeEncourage ChangeMike Cohn describes a failed project as “ a project on which no one came up with any better ideas that what was on the initial list of requirements.”Easily ChangedDon’t let your process get in the wayIf you stifle innovation chances are you are stifling a successful project2/3 of all successful products drastically changed their plan throughout the projectSpread through projectWe are constantly learning new things aboutTechnologyThe productThe marketThe user’s needsEtcetcWe need to seek out new knowledge throughout the life of the projectExample of car driving towards tornado
- Hierarchy of planningUser Story Map manages product direction and visionAnother useful tool is Impact MappingRelease Planning helps manage value deliveryWe’ll go over a couple of strategiesSprint Planning aligns the low level development effort to our business needs
- Why a map?We want to get from point A to point B. Gives us a layout of the land so we can change course if neededVisual, easy to understand
- Aligns business impacts to work that needs to be donePros: Easy to see business goalsPromotes testing assumptionsConsSometimes there is just too much information
- A second dimension to your backlogLarge and visualEasy to see progress (WIP and Done)Useful tool to manage scope and to planBecomes a focal point of planning conversationsCons: Where is the vision and the goal?Takes up a lot of spaceMay not work that well for multiple projects or maintenance
- - Things people do. High level…no detailWalking skeleton because you can walk through it to see if you missed anything
- Arranged in a logical order, from left to rightSometimes accompanied by sketches or details.Could be user type specific (admin manage email, end user manage email)
- High priority at top, low at bottomSplit into releases
- Traditional Release planning has changedNo longer until next release of software in 3-6 months…industry releases software very quicklyHow far until our next goal?From x to y by whenmeasurableWe want to make small steps so we can get fast feedbackFail fastStay within bounds of time, budget, and valueWe want to validate our assumptionsExample of gaming website…A company assumed spending 7 months building an rewards and sharing program would get them to 1M users
- “Product” is a misnomerMay not be tangible or even visible
- An idea fostered by designer and entrepreneur Grace NgTraditionally we’d start listing out features, order by priority and then start building.
- - Within an hour 10 people had paid
- - Established designers were picky about new clients. New designers were not.
- Designers also had a simple form to fill outGrace would manually send form entries back and forth between founders and designers until the load became too much. She then scaled to an automated process.MVP is a quick way to validate our ideas
- Mile wide, inch deep. Something is always working.Traditionally our larger feature setsGood way to validate architecture.Could focus more on user scenarios
- We’re generally pretty bad at figuring our how large something isWe are pretty good at telling if something is bigger or smaller than something else
- SP & Velocity is how we can estimate and forecast how long future work will takeStory Points:Are not meant as a indicator of performance…too easy to gameLarger gaps among the larger numbers account for the unknownSmaller estimates will be more accurate…if too big break them out to more storiesFrom velocity we derive how long it takes to complete