Agile Estimation And Planning Part I
•Download as PPTX, PDF•
1 like•530 views
Agile estimation and planning focuses on iterative development with short planning cycles. Teams work together in short iterations to deliver working software. Planning occurs through story mapping and estimation rather than detailed Gantt charts. Constant inspection and adaptation allows teams to respond to changes rather than rigidly following a predefined plan. Traditional waterfall planning fails because it relies on overly optimistic estimates far into the future and does not adapt to new information learned.
More Related Content
What's hot
What's hot (20)
Similar to Agile Estimation And Planning Part I
Similar to Agile Estimation And Planning Part I (20)
Agile Estimation And Planning Part I
- 1. Agile Estimation and Planning Kevin Zamora
- 2. Credits • Based on “Agile Estimating and Planning” by Mike Cohen • Wikipedia
- 3. Key Questions • What is Agile? • How do we use it to estimate & plan for projects?
- 4. What is Agile? Wikipedia Definition - a group of software development methodologies based on iterative and incremental development ……. Which begs the question – Why am I interested in it?
- 5. Agile Report • 35-45% of IT companies are now adopting agile according to a Forester report, 2010. • Numerous books and articles appearing all over the place about Agile processes. • Even DOD is adopting Agile methods - “March 2009 Defense Science Board Task Force report”.
- 6. Traditional Development Style (SDLC) “WATERFALL” MODEL (Predictive)
- 7. Waterfall vs. Agile Waterfall Agile Release Release I1 I2 I3 I4 .. Req. Req. Req. Req. Req. Des. Des. Des. Des. Des. Imp. Imp. Imp. Imp. Imp. Ver. Ver. Ver. Ver. Ver. Mai. Mai. Mai. Mai. Mai.
- 9. Gantt Chart (MS Project)
- 10. Problems with Waterfall • Heavily regulated • Regimented • Micromanaged • Uses “Tools” to drive process • Predictive – “Can’t adapt to change easily”
- 11. Waterfall Roles (mimic assembly line) Requirements Analysts Architects Design Implementation Developers Verification Testers Maintenance
- 12. Agile Development (Adaptive and Iterative) Requirements Analysis & Design Implementation 0 Planning Deployment Initial Planning Evaluation Testing
- 14. The Agile Manifesto Values (2001) • Individuals and interactions over processes and tools (1). • Working software over comprehensive documentation (2). • Customer collaboration over contract negotiation (3) . • Responding to change versus following a plan. What is Agile?
- 16. Agile Teams • Work as one Team • Work in short iterations • Deliver something each iteration • Focus on business priorities • Inspect and adapt to change What is Agile?
- 17. Teams Work As One (with Roles) • Product Owner • Customer • User • Developer • Project Manager What is Agile?
- 19. Work is split into short iterations • Each iteration contains its own requirements and architectural design. • Iterations are time boxed (meaning they finish on time even if functionality is dropped). Time boxes average 2-4 weeks. • Iterations combine to form releases. • No grand delineations of phases with up-front requirements and architectural design. What is agile?
- 20. The Cone of Uncertainty (1998) 1.6x During the feasibility phase, a project estimate 1.25x can be off as much as 1.15x 60% to 160%!! Project 1.1x Schedule x 0.9x 0.85x .8x 0.6x Initial Approved Requirements Product Detailed Accepted Product Product Spec. Design Design Software Def. Def. Spec Spec
- 21. Focus is on Business Priorities • Delivery specified by the business owner. • Release based on the teams capabilities. • Features written to minimize dependencies. • Focus is on delivering user-valued features (stories) rather than completing tasks . E.g.. “As a <type of user>, I want < this capability> so that <I get this business value>”. • Verbal conversations over written instructions. What is agile?
- 22. Stories
- 24. Iteration planning done with note cards on a wall (low tech). Story Tasks As a coach, I can Determine rules Specify acceptance tests assign swimmers to who can swim in to show how this should events for a meet. which events work 8 6 Design user interface Code user 16 interface 8 Specify Change view- As a swimmer, I can acceptance only update my tests. 5 demographics demographics. page to allow edits 6
- 25. Constant Introspection and adaptation • The plan is not a guarantee of what will happen ! • Personnel may leave. • Technologies may NOT work as expected. • Each new iteration incorporates knowledge from the previous iteration successes and failures and adapts accordingly. • Change is viewed positively versus negatively. What is agile?
- 26. Why planning fails • Planning is by Activity rather than Feature . • Activities Don’t Finish Early (Parkinson’s law). • Lateness Is Passed Down the Schedule. • Activities are not independent. • Multi-tasking Causes Further Delays. What is agile?
- 27. Effect of Multitasking on Productivity 90 80 70 % 60 Time 50 on 40 Tasks 30 20 10 0 1 2 3 4 5 # of Concurrent Assigned Tasks
- 28. Why Planning Fails (cont.) • Features Are Not Developed By Priority • We ignore Uncertainty. • Estimates Become Commitments.
- 29. Why planning fails (continued) • Frequently reduced to a single date. All assumptions and expectations that led to that date are forgotten! • Accuracy decreases rapidly the further we attempt to plan beyond the current horizon (1). • Over planning leads to a false sense of security(2). • Fails to recognize and use knowledge learned along the way (3).
Editor's Notes
- What my motivation is to talk about this topicQuestions to ask audience?Has anybody had a problem estimating and making schedules?What processes do people usually use to define a project? Work Breakdown structure then they put it in a Gantt ch, etc.What questions do managers ask you when you start a project? How long is it going to take?
- Waterfall is a planning based model!When might we want to use this model?Hardware oriented model (Based on Manufacturing & Construction Industries in which changes are highly costly) adapted for software.
- Agile – Incremental and Iterative Development (more later)
- 1) Waterfall does not define priorities!2 ) McConnell shows that a bug found in the early stages (such as requirements specification or design) is cheaper in money, effort, and time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that "...a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time3) Time spent early on making sure requirements and design are correct saves you much time and effort later. 4) A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. Helps if people leave!! Government contracts often require the use of Waterfall method.5) Some prefer the waterfall model for its simple approach and argue that it is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process.6) Large amount of time and resources spent designing wrong product (Did we use up the budget?)7) Steve McConnell (Code Complete) notes its impossible to smoothly go from one phase to another. 8) “Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.” A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.9) US Department of Defense, now has a preference against waterfall type methodologies, starting with Mil-Std-498 "clearly encouraging evolutionary acquisition and IID (Incremental and Iterative Development)".[6]The current DoD Standard 5000.2, released in 2000, states a clear preference against 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.“11) According to The Standish Group’s 2009 Chaos Summary, 68% of all IT projects are either late, over budget or both.
- “Distinct” division of roles2) After performing role, next work to be done “Thrown over the wall”
- Feedback gives us a solid knowledge of 2 concepts:Whether we’ve done the right thing and whether we’ve done it right. We want to know this as early as possible.
- 1 - Individuals over processes and tools - people are self-organized and self motivated. They are also co-located (Face-to-face conversation is the best form of communication (NO OUTSOURCING!) ) and accomplish activities in pairs (why pairs?).2- Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.3 – Not good for Ken PettitCustomer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.Continuous attention to technical excellence and good designSimplicitySelf-organizing teams
- "Agile tends to work better on certain types of projects and in certain types of organizations with certain types of technologies."
- That is why the customer is counted as a member of the Agile team!All of this engenders a positive and collaborative working relationship between the developers and the customer. In the end, the team (both developers and customer) own the plan and are responsible for its success. When corrective action needs to be taken, there are no fingers to point. “Our plan is wrong. We need to do something about it.”Most software developers appreciate the trust and respect that is implied when management empowers them to operate as a self-directed team.
- - No cubicles
- Stories are “lightweight”No mandatory syntaxAs a book buyer, I want to search by ISBN number, so that I can find the right book quickly.
- Is there a problem with this? Yes and No. Scaling is an issue.Numbers inside boxes represent “days”.
- Another productivity-enhancer is that Agile developers focus on working to “pay down” technical debt. Technical debt takes many forms on software projects, including these:• Technical questions or unknowns that are left unresolved. Agile developers will attack these things early in the project to eliminate the uncertainty that can balloon into missed deadlines.• Design errors that are left uncorrected. Agile developers will refactor working code to keep it malleable so they can continue incremental development, rather than coding around problems and postponing the day of reckoning.• Testing left for later. Agile developers fully and completely test their code as they write it, and do not consider coding to be “done” until all tests pass. They do not count on testers or anyone else to catcher their defects, which can result in protracted testing phases at the end of the project.
- The changing business environment might impact the value proposition for the project, causing management to allocate more or fewer resources, rearrange priorities, extend or contract the timeline, or even suspend or cancel the project.
- An estimate is a probability. Therefore a commitment cannot be made to a probability.Commitments are made to dates!
- 1 (unknown factors: people, new technologies, customer).2 (We can’t be wrong, can we?).3 to further answer the questions “What do we build?” and “How long will it take?”