Transcript Agile
SECTZG652 : Agile Software Process Session – 01: Introduction to Agile 1 Introduction Traditional approaches of software development Need for Agile Benefits of Agile Why agile projects work better 2 Traditional Model Feasibility Study User Requirements Analysis System Design Detailed Design Coding Testing Deploy and Maintain 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Traditional approaches - Objective In the face of changing requirements, traditional project management "best practices" suggest that we try to Lock down requirements to form a baseline Implement change control and Fall back on the documented requirements or the contract as means to enforce the change control. All-at-once delivery Success of a project depends on ‘Triple Constraints’ Ending the project within schedule Finishing under budget Completing entire scope Results of projects differed based on the choice Lenient and allowing too much change to the baseline without triggering the change control processes (in the interest of customer satisfaction) - may go way over budget and may be late due to additional features being added Too strict and refusing to accept changes to the baseline. Sometimes leads to irate customers - may go over budget and may be late due to the extra work and delays 4 caused by assessing the changes to the baseline and the often contentious negotiations with the customers. Waterfall Model 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Waterfall Model Pros The model is straight forward Very formal and disciplined model The model is rigid and each of the phases has certain deliverables and a review process immediately after a particular phase is over Cons Assumes everything is predictable at once Expects all requirements to be captured upfront Changes to requirements would be very expensive Bugs are expensive to fix and new requirements are expensive to incorporate. Problems are not discovered until system testing It is not suited for long or complex projects or projects where the requirements can change You do not see a working version of the software until late in the life cycle 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Incremental Model Incremental model In incremental development, we break up the work into smaller pieces, schedule them to be developed over time and integrate as they get completed The system is developed in different stages with each stage consisting of requirements, design, development, and test phases (a waterfall) In each stage, new functionality is added Each increment should deliver something of value to the customer Allows the user to see a functional product very quickly and allows the user to impact what changes are included in subsequent releases Pros Allows for a very complex project with incomplete initial understanding of requirements since development is done in small, incremental phases where each phase consists of requirements, design, implementation and test Feedback from early increments improves the later stages Users see value early Cons Requirements should be quite stable because it is expensive to go back and redesign something that has already been delivered in a previous increment - Known a software breakage Each phase of iteration is rigid and does not overlap each other All the requirements are not gathered up front for the entire software life cycle which can create problems at the later stages in the design and development cycle 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Incremental Model Increment 1 Increment 2 Increment 3 Requirement Design Requirement Feedback Build Design Test Build Design Test Build Requirement Feedback Test 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Iterative Model Iterative model An iterative lifecycle model does not attempt to start with a full specification of requirements – It can evolve over time Development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements Value to cost ratios can be used to decide priorities This process is then repeated, producing a new version of the software for each cycle of the model Pros Allows requirements to evolve based on user feedback Customers see value at the end of every iteration Facilitates the support for changes within the life cycle Cons The communication overhead for the project team is significant It is difficult to freeze requirements, and they may continue to change in later iterations because of increasing customer demands. As a result, more iteration may be added to the project, leading to project delays and cost overruns 9 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Iterative Model Requirement Evaluation and refinement Design Initial Planning Deploy Test Build 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Need for Agile Development • Client not sure how the end • Requirements are evolutionary product should look like • Need for end user feedback for • Need for having the best features delivering better functionalities for better marketability Why Agile? • Shorter release cycles required • Identify and follow optimal processes • Improve productivity to get continuous feedback • Working software to reach the customers faster 11 Agile Model High Level Requirements Analysis (Business Requirements Domain Model) Define Program Roadmap Key Features Release …N Release 2 unclear/continuously evolving Release 1 • Release Goal • Features Identification Product Backlog Creation (High Level Feature Sets, Prioritization) • Requirements are • Requirements & Architecture Elaboration • Sprint Zero (Pre-Game Phase) Sprint …N Sprint 2 Sprint 1 Sprint Execution Planning Refine Requirements & Architecture Design By Feature Code By Feature Test By Feature Certify By Feature (UAT) Sprint Review and Closure • Release Integration • System & Performance & User Acceptance Testing Daily Standup Meeting High Level Architecture Analysis • Production Rollout • Warranty Support 12 • Unproven technology is used • Frequent customer-project team interaction • Usage of Cutting edge Technology architecture & Initial iterations may evolve architecture, UI frameworks etc • Suited for large duration projects; • Software is developed in numerous releases by globally distributed teams ;Release to production can combine one or more iterations Benefits of Agile At a strategic level, Agile benefits include Ongoing risk management: This is achieved by regularly confirming and adjusting requirements according to [17] ongoing interactions with the customer and by delivering fully functional and fully tested software features Ongoing control of budget expenditure: by providing decision makers with the opportunity to review and assess the business value of deliverables at each iteration, and with the option to adjust, postpone or stop ongoing funding based on the return on investment (ROI) of delivered work. Rapid delivery of tangible outcomes: by focusing team efforts on regularly producing fully functional, fully tested, production-ready software features that can be used by the organization well before the end of the project timeline. Strong alignment with business requirements: by directly involving the customer in the initial and ongoing review of developed software, and by incorporating their feedback throughout the process. Focus on the highest-priority features: by continually working with the customer to confirm and adjust the work undertaken by the project team to align with the most current priorities of the organization. Responsiveness to business change: by adjusting work throughout the process to incorporate organizational, industry and technology changes. Transparency in status tracking: by regularly providing tangible outputs for customer review, combined with the use of open communication forums and centrally available real-time status-tracking tools. Substantially higher-quality outputs: by incorporating rigid testing regimes throughout the process and by working regularly with the customer to confirm the usability and business value of delivered features. Greater employee retention: by creating work environments that are based on high communication, empowering the team, trusting their expertise, encouraging innovation, and regularly acknowledging their [18] contribution to the organization . Minimized whole-of-life software costs: by incorporating usability, quality and extensibility into solutions throughout the delivery process – thereby reducing both development costs and support and maintenance 13 overheads – and by providing a less risky and more cost-effective platform for additional functionality to be integrated into the solutions. Benefits of Agile Tactical benefits of Agile The production of more valuable outputs per resource hour: Earlier identification of technical issues Less rework and “throw-away” work Reduced need to create – and maintain – detailed documentation Greater flexibility Greater opportunity for innovation Reduced dependency on paper status reports Reduced demand for ongoing support and maintenance 14 Traditional Vs Agile Development Category Visibility Traditional Development Adaptability Agile Development High Involvement of client during Requirement elicitation Little or no visibility until the build is ready for UAT testing • Active involvement of client through out the life cycle Define detail requirement in advance Difficult to change requirement due to longer delivery cycles Adapt requirement at each iteration Quickly respond to business and process changes Business value • Little or no Business value is delivered until the system is complete • Deliver small usable components through out the iteration process Risk • Risk remains high until the system is delivered • Identify issues earlier in the process, eliminating risk in the earlier cycle 15 Traditional Vs Agile Development Traditional Detailed requirements are frozen before execution begins. (BDUF) The entire scope of the project is attempted to be defined in the project scope document. Agile Iterative. Only detailed requirements for an upcoming sprint/iteration needs to be frozen. The entire scope of the project is defined in a simple-to-use product backlog which has a specific owner too (product owner). Emphasis on documentation (Req., Design) Emphasis on creating working software iteratively with minimal documentation. When the project is in execution phase, for any scope change, A change management process is followed only if the sprint backlog a change management process needs to be followed. is changed. Team works as per plan passed on to them by the project Team picks up features for a sprint/iteration from prioritized release manager, managing the project goes by the intuition of project backlog and works collaboratively within themselves and with the manager client. Project Manager is more in guiding and monitoring role at the sprint level. Productivity of the team remains almost constant throughout Productivity of the team increases as the project progresses and the project duration. teams working on Agile projects prefer not to work on traditional projects. Problems in the project become visible late in the project when Problems are exposed early and the team gets the opportunity to fix the first demo is given to the client. them early in the project. Lessons learnt are discussed after the phase completes. Retrospection is done after each iteration / sprint completes. The opportunity to apply phase specific learning comes only with the next project. Client sees the end product when the project is near completion. Client does not interact with the teams and hence may have concern on not being informed if the project delays. Lessons learnt are adopted upfront in the upcoming iteration / sprint itself. Client sees the product getting built every iteration and can change/reprioritize the requirements, if business demands. 16 Product owner is up-to-date on the project status since he attends the daily standup meeting as part of the composite team. Challenges • • • • By only looking at small pieces (increments) of the software, we may have to do massive rework, which might have been avoided if we analyzed or designed the whole system correctly. We might "paint ourselves into a corner;" that is, we can get a system that is incapable of supporting some new requirement. We may be unable to add global requirements, such as alternate language support, performance, and security. A typical example is trying to retrofit "security" to an application that was not designed with this requirement in mind. We might go slower because we have to restart analysis and design sessions for each increment, instead of doing it once at the start of the project. 17 References I. Managing Agile Projects Kevin Aguanno / Multi-Media Publications 2004 (Available in Books 24X7) – Chapter 1 II. Agile Project Management for Dummies - Mark C. Layton/ John Wiley & Sons - 2012 (Available in Books 24X7) – Chapter 1 18 SECTZG652 : Agile Software Process Session – 02, 03: Basics of Agile Software Development, Principles of Agile 19 Introduction Iterative Planning Agile Development 10 Lean Best practices Agile Manifesto Agile Principles 20 Iterative Planning Risk Driven Development Chooses the riskiest, most difficult features for the early iterations High risks are surfaced and mitigated early Client Driven Development Choice of features for next iteration comes from the client Focus is on getting highest business value items implemented Adaptively plan for the next iterations based on their latest insight Client has ongoing control and choice as fresh information is available Recommended approach Both have to be applied. Client do not always appreciate what is technically hard or risky. Developers do not appreciate what has high business value 21 Iterative Planning Time-boxed Iterative Development Fixing the iteration end date and not allowing it to change Overall project may be time-boxed as well If chosen requests (scope) cannot be met within the iteration end date scope is reduced by moving out the low priority items back to the wish list No changes to be made to the scope of the iteration once it has started Team itself is allowed to reduce the scope of an iteration if the deadline cannot be met Evolutionary Iterative Development Requirements, plan, estimates and solution evolve, are refined over the course of the iterations A detailed schedule is not created beyond a relatively short time horizon and level of detail and commitment is commensurate with the quality of information Consistent with the pattern of unpredictable discovery and change in new product development Captures feedback regarding installed product and uses it to guide the next delivery Helps best meet some difficult to predict requirements Agile Development Adaptive Development Elements adapt in response to feedback from prior work – feedback from users, tests, developers, etc. Very similar to evolutionary but more onus is on the feedback response mechanism Agile Development Applies time-boxed iterative and evolutionary development, adaptive planning, promote evolutionary delivery Includes other values and practices that encourage Agility – rapid and flexible response to change Motto is to embrace change; Strategy is maneuverability Most of the Agile practices are nothing new. Instead, the focus and values behind Agile Methods differentiate them from more traditional methods Promotes practices and principles that reflect an agile sensibility of Simplicity, lightness, communication, self-directed teams, programming over documentation and more 10 Lean Best Practices – Application to Software Development Eliminate waste - eliminate or optimize consumables such as diagrams and models that do not add value to the final deliverable Minimize inventory - minimize intermediate artifacts such as requirements and design documents Maximize flow - use iterative development to reduce development time Pull from demand - support flexible requirements Empower workers - generalize intermediate documents, tell developers what needs to be done, not how to do it Meet customer requirements - work closely with the customer, allowing them to change their minds Do it right the first time - test early and refactor when necessary Abolish local optimization - flexibly manage scope Partner with suppliers - avoid adversarial relationships, work towards developing the best software Create a culture of continuous improvement - allow the process to improve, learn from mistakes and successes 24 Agile Manifesto Individuals and interaction over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is a value in the items on the right, the items on the left more are valued more Where traditional approaches emphasize a rigid plan, avoiding change, documenting everything, and hierarchal-based control, the Manifesto focuses on People Communications The product Flexibility 25 12 Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 8. Working software is the primary measure of progress 26 12 Agile Principles 9. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 10. Continuous attention to technical excellence and good design enhances agility. 11. Simplicity — the art of maximizing the amount of work not done — is essential. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly 27 Where We Are Now 17–28 • Traditional PM versus Agile Methods Traditional PM Approach – Concentrates on thorough, upfront planning of the entire project. – Requires a high degree of predictability to be effective. • Agile Project Management (Agile PM) – Relies on incremental, iterative development cycles to complete less-predictable projects. – Is ideal for exploratory projects in which requirements need to be discovered and new 17–29 Traditional Project Management versus Agile Project Management Traditional Agile Design up front Continuous design Fixed scope Flexible Deliverables Features/requirements Freeze design as early as possible Freeze design as late as possible Low uncertainty High uncertainty Avoid change Embrace change Low customer interaction High customer interaction Conventional project teams Self-organized project teams 17–30 TABLE 17.1 Project Uncertainty 17–31 FIGURE 17.1 Agile Project Management • Agile PM – Is related to the rolling wave planning and scheduling project methodology. • Uses iterations (“time boxes”) to develop a workable product that satisfies the customer and other key stakeholders. • Stakeholders and customers review progress and re-evaluate priorities to ensure alignment with customer needs and company goals. • Adjustments are made and a different iterative 17–32 cycle begins that subsumes the work of the Iterative, Incremental Product Development 17–33 FIGURE 17.2 • Agile Project Management (cont’d) Advantages of Agile PM: – Useful in developing critical breakthrough technology or defining essential features – Continuous integration, verification, and validation of the evolving product. – Frequent demonstration of progress to increase the likelihood that the end product will satisfy customer needs. 17–34 Agile PM Principles Focus on customer value Iterative and incremental delivery Experimentation and adaptation Self-organization Continuous improvement 17–35 Popular Agile PM Methods Scrum Crystal Clear Extreme Programming RUP (Rational Unified Process) Agile Modeling Agile PM Method s Rapid Product Development (PRD) Dynamic Systems Development Method (DSDM) Lean Development 17–36 Agile PM in Action: Scrum • Scrum Methodology – Is a holistic approach for use by a crossfunctional team collaborating to develop a new product. – Defines product features as deliverables and prioritizes them by their perceived highest value to the customer. – Re-evaluates priorities after each iteration (sprint) to produce fully functional features. – Has four phases: analysis, design, build, test 17–37 Key Roles and Responsibilities in the Scrum Process • Product Owner – Acts on behalf of customers to represent their interests. • Development Team – Is a team of five-nine people with crossfunctional skill sets is responsible for delivering the product. • Scrum Master (aka Project Manager) – Facilitates scrum process and resolves impediments at the team and organization 17–38 Applying Agile to Large Projects • Scaling – Is using several teams to work on different features of a large scale project at the same time. • Staging – Requires significant up-front planning to manage the interdependences of different features to be developed. – Involves developing protocols and defining roles to coordinate efforts and assure compatibility and harmony. 17–39 Limitations and Concerns of Agile PM • It does not satisfy top management’s need for budget, scope, and schedule control. • Its principles of self-organization and close collaboration can be incompatible with corporate cultures. • Its methods appear to work best on small projects that require only five-nine dedicated team members to complete the work. 17–40 Key Terms Feature Iterative incremental development (IID) Scrum meeting Scrum Master Sprint backlog Product Backlog Product Owner Scaling Agile PM Self Organizing Team 17–41 SCRUM – Agile Project Management Joint Advanced Student School Maria Belkina Jennifer Schiller Maxim Masunov Vycheslav Filippov April 2006 Agenda – – – – – – – – – – Introduction Agile Project Management What is Scrum? History of Scrum Functionality of Scrum Components of Scrum • Scrum Roles • The Process • Scrum Artifacts Scaling Scrum Evolution of Scrum Scrum & XP Conclusion JASS 2006 Agile Project Management Scrum 43 Introduction • Classical methods of software development have many disadvantages: - huge effort during the planning phase - poor requirements conversion in a rapid changing environment - treatment of staff as a factor of production New methods: Agile Software Development JASS 2006 Agile Project Management Scrum 44 Manifesto for Agile SD • Based on the Manifesto for Agile Software Development – – – – Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan JASS 2006 Agile Project Management Scrum 45 Agile Methods • Agile methods: – – – – – Scrum Extreme Programming Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) … • Agile Alliance – A non-profit organization promotes agile development JASS 2006 Agile Project Management Scrum 47 What is Scrum? Definition from rugby football: a scrum is a way to restart the game after an interruption, where the forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them JASS 2006 Agile Project Management Scrum 48 Scrum - an agile process • SCRUM is an agile, lightweight process for managing and controlling software and product development in rapidly changing environments. – Iterative, incremental process – Team-based approach – developing systems/ products with rapidly changing requirements – Controls the chaos of conflicting interest and needs – Improve communication and maximize cooperation – Protecting the team form disruptions and impediments – A way to maximize productivity JASS 2006 Agile Project Management Scrum 49 History of Scrum • 1995: – analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes – Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber – Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming • 1996: introduction of Scrum at OOPSLA conference • 2001: publication “Agile Software Development with Scrum” by Ken Schwaber & Mike Beedle Successful appliance of Scrum in over 50 companies Founders are members in the Agile Alliance JASS 2006 Agile Project Management Scrum 50 Functionality of Scrum JASS 2006 Agile Project Management Scrum 51 Components of Scrum – Scrum Roles – The Process – Scrum Artifacts JASS 2006 Agile Project Management Scrum 52 Scrum Master • Represents management to the project • Typically filled by a Project Manager or Team Leader • Responsible for enacting scrum values and practices • Main job is to remove impediments JASS 2006 Agile Project Management Scrum 53 The Scrum Team • Typically 5-10 people • Cross-functional (QA, Programmers, UI Designers, etc.) • Members should be full-time • Team is self-organizing • Membership can change only between sprints JASS 2006 Agile Project Management Scrum 54 Product Owner • Acts like one voice (in any case) • Knows what needs to be build and in what sequence this should be done • Typically a product manager JASS 2006 Agile Project Management Scrum 55 The Process • • • • Sprint Planning Meeting Sprint Daily Scrum Sprint Review Meeting JASS 2006 Agile Project Management Scrum 56 Sprint Planning Meeting • A collaborative meeting in the beginning of each Sprint between the Product Owner, the Scrum Master and the Team • Takes 8 hours and consists of 2 parts (“before lunch and after lunch”) JASS 2006 Agile Project Management Scrum 57 Parts of Sprint Planning Meeting • 1st Part: – Creating Product Backlog – Determining the Sprint Goal. – Participants: Product Owner, Scrum Master, Scrum Team • 2nd Part: – Participants: Scrum Master, Scrum Team – Creating Sprint Backlog JASS 2006 Agile Project Management Scrum 58 Pre-Project/Kickoff Meeting • A special form of Sprint Planning Meeting • Meeting before the begin of the Project JASS 2006 Agile Project Management Scrum 59 Sprint • A month-long iteration, during which is incremented a product functionality • NO outside influence can interference with the Scrum team during the Sprint • Each Sprint begins with the Daily Scrum Meeting JASS 2006 Agile Project Management Scrum 60 Daily Scrum • Is a short (15 minutes long) meeting, which is held every day before the Team starts working • Participants: Scrum Master (which is the chairman), Scrum Team • “Chickens” and “Pigs” • Every Team member should answer on 3 questions JASS 2006 Agile Project Management Scrum 61 Questions • What did you do since the last Scrum? • What are you doing until the next Scrum? • What is stopping you getting on with the work? JASS 2006 Agile Project Management Scrum 62 Daily Scrum • Is NOT a problem solving session • Is NOT a way to collect information about WHO is behind the schedule • Is a meeting in which team members make commitments to each other and to the Scrum Master • Is a good way for a Scrum Master to track the progress of the Team JASS 2006 Agile Project Management Scrum 63 Sprint Review Meeting • Is held at the end of each Sprint • Business functionality which was created during the Sprint is demonstrated to the Product Owner • Informal, should not distract Team members of doing their work JASS 2006 Agile Project Management Scrum 64 Scrum Artifacts • Product Backlog • Sprint Backlog • Burn down Charts JASS 2006 Agile Project Management Scrum 65 Product Backlog • Requirements for a system, expressed as a prioritized list of Backlog Items • Is managed and owned by a Product Owner • Spreadsheet (typically) • Usually is created during the Sprint Planning Meeting • Can be changed and re-prioritized before each PM JASS 2006 Agile Project Management Scrum 66 Estimation of Product Backlog Items • Establishes team’s velocity (how much Effort a Team can handle in one Sprint) • Determining units of complexity. – Size-category (“T-Shirt size”) – Story points – Work days/work hours • Methods of estimation: – Expert Review – Creating a Work Breakdown Structure (WBS) JASS 2006 Agile Project Management Scrum 67 Product Backlog • Is only a FORECAST!-> is not exact JASS 2006 Agile Project Management Scrum 68 Sprint Backlog • A subset of Product Backlog Items, which define the work for a Sprint • Is created ONLY by Team members • Each Item has it’s own status • Should be updated every day JASS 2006 Agile Project Management Scrum 69 Sprint Backlog • No more then 300 tasks in the list • If a task requires more than 16 hours, it should be broken down • Team can add or subtract items from the list. Product Owner is not allowed to do it JASS 2006 Agile Project Management Scrum 70 Sprint Backlog • Is a FORECAST! • Is a good warning monitor JASS 2006 Agile Project Management Scrum 71 Burn down Charts • Are used to represent “work done”. • Are wonderful Information Radiators • 3 Types: – Sprint Burn down Chart (progress of the Sprint) – Release Burn down Chart (progress of release) – Product Burn down chart (progress of the Product) JASS 2006 Agile Project Management Scrum 72 Information Radiator • "Two characteristics are key to a good information radiator. The first is that the information changes over time. This makes it worth a person's while to look at the display... The other characteristic is that it takes very little energy to view the display." JASS 2006 Agile Project Management Scrum 73 Burn down Charts • X-Axis: time (usually in days) • Y-Axis: remaining effort JASS 2006 Agile Project Management Scrum 74 Sprint Burn down Chart • Depicts the total Sprint Backlog hours remaining per day • Shows the estimated amount of time to release • Ideally should burn down to zero to the end of the Sprint • Actually is not a straight line • Can bump UP JASS 2006 Agile Project Management Scrum 75 Release Burn down Chart • • • • Will the release be done on right time? X-axis: sprints Y-axis: amount of hours remaining The estimated work remaining can also burn up JASS 2006 Agile Project Management Scrum 76 Alternative Release Burn down Chart • Consists of bars (one for each sprint) • Values on the Y-axis: positive AND negative • Is more informative then a simple chart JASS 2006 Agile Project Management Scrum 77 Product Burn down Chart • Is a “big picture” view of project’s progress (all the releases) JASS 2006 Agile Project Management Scrum 78 Scaling Scrum • A typical Scrum team is 6-10 people • Jeff Sutherland - up to over 800 people • "Scrum of Scrums" or what called "MetaScrum“ • Frequency of meetings is based on the degree of coupling between packets JASS 2006 Agile Project Management Scrum 79 Scaling Scrum JASS 2006 Agile Project Management Scrum 80 Scaling Scrum JASS 2006 Agile Project Management Scrum 81 XP@Scrum Scrum is an effective project management wrapper for eXtreme Programming development practices, which enables agile projects to become scalable and developed by distributed teams of developers. JASS 2006 Agile Project Management Scrum 82 Pro/Con • Advantages • Drawbacks – Completely developed and tested features in short iterations – Simplicity of the process – Clearly defined rules – Increasing productivity – Self-organizing – each team member carries a lot of responsibility – Improved communication – Combination with Extreme Programming JASS 2006 – “Undisciplined hacking” (no written documentation) – Violation of responsibility – Current mainly carried by the inventors Agile Project Management Scrum 83 Conclusion • Thanks for you attention! • Any questions? JASS 2006 Agile Project Management Scrum 84 Cyreath.co.uk Empirical Pragmatic Testing An introduction to SCRUM Agile Project Management Mark Crowther – Empirical Pragmatic Tester [email protected] Copyright ©Mark Crowther 2009 Cyreath.co.uk Empirical Pragmatic Testing About this slide pack. This slide pack provides a brief overview of the SCRUM Agile Project Management Methodology. Contact Mark Crowther to learn how Testing within a SCRUM driven project can be effectively achieved and how it can be utilised to help make your Agile projects more successful. Copyright notice This document is copyright of Mark Crowther - © Mark Crowther 2009. The content and trademarks are the property of and copyright of their respective owners. All rights reserved. You may not, except with the express written permission of Mark Crowther make derivative works or commercially exploit the content or the publication. Nor may you transmit it or store it in any website or other form of electronic retrieval system except as permitted by this copyright notice. Any redistribution or reproduction of part or all of the content or publication in any form is prohibited other than the following: you may print or download the complete document or extracts of the content to a local hard disk and you may transmit it to an individual third party for personal and non-commercial use only; but only if you acknowledge Mark Crowther as the source of the publication and provide this copyright notice intact. For more information contact Mark Crowther. Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing SCRUM is an Agile Project Management Methodology Characteristics of an ‘Agile’ methodology are: • ADAPTIVE, not PREDICTIVE • LIGHTWEIGHT, not HEAVYWEIGHT • DESCRIPTIVE, not PRESCRIPTIVE Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing SCRUM has the following ELEMENTS: • A project team called a SCRUM Team • A Product Backlog of all known Requirements • A Sprint Backlog of requirements being worked on • A period of work referred to as a Sprint • Daily Stand-up Meetings with the SCRUM Team • A Burndown Chart to track progress of the Sprint • An Incremental Delivery at the end of each sprint Copyright ©Mark Crowther 2009 Cyreath.co.uk An introduction to SCRUM Empirical Pragmatic Testing A Model of SCRUM Burndown Chart Daily SCRUM Product Backlog Sprint Sprint Backlog Incremental Delivery 2 - 4 Weeks Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing The SCRUM Team • • Is all the people who will COMMITTED to the delivery of the backlogs One role is ‘SCRUM Master’ who is in practice the PM • Is staffed by PMs, BAs, Developers, Testers, Support – i.e. ALL the typical project staff Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Product Backlog Contains all the currently known requirements for a product • • Is managed by the Product Owner and can change as needed Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Sprint Backlog • Contains the set of prioritised Product Backlog items that are currently being worked on • Are not to be changed during the Sprint Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Sprint • Is a fixed period of development and testing • Results in an incremental delivery of usable product • Usually lasts 2 to 4 weeks Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Daily SCRUM Meeting • Brief ‘Stand-up’ meeting each morning with SCRUM Team only • What value did you add yesterday? • • What value will you add today? What will stop you making progress? Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Burndown Chart • • Charts delivery of the Sprint Backlog against Sprint Duration. Simple, at-a-glance view of progress showing velocity and traction • Easy to keep updated Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing Incremental Delivery • Output of the Sprint • Working functionality that can be deployed • Delivered every 2 to 4 weeks, tested and working Copyright ©Mark Crowther 2009 An introduction to SCRUM Cyreath.co.uk Empirical Pragmatic Testing What SCRUM isn’t • It isn’t a Development Methodology, SCRUM doesn’t say how to write or manage the writing of code. • • It isn’t suitable for every project and every organisation. It isn’t a way to drop sound Project Management, Development, Testing Practice, etc. Copyright ©Mark Crowther 2009 Conclusion • Thanks for you attention! • Any questions? JASS 2006 Agile Project Management Scrum 98 Agile Project Management Presented by Carter Engelhart – PMI-SVC I80 Roundtable Moderator. – January 2007 Meeting • Excerpts extracted from the book Managing Agile Projects by Kevin Aguanno, PMP, MAPM • ISBN 1-895186-11-0 • See www.mmpubs.com • Paperback and PDF editions available. • Endorsed by PMP’s as well as Staff of The Project Management Institute (or PMI). What is Agile? • Agile is used to denote the ability of Agile Methods to respond to changing requirement in a controlled but flexible manner • Agile methodologies can equip experienced Project Managers with new tools to manage projects that are set in environments of constant change. Why do we need new Project Management Methods? • Information Technology (as well as other industries) are continuously being challenged by emerging technologies and requirements. • Traditional Project Management “Best Practices” suggest that we should lock down requirements and setup a change control system up front. • Traditional Project Management practices also tend to refer back to the original requirements (and/or the contract) when enforcing change control. Traditional Project Management Practices can Lead to…. • Chaos – Junior Project Managers tend to either: – allow too much uncontrolled changed to take place (to ensure customer satisfaction) – or are too strict in allowing for change (resulting in irate customers). Traditional Project Management Practices can Lead to…. • Dramatic Project Underperformance – According to the Standish Group’s Chaos Reports, only 16 percent of IT projects are successful, the remainder are: – Late. – Over Budget. – Deliver only a fraction of original scope in order to meet budget restrictions. – Cancelled. What Is Different About Agile Methods? • They are all about managing the impact of change on a project. • They allow change to be introduced into a project in a orderly way that that attempts to maximize the benefits for the sponsor. • They control the risks that the change introduces. What is different about Agile Methods? • Iterative and Incremental development that break down development into a number of repeating cycles called Iterations • Short iterations are used to keep the feedback flowing (allowing for increased responsiveness to change and reducing the risk of building the wrong thing). • Open, Flexible and Extensive design using open standards whenever possible What is different about Agile Methods? • Empowered Teams – Experienced specialists are encouraged to work out the detail design on their own. • Personal Communication – Rather than relying on written documentation to communicate design decisions, technical approaches and other typically documented items, agile method suggest that the team work in the same physical space (co-location). Use of white boards in the work area is encouraged rather than lengthy formal detail design documentation. The Benefits of Being Agile • Reducing Risk – The benefits from improved control and improved communication lead to reduced risks. Examples of risks include: – Risk of building (or doing) the wrong thing. Did the sponsor get what they asked for but not what they actually wanted? – Risk of building the right thing poorly. For example, was the product poorly crafted. Was it thoroughly tested as a part of each iteration? Is the final produce extensible? – Risk of being placed into an endless cycle of design updates and reviews due to changing requirements or high levels of complexity The Benefits of Being Agile • Relief from continual design revisions - Agile Methods are of the most benefit when applied to projects where the requirements are either unclear or evolving The Benefits of Being Agile • Improved Control – Agile methods allow the Project Manager to their control over the project in high change environment. Utilizing less rigid, yet structured agile methodologies, control is through a number of mechanisms. The Benefits of Being Agile (Improved Control) • Frequent delivery of working code allows progress to be objectively measured. • Early and frequent stakeholder feedback allows the Project Manager to redirect project priorities when needed to ensure that real value is delivered. • Misunderstandings are cleared up early in the project life-cycle. • The sponsor is able to end the project earlier than scheduled and still receive value. The Benefits of Being Agile (Improved Control) • Short daily meetings allow team members to share both successes and problems with each other. Each team member should share: – What they have just completed (so that team members working on dependent tasks are notified). – What are they going to work on next (allows other team members to contribute information that may be helpful to the task). – Issues that are slowing down or halting their progress (so that other team members and/or the Project Manager can provide assistance). Waterfall (traditional) way to plan a software project. • • • • • • Analyze the problem Design the solution Implement the code (Execution) Test the code Deploy the code. Done Agile method of planning a software development project. • Initial Analysis • Initial Design (When problems are identified they are pushed back into the analysis step, to improve it). • Initial coding, push back identified design problems back. Perform another iteration of design to improve it. • Initial Testing. Identified problems are feed back into another iteration of coding. • Integration and deployment. Feedback any problems you encounter into the process. • A system of incremental/continuous improvement. Agile methods are all about incremental progress • Working incrementally allows the most critical portions of the product to be delivered earlier. • Working incrementally can help reduce risk by receiving stakeholder feedback in increments rather than at the end. • Working incrementally allows project teams to continuously make small corrections along the way. Each incremental corrections contributes to the overall quality of the entire project. Agile – Sweat Spots • • • • • Dedicated developers Experienced developers Small collocated teams Automated Regression testing Easy to access users. Waterfall vs. Agile • Money for information (waterfall) • Money for flexibility (agile) Agile Documentation • A document is any artifact external to source code whose purpose is to convey information in a persistent manner. Reasons to Create Documentation • Project stakeholders require it (a Business decision with costs and benefits associated with it) • To define a contract model (to define how your system and an external one interact with each other). Typically required when an external resource controls an IT resource your system requires (e.g. DB, Application or IT service) Reasons to Create Documentation • To support communication with an external group (e.g. a non-co-located group). • If it will assist you in thinking something through. When is Documentation Agile • Generally – when it is “Good Enough”, but no more. This of course is subjective. • When it maximizes stakeholder investment. • When the documentation contains “just enough” information to fulfill its purpose (and no more). • Is purpose driven. If you are not clear about the purpose you are creating the document, you should not be doing so. • When it contains information that is “Less Likely” to change. When is Documentation Agile • When the documentation contains critical information not readily available. • When the documents have a specific customer and facilitate the work efforts of that customer. • When the documents are sufficiently indexed, accurate, consistent and detailed. Relating PMBOK Practices to Agile Practices • Relating PMBOK Practices to Agile Practices – Michele Sliger – Part I – Part II – Part III – Part IV SECTZG652 : Agile Software Process Session – 05, 06: Agile Roles and Processes, Executing a Sprint 123 Introduction Scrum Framework Scrum Roles, Artifacts Sprint in Scrum Sprint Review Sprint Retrospective 124 Scrum Daily Scrum Meeting • Done since last meeting • Plan for today • Obstacles? Sprint Planning Meeting • Review Product Backlog • Estimate Sprint Backlog • Commit to 2-4 weeks of work daily Sprint Review Meeting • Demo features to all • Retrospective on the Sprint Backlog tasks expanded by team 2-4 weeks Sprint Retrospective • What well well, What went wrong, New ideas Vision Product Backlog: • Prioritized Features • desired by Customer Sprint Backlog • Features assigned to Sprint • Estimated by team Potentially Shippable Product Increment 125 Scrum Roles, Artifacts 126 Product Owner Communicates a Product Vision Business Goals High Level Approach Owns Product Backlog Prioritizes the backlog (include all input for a product) Performs Release Planning Owns Release Planning and communicates release goals (Internal/External) Participates in Sprint Planning Present product backlog at sprint planning meeting Is available in the Sprint Attend daily standup meetings, available to team for questions 127 Product Backlog It exists over the life time of the project The Product backlog will contain a variety of items like Features Development requirements Exploratory work Known Issues Continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear The team provides the Product Owner with rough estimations of the relative effort required for each item on the Product Backlog. Helps the Product Owner make prioritization decisions 128 Product Backlog (contd.) Estimations are relative Items can be large but preferable to break them into smaller stories The Product Owner and team decides the level of details to which the specification should be documented User Story A description of desired functionality told from the perspective of the user or customer Story Points A relative size of a User Story. Has no UOM Ideal Days Effort needed to complete a story when it is the only thing you’ll work on, no interruptions and every thing you need is available 129 Team 7 people, + or -2 Better to have dedicated resources Cannot change during a Sprint Can be distributed but better when co-located Cross functional, Self Organized and Self Managing Every team member that contributes is termed as Pigs in Scrum Vs Chickens Team decides what to commit to and how to accomplish that commitment The team can also provide input to the customer/Product owner on how to make the product as good as it can be 130 Pigs and Chickens in Agile Pigs are the scrum team members who are committed to the Sprint/Scrum Chickens are members who are involved but NOT committed to the project 131 Scrum Master Serves the team The Scrum Master takes action to help remove impediments to the team’s effectiveness The Scrum Master facilitates the team’s group interactions, to help the team achieve its full potential Protects the team The Scrum Master protects the team from anything that threatens its effectiveness, such as outside interference or disruption The Scrum Master will need to confront uncomfortable issues, both inside and outside the team Guides the team’s use of Scrum The Scrum Master teaches Scrum to the team and organization The Scrum Master ensures that all standard Scrum rules and practices are followed 132 Sprint Backlog Tasks to turn product backlog into working product functionality Tasks are estimated in hours, usually 1-16 Tasks with more than 16 hours are broken down later Team members sign up for tasks, they aren’t assigned (be patient, just wait!) Estimated work remaining is updated daily Any team member can add, delete or change the Sprint Backlog (theirs or new) Work for the Sprint emerges If work is unclear, define a Sprint Backlog with a larger amount of time, break it down later. Update work remaining as more is known, as items are worked 133 Sprint Backlog (sample) 134 Sprint Burndown To create a burndown chart, each day the Scrum Master records the estimated remaining work for the Sprint records it on a chart Start at day zero, the day of the Sprint planning meeting End at the day of the Sprint review 135 Sprint Tasks to turn product backlog into working product functionality Tasks are estimated in hours, usually 1-16 Tasks with more than 16 hours are broken down later Team members sign up for tasks, they aren’t assigned (be patient, just wait!) Estimated work remaining is updated daily Any team member can add, delete or change the Sprint Backlog (theirs or new) Work for the Sprint emerges If work is unclear, define a Sprint Backlog with a larger amount of time, break it down later. Update work remaining as more is known, as items are worked 136 Sprint Sprints are not mini-waterfall projects Rather, we do a little bit of everything all the time 137 Daily Scrum Daily – same place, same time, all must attend Short , stand-up meeting for 15-mins All are welcome, but only "pigs" may speak Everyone reports 3 things only to each other What was I able to accomplish since last meeting What will I try to accomplish by next meeting What is blocking me Purpose – Share commitments, communicate status, identify issues, set directions and focus, build the team Daily standup is for synchronizing between the team members, not between Scrum Master and the team Some teams find it useful to have the Product Owners join and give a brief daily report of their own activities to the team though this is at the team’s discretion 138 Sprint Review Demo by the team of what the functionality it has developed during the Sprint to the Product Owner and “stakeholders” in the project. Generate feedback, which the Product Owner can incorporate in the Product Backlog Attended by Team, Product Owner, Scrum Master, functional managers and any other stakeholders 139 Sprint Retrospective Accelerates visibility Accelerates action to improve It’s a key mechanism of continuous improvement A Good Approach What went well and therefore should be continued What didn’t go so well and therefore should be done differently next time What learning can the team apply to make improvements in the future The discussion can cover anything that affects how the team builds software this might include: processes, practices, communication, environment, artifacts and tools. Process improvements are made at end of every Sprint - ensures that the project team is always improving the way it works. Attended only by the Delivery Team 140 References 1. Agile and Iterative Development A Manager’s Guide - Craig Larman/Pearson Education - 2004. - Chapter 7, 8 and 9 2. Scrum Primer - Peter Deemer (Free download available) 3. Agile Project Management for Dummies - Mark C. Layton/John Wiley & Sons 2012 (Available in Books 24X7) – Chapter 6 and 9 141 SECTZG652 : Agile Software Process Session – 07, 08: Agile Requirements and Iteration Planning 142 Introduction • • • • • • • • • Introduction to User Stories Prioritization techniques Size Estimation Introduction to Poker Estimation Introduction to Velocity Pre-requisite for Sprint Planning Velocity based planning Capacity based planning Sprint Commitment 143 Agile Requirements • Active user involvement is imperative • Requirements emerge and evolve as software is developed • Agile requirements are ‘barely sufficient’ • Detailed enough for the team to work from, and further details to be established and clarified at the time of development • Requirements are developed in small, bite-sized pieces • Cooperation, collaboration and communication between all team members is essential 144 User Stories A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software. It generally has 3 parts Card - A written description of the user story for planning purposes and as a reminder Conversation - A section for capturing further information about the user story and details of any conversations Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected • User Stories should describe features that are of value to the user, written in a user’s language. • User Stories detail just enough information and no more. • Details are deferred and captured through collaboration just in time for development. • User Stories need to be the right size for planning 145 User Stories User story should have the following INVEST features. I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable 146 User Story Desciption As a [user role] I want to [goal] so I can [reason] For example: As a registered user I want to log in so I can access subscriber-only content Who (user role) What (goal) Why (reason) gives clarity as to why a feature is useful can influence how a feature should function can give you ideas for other useful features that support the user's goals 147 MOSCOW Prioritization MoSCoW is a fairly simple way to sort features (or user stories) into priority order – a way to help teams quickly understand the customer’s view of what is essential for launch and what is not. MoSCoW stands for: Must deliver the item – the release is worthless to the user without it. Should deliver the item – but there is a short-term workaround. (Note: “Should” item would be “Musts” if they were time-critical). Could deliver the item – if time is available. Will NOT deliver the item under any circumstances – but will consider it for future releases. 148 Story Point Sizing Estimation is done in terms of Story Points All estimates are relative to other Stories in the backlog The team does the estimation themselves Stories Size Enable users to search all Users 5 Enable users to create, update and delete users 8 Allow users to create, update and delete roles 8 Users should be able to map each user to a role 13 149 Poker Estimation 1. Everyone has cards: 1, 2, 3, 5, 8, 13, 21, 34 2. Scrum Master reads description of backlog item 3. Everyone selects and simultaneously shows cards 4. If estimates vary significantly, high and low estimators briefly explain 5. Repeat steps 3-5 until estimates stop converging 6. Decide estimate for backlog item 7. Move to next backlog item all standard Scrum rules and practices are followed 150 Velocity Planning in Scrum is based on Velocity Velocity is a measure of how much Product Backlog the team can complete in a given amount of time Velocity can be calculated by Using historical data for this team Running an iteration Making a forecast 151 Backlog Prioritization high High risk Low value High risk High value (Avoid) (Do first) Low risk Low value Low risk High value (Do last) (Do second) Risk Low high Value 152 Sprint Planning Customers Management Meeting Attendees Meeting Product Backlog Meeting Inputs Outputs Team Capabilities Sprint Planning Sprint Goal Technology Meeting Sprint Backlog Current Product 153 Sprint Planning More commitment as the team determines the estimates and make a commitment by itself Sometimes it is acceptable to pull an item of lower priority as a gap filler The team will know how much time is available with them for the sprint related work Once the available effort is known team starts picking the tasks one by one until estimates exceed available hours The selected tasks are noted down in a Sprint backlog - Task board or excel 154 Sprint Planning 155 Sprint Commitment No changes once commitment is made No Changes to Deliverable Details will emerge during Sprint, but no new work or substantially changed work Product Owner can terminate the Sprint if necessary No Changes to Sprint Duration Sprint ends on planned date whether team has completed its commitment or not Product Owner can make any changes to the remaining Product Backlog before the start of the next Sprint 156 References 1. Agile and Iterative Development A Manager’s Guide - Craig Larman/Pearson Education - 2004. - Chapter 5, 8 2. Managing Agile Projects Kevin Aguanno / Multi-Media Publications 2004 (Available in Books 24X7) – Chapter 7, 11 157 SECTZG652 : Agile Software Process Reinforcement Session – 01: Agile Introduction “If you try to make the software foolproof, they will just invent a better fool!” Dorothy Graham 1 Introduction Refresher of concepts discussed Traditional approaches Traditional approaches vs. Agile Benefits of Agile Case Study “From Waterfall to Evolutionary Development and Test” 2 Traditional Model Feasibility Study User Requirements Analysis System Design Detailed Design Coding Testing Deploy and Maintain 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Traditional approaches - Objective In the face of changing requirements, traditional project management "best practices" suggest that we try to Lock down requirements to form a baseline Implement change control and Fall back on the documented requirements or the contract as means to enforce the change control. All-at-once delivery Success of a project depends on ‘Triple Constraints’ Ending the project within schedule Finishing under budget Completing entire scope Results of projects differed based on the choice Lenient and allowing too much change to the baseline without triggering the change control processes (in the interest of customer satisfaction) - may go way over budget and may be late due to additional features being added Too strict and refusing to accept changes to the baseline. Sometimes leads to irate customers - may go over budget and may be late due to the extra work and delays caused by assessing the changes to the baseline and the oft4en contentious negotiations with the customers. Waterfa l Model 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Waterfa l Model Pros The model is straight forward Very formal and disciplined model The model is rigid and each of the phases has certain deliverables and a review process immediately after a particular phase is over Cons Assumes everything is predictable at once Expects all requirements to be captured upfront Changes to requirements would be very expensive Bugs are expensive to fix and new requirements are expensive to incorporate. Problems are not discovered until system testing It is not suited for long or complex projects or projects where the requirements can change You do not see a working version of the software until late in the life cycle 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Spiral Model 1. In discussion with the customer, the requirements for the system are defined and documented in as much detail as possible. 2. An initial design is created based on the requirements. 3. A sequence of increasingly complete prototypes are constructed from the design in order to - test the strengths and weaknesses of the prototypes, and to highlight any risks; - assist in refining the requirements by obtaining customer feedback; and - assist in refining the planning and design. 4. The risks identified by testing the prototypes are reviewed with the customer, who can make a decision whether to halt or continue the project. 5. Steps 2 through 4 are repeated until the customer is satisfied that the refined prototype reflects the functionality of the desired system, and the final system is then developed on this basis. 6. The completed system is thoroughly tested (including formal acceptance testing) and delivered to the customer. 7. Where appropriate, ongoing maintenance and test are performed to prevent potential failures and to maximize system availability. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Spiral Model BITS Pil ani, Deemed t o be Uni ver sit y under Secti on 3 of UGC Act, 1956 Need for Agile Development Client not sure how the end product should look like Need for having the best features for better marketability Business is in a state of flux Why Agile? Requirements are evolutionary Need for end user feedback Unclear Requirement s for delivering better functionalities Shorter release cycles required Identify and follow Optimal Process to Rapid releases get continuous feedback optimal processes Working software to reach Improve productivity the customers faster 9 Agile Model Leve Requirements High Level Analysis (Business Requirements Domain Model) Key Features High Level Architecture H gh Leve Arch tecture Analysis Ana ys s Release 1 • Product Backlog Creation (High Level Feature Sets, Prioritization) Release Goal • Features Identification • Requ emen s are Requirements unclear/con nuously evo ving unclear/continuously evolving • Requirements & Architecture Elaboration Sprint Zero (Pre-Game Phase) Sprint …N Sprint 2 Sprint 1 • Sprint Execution Planning Refine Requirements & Architecture Design By Feature Code By Feature Test By Feature Certify By Feature (UAT) Sprint Review and Closure 10 • Daily Standup Meeting Define Def ne Program Roadmap Release …N Release 2 • Unproven technology echno ogy is s used Frequen -pro ect Frequent custome customer-project eam interaction n e act on team Usage Usage o Cu edge ng edge of Cutting Release Integration System & Performan ce & User Acceptanc e Testing • Productio n Rollout Warranty Support Technology architecture Techno ogy arch ec ure && Initial n a iterations era ons may may evolve evo ve architecture, UI frameworks arch ecture U amewo ks etc ec Suited Su ed for o large arge duration dura on projects; pro ects; Software developed So wa e is s deve oped in n numerous releases by globally nume ous re eases by g oba y ddistributed stribu ed teams eams ;Release Re ease to o production can combine one product on can comb ne one or o more iterations more e a ons Benefits of Agile At a strategic level, Agile benefits include Ongoing risk management: This is achieved by regularly confirming and adjusting requirements according to ongoing interactions with the customer[17] and by delivering fully functional and fully tested software features Ongoing control of budget expenditure: by providing decision makers with the opportunity to review and assess the business value of deliverables at each iteration, and with the option to adjust, postpone or stop ongoing funding based on the return on investment (ROI) of delivered work. Rapid delivery of tangible outcomes: by focusing team efforts on regularly producing fully functional, fully tested, production-ready software features that can be used by the organization well before the end of the project timeline. Strong alignment with business requirements: by directly involving the customer in the initial and ongoing review of developed software, and by incorporating their feedback throughout the process. Focus on the highest-priority features: by continually working with the customer to confirm and adjust the work undertaken by the project team to align with the most current priorities of the organization. Responsiveness to business change: by adjusting work throughout the process to incorporate organizational, industry and technology changes. Transparency in status tracking: by regularly providing tangible outputs for customer review, combined with the use of open communication forums and centrally available real-time status-tracking tools. Substantially higher-quality outputs: by incorporating rigid testing regimes throughout the process and by working regularly with the customer to confirm the usability and business value of delivered features. Greater employee retention: by creating work environments that are based on high communication, empowering the team, trusting their expertise, encouraging innovation, and regularly acknowledging their contribution to the organization[18]. Minimized whole-of-life software costs: by incorporating usability, quality and extensibility into solutions throughout the delivery process – thereby reducing both development costs and 1s1upport and maintenance overheads – and by providing a less risky and more cost-effective platform for additional functionality to be integrated into the solutions. Benefits of Agile Tactical benefits of Agile The production of more valuable outputs per resource hour: Earlier identification of technical issues Less rework and “throw-away” work Reduced need to create – and maintain – detailed documentation Greater flexibility Greater opportunity for innovation Reduced dependency on paper status reports Reduced demand for ongoing support and maintenance 12 Traditional Vs Agile Development Category Visibility Adaptability Traditional Development High Involvement of client during through out the Requirement elicitation Little or no visibility until the is ready for UAT build Define detail requirement in testing iteration advance Agile Development Active involvement of client life cycle Adapt requirement at each Quickly respond to business and process Difficult to change requirement changes due to longer delivery cycles Business Little or no Business value is Deliver small usable components through value delivered until the system is out the iteration process complete Risk Risk remains high until the Identify issues earlier in the process, system is delivered eliminating risk in the earlier cycle 13 Challenges By only looking at small pieces (increments) of the software, we may have to do massive rework, which might have been avoided if we analyzed or designed the whole system correctly. We might "paint ourselves into a corner;" that is, we can get a system that is incapable of supporting some new requirement. We may be unable to add global requirements, such as alternate language support, performance, and security. A typical example is trying to retrofit "security" to an application that was not designed with this requirement in mind. We might go slower because we have to restart analysis and design sessions for each increment, instead of doing it once at the start of the project. 14 Corrective Maintenance While agile methods may not fit every project, they do provide valuable benefits when applied against specific business problems Reducing Risk Building the Wrong Thing Building the Right Thing Wrong Getting Stuck in "Design Churn“ Improving Control Frequent Delivery means Measurable Progress Feedback and Redirection means Delivering More Value Early Feedback means Lower Cost of Change End Early with Measurable Benefits Improving Communications Co-Located Teams Short Daily Meetings Close Customer (Sponsor) Involvement 15 EVERYONE IS DIFFERENT: AGILE CASE STUDIES “People think computers will keep them from making mistakes. They’re wrong, with computers you just make mistakes faster.” - Adam Osborne CASE STUDY “From Waterfall to Evolutionary Development and Test” Synopsis of case study Evolutionary Development (Evo) focuses on early delivery of high value to stakeholders and on obtaining and utilizing stakeholder feedback. Describes results rapidly achieved after migration from waterfall to Evo Major benefits of adopting an Evo approach: Reducing the duration of the reqts phase from 5 weeks to a week Paying greater attention to the quality requirements vs. concentrating solely on the required functionality Resulting in a happier workforce, happier clients, and more business Background Case study will focus on adoption and use of Evo method in building a Conformit product from an Oslo-based company called Conformit AS. Specifically focusses on the reduced integration efforts as well as reduced devt. timescales by using Evo as compared to waterfall model Background (Contd.) Confirmit is a powerful web-based software package that enables organizations to gather, analyze, and report on key business information across a broad range of commercial applications. A total staff of 20 members (including a QA team of 3 people) work in the Confirmit AS R&D department This team is responsible for developing the core Confirmit functionality and developing custom bespoke modules for specific clients. For initial versions, Confirmit AS had just a few clients, the development process was fairly ad hoc and customer-driven. Changes to the software were made on an almost daily basis, driven by client feedback. This delivered stakeholder value quickly. This process also resulted in numerous defects, long working hours, and poor control of the software development and testing process. As the clients grew, they were faced with the need to become more effective and efficient in its development and testing. This required a more formal process. Background (Contd.) Initially, Confirmit AS looked to adopt a waterfall approach and following the Capability Maturity Model. After following a waterfall approach for a number of years, a number of issues were identified: Risk discovery and mitigation was delayed until the later stages of the project. Document-based verification was postponed until the later stages of the project. There was dissatisfaction with the need to stipulate unstable requirements too early; requirements change is perceived as a bad thing in waterfall. Operational problems were discovered far too late in the process (typically at acceptance testing). There were lengthy modification cycles and too much rework and retesting. Most important, the requirements were nearly all focused on functionality, not on the quality attributes of the system. Key goals of new process Reducing the integration effort – that is, the amount of effort for each developer to get the latest build to work on his or her workstation so that they were able to code against the latest code platform Reducing the time in minutes to upgrade – from a previous code platform to the most recent code platform from 3 hours to a goal of 2 minutes; Improving the reliability of builds – which historically had been an area where there had been significant quality issues. Realization dawned that “It is THE product quality requirements that provide Confirmit with a competitive advantage over its rivals.” Evo 10 Key process Principles 1. Real results, of value to real stakeholders, will be delivered early and frequently. 2. The next Evo delivery step must be the one that delivers the most stakeholder value possible at that time. 3. Evo steps deliver the specified requirements, evolutionarily. 4. It is impossible to know all the right requirements in advance, but it is possible to discover them more quickly by attempts to deliver real value to real stakeholders. 5. Evo is holistic systems engineering; all necessary aspects of the system must be complete and correct, and delivered to a real stakeholder environment. It is not only about programming, it is about customer satisfaction. Evo 10 Key process Principles 6. Evo projects will require an open architecture, because project ideas will change as often as needed to really deliver value to the stakeholders. 7. The Evo project team focuses their energy, as a team, toward success in the current Evo step. They succeed or fail in the current step together. They do not waste energy on downstream steps until they have mastered current steps successfully. 8. Evo is about learning from hard experience, as fast as possible – what really works and what really delivers value. Evo is a discipline to make teams confront project problems early, but one that delivers progress quickly when provably the team have got it right. 9. Evo leads to early, and on-time, product delivery – both because of selected early priority delivery and because the team learns to get things right early. 10. Evo should allow teams to validate new work processes and get rid of bad ones early. Evo: New Reqts standard Requirements had to be : be clear and unambiguous, be testable, be quantified, not involve solutions, and have a stakeholder focus. Focus on day-to-day operations of users Following this process, all reqts of new release was designed and documented in 1 week. Eco: Cycle time of 1 week Week-day wise template plan for project activities was worked out. This plan had individual roles and responsibilities clearly identified and targeted. Week day activities On the Friday: (PM) delivers the detailed plan for the next week’s version of the software (let’s call it Version N) to the customer (CTO) prior to attending a weekly PM meeting. CTO reviews and approves or rejects the design and records their comments. PM and CTO attend the weekly PM meeting to discuss the Version N detailed plan and review CTO comments. Developers focus on general maintenance and documentation tasks. QA team runs final build and setup for that week’s developed version (let’s call it Version N-1), installs setup on test servers, and performs initial crash test 1 of Version N-1 prior to its release. Week day activities On the Monday: The developers first generate the tests required to validate Version N and then begin development of the code. QA team reviews the results of the continuous integration (CI) process and reviews test plans and tests for Version N. Users begin to use Version N-1 and compile feedback for the developers. Week day activities During Tuesday and Wednesday: The developers continue to generate the tests required to validate Version N and develop the associated code. The developers meet with the users to discuss the feedback from using Version N-1. Incorporating the feedback from the users, the developers continue to generate the tests required to validate Version N and develop the associated code. QA team reviews the results of the CI process and reviews test plans and tests for Version N. Week day activities On the Thursday: The developers complete the final tests for Version N, code, and execute the tests. The developers also complete the graphical user interface tests for the previous week’s version of the software (let’s call this Version N-2). The QA team reviews the results of the CI process and reviews test plans and tests for Version N. Benefits of Evo adoption Resulted in increased motivation and enthusiasm among the developers and testers developers reported that they are empowered and feel they have the scope for greater creativity Roll-out and adoption of Evo was relatively painless Paradigm shift with respect to the requirements process Previously focussed on functional requirements but now on product quality requirements Testing was made mandatory thereby raising the quality standards of the deliverable Lessons learnt The adoption of a weekly development, test, and delivery cycle has been very beneficial – All stakeholders could easily see value As with the introduction and use of any new, nontrivial technology, it is key to ensure adequate training, mentoring, and consultancy Approach to CI has been refined, the CI process has proven to be successful and we intend to continue to use it for the foreseeable future There is always another lesson to be learned – the goal of fine-tuning our processes continues today, and will continue into the future. Thank you Questions? SECTZG652 : Agile Software Process Reinforcement Session – 03: Testing of a system that is WIP 1 Introduction Agenda Case Study Experiential learning – Cause – Effect relationships for arriving at Project Risks 2 Case Study In a fast-moving environment where requirements are changing all the time, in order to support the customer’s needs, the testing strategy has to be superagile. Questions to be answered: How do you keep the relevant documentation up to date? How do you communicate the changes to your team? How do you ensure your testing covers the changes? How can you guarantee that you deliver a system that works and meets the customer’s needs? 3 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Case Study: Synopsis This case study reviews the issues that are being faced by a large, multiyear project practicing incremental delivery, and shows how the team has used agile techniques to address these issues. In particular we will look at how using techniques such as daily builds, pairing testers and developers through an iteration, and the use of automated testing tools for regression testing have enabled the team to successfully test and deliver a new,ONLY high-quality release every has six weeks! ONE AND SOLUTION: Testing to be superagile!!! 4 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Background of team A team enhancing a large business critical information system that needs to be updated every six weeks to keep pace with an ever-changing variety of information sources and analytical needs. Traditional test approaches are not suitable in this kind of situation; the test strategy must be agile for the project to survive. 5 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Challenges faced As team worked to develop and test the software, we needed to meet the challenges of: a) Keeping the relevant documentation up to date, b) Communicating the frequent changes to all members of the team c) Ensuring that the changes are thoroughly tested, d) Ensuring that the changes don’t compromise or break the existing system, and e) Delivering a system that works and meets the customer needs every six weeks. 6 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Solutions to challenges faced Solutions that were explored to address those issues: a) Developing the test cases alongside the requirements, b) Pairing testers and developers through an iteration, c) Ensuring that all the documentation was updated as we went along, d) Relaying information to the team by means of a daily Scrum, and e) Employing automated testing tools to assist with the testing load 7 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Background to the Project work a) Project was first initiated in 1997 b) Involves the development of systems to provide key information to government departments on demand. c) As information sources are enhanced or new sources identified, the systems need to be quickly updated. d) No end date to this project, as it is inevitable that changes and new reqts will continue to be added future. e) Systems are truly “business critical,” requiring very high quality, reliability, and availability. f) Essential updates must be implemented quickly, must be delivered on time, must be defect free, and should not regress the existing functionality. 8 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Background to the Project work a)Project runs on a rolling three-year cycle, with major reviews carried out at the end of each period. These result in changes to the personnel involved in the project and the underlying customer needs. b)This is a large agile project, with some thirty staff, including customer representatives. Team changes regularly, with no one staying on the team for any great length of time, other than a core of 5 people. c)It is critical to project success that the productivity and quality are not harmed as a result of the high turnover. d)Continuously integrating new team members into the team is a major challenge; consequently, a great deal of attention has to be paid to keeping documentation up to Background to the Project work a) The project is run as a series of six-week iterations, with each iteration delivering production-quality code into the live environment. b) As a result of this rapid development cycle and the need to deliver high-quality reliable code into the live environment, testing is absolutely critical to the success of each iteration, as well s that of the overall project. c) The need to ensure that the code implemented in the current iterations meets the customer requirements and is reliable, while ensuring that the changes do not regress existing code base, means that testing must be continuous, comprehensive, effective, and efficient. 10 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Background to the Project work a)Project runs on a rolling three-year cycle, with major reviews carried out at the end of each period. These result in changes to the personnel involved in the project and the underlying customer needs. b)This is a large agile project, with some thirty staff, including customer representatives. Team changes regularly, with no one staying on the team for any great length of time, other than a core of 5 people. c)It is critical to project success that the productivity and quality are not harmed as a result of the high turnover. d)Continuously integrating new team members into the team is a major challenge; consequently, a great deal of attention has to be paid to keeping documentation up to Definition of an Agile Testing Process There were two aspects to the successful delivery of the system: 1. Needed to assemble the core of a great team that had the experience and talent to work using the new agile techniques. This core of five people needed to transfer knowledge to new team members as they moved in and out of the project. 2. Needed a lightweight and practical process to help us deliver on time, to budget, and to acceptable quality. 12 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Customized Agile Testing Process Decided to adopt a smaller number of agile practices taken from the Essential Unified Process EUP is available at: http://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Ce ntre/Resources/White_Paper/Resources/paper_essup_first_look. pdf The concepts within this process are delivered using cards – this means that minimal information is referenced when it is needed. The beauty of the EUP is that it adopts a practice-based approach, where the practices underlying the process are defined separately in a way that allows you to select just the ones that will benefit your project. 13 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Customized Agile Testing Process The practice approach is a 'Lightweight' approach: Lightweight: Using small parts of the process to add value where and when needed. Followed the practice for improving communications and introduced daily Scrums. Scrum allowed us to minimize the amount of documentation we produced Combining smart communication with fit-for-purpose levels of documentation turned out to be very important in supporting the testing effort needed to ensure high-quality and reliable delivery. Communication through simply talking has proven invaluable in ensuring that all stakeholders are headed in the same direction. 14 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Customized Agile Testing Process Decided to adopt a smaller number of agile practices taken from the Essential Unified Process EUP is available at: http://www.ivarjacobson.com/uploadedFiles/Pages/Kn owledge_Centre/Resources/White_Paper/Resources/pap er_essup_first_look.pdf The concepts within this process are delivered using cards – this means that minimal information is referenced when it is needed. The beauty of the EUP is that it adopts a practicebased approach, where the practices underly15ing the process are defined separate BITlSyPilian i, Da eemw ed ta o by e Untih vera sitytuna delrlSo ecw tions 3 ofy Uo GCu Act, Customized Agile testing process Process encouraged the involvement of the test resources throughout the project Testers were involved in working with the customers alongside the analysts, producing the test cases at the same time as the use cases were getting built. This test-driven approach provided significant improvements in productivity and accuracy compared with traditional methods. Ensured that the requirements, both functional and nonfunctional, have a test built alongside them during their development. Establishing traceability between the requirements, tests, and components provides the minimal level of documentation that is needed and adds value.When frequent personnel changes were there, it was very useful. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Customized Agile testing process Took the approach that the customer representative was an essential part of the team and mandated that customer representatives be involved in the software development from day one. Followed the assumption that “the customer will only know what they want when they see it,” and through having them on hand at all times we could make sure that we were building and testing the right thing. Agile principle of promoting good and regular communication works very well with the customer and cuts down the amount of time spent on clarifying or confirming issues. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Results of customized Agile testing process project continues to deliver successfully reputation of the project has excelled other projects within the same organization are now looking to reuse the approach developed in order to improve their productivity and delivery records. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Lessons Learnt User requirements and test cases – you need them both up front. As the use cases are constructed, a test resource is on hand to identify the test cases that will be needed to cover functional and nonfunctional issues, quality, and integration. This provided us with accurate requirements and the details of the testing needed to ensure that the requirements were met. Pair developers and testers This was not perfect owing to politics of developer vs. tester as a policeman Subsequently, refined this approach so that the tester was involved in reviewing what had been delivered at the end of each day, so that this could be incorporated into the next day’s testing. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Lessons Learnt Every day is test day The phrase ““we can cut back on testing to meet the deadline!” was thrown out of the window If something is to be delivered, then it is the testers who make the final decision as to whether or not that something is delivered into the live environment. In addition to daily builds and their associated tests, test cases are implemented during an iteration as the code is being developed. Each and every day in our iterations is a day that the testers will work with the team, with one common goal – successful delivery. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Lessons Learnt Automated testing of daily builds The use of automated testing tools for regres sion testing has saved the project significant amounts of time, effort, and cost, and has helped to ensure that the quality of the deliverable is maintained. The goal is to run automated tests every night, with any issues highlighted the following morning. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Lessons Learnt Role and use of Scrums One of the benefits of holding daily Scrums has been in promoting effective testing as the key to the delivery of higher-quality code. Scrums have also been instrumental in ensuring that testers, analysts, developers, and customer representatives are all working together as a team toward the same goal. BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Conclusions of this case study Overall, the importance of testing within a project that has to deliver high-quality code cannot be underestimated. Within this project, testing was given a great deal of emphasis and, specifically, testing was: introduced into the process as early as possible present everywhere within the practices employed throughout each iteration, the central cog of the development process supported by the use of automated testing tools “With agile practices and a good team, successful delivery becomes the norm.” [Source: Anonymous] BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Experiential learning 24 Cause – Effects relationship Cause – Effects relationship is used to identify project risks and understand techniques to be used for process adherence Class to be split into different groups Each group lists down point by point all facts that can relate to an Enterprise Software Scope includes Cost, Time, Man-power, SW maintenance, Support etc. Facts are grouped together in such a way that the fact on left causes the fact mentioned on right Example follows in the next slide..... 25 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Approach (Contd.) The facts written could be: Enterprise software has a lot of features Enterprsie software is complex Enterprise software is expensive Enterprise software implementations can have bugs Enterprise software takes time to deliver Time is money Enterprise software features need manpower to implement them Bugs take time to fix It takes time to co-ordinate the efforts of the develo2p6ers B ITS P ila ni, De e med to be University under Section 3 of UGC Act, Example Cause - Effect 27 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Likewise..... Do for IRCTC Online reservation system enterprise Software 28 BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956 Thanks 29 Managing Agile Projects, First Edition by Kevin Aguanno (ed) Multi-Media Publications Inc.. (c) 2004. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Managing Agile Projects, First Edition Chapter 1: Introduction Kevin Aguanno Overview Extreme Programming, [1] Scrum, [2] Feature-Driven Development, [3] Lean Development, [4] Crystal Methods, [5] Agile Project Management: [15] these are just a few of the more common examples from a group of new product-development methods that have emerged over the past decade. While they were once relegated to back alley discussions between product development teams, they have emerged to become topics of mainstream discussion, appearing as topics in conferences and academic journals. Where did these "new" methods come from? What do they offer that is different from traditional methods? Is there anything really new in these methods? And do we need new techniques new methods? Proponents have come together under theproject bannermanagement of Agile Methods in ordertotomanage supportthese the further development and promotion of these methods. The term agile was selected by these proponents at an initial meeting [6] in order to denote the ability of these methods to respond to changing requirements in a controlled but flexible manner. The runner-up moniker, Lightweight Methods, did not highlight the applicability of these methods to projects experiencing high levels of change, and also carried the negative connotations of the term lightweight — these are serious methods and deserve consideration. The concepts of agile product development first emerged among Japanese automobile manufacturers in the 1980s. [7] These concepts quickly spread to North American car manufacturers and then their IT departments in the late 1980s. Once these ideas worked their way into the IT community, they quickly spread to other organizations and industries through exposure in software development conferences and journals. Naturally, several different approaches, or methods, evolved that incorporated these new product development ideas into a software engineering and development context. While they first emerged as software development methods, these methods have been adopted more broadly. Scrum, for example, has been used as a general project management approach in non-software projects, [8] and agile techniques have been customized into methods for other industries, such as Lean Construction. [9] While the principles described in this book are generally applicable to most new product development scenarios, the discussions and examples are mostly from the software development world, where most of the research and work on agile methods is taking place. [1]Beck, Kent. Extreme Programming Explained: Embracing Change. Boston: Addison Wesley, 1999. [2]Schwaber, Ken and Beedle, Mike. Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002. [3]Palmer, Steven. "Feature-Driven Development." Borland Developer Network Web site. <http://bdn.borland.com/article/borcon/files/2136/paper/ 2136.html>. [4]Poppendieck, Mary and Poppendieck, Tom. Lean Software Development: An Agile Toolkit for Software Development Managers. Boston: Addison Wesley, 2003. [5]Cockburn, Alistair. "Crystal Light Methods." Available at <http://alistair.cockburn.us/crystal/articles/clm/crystallightmethods. htm>. [15]Highsmith, Jim. Agile Project Management. Boston: Addison Wesley, 2004. [6]Highsmith, Jim. "History: The Agile Manifesto." Agile Alliance Web site, 2001. < http://www.agilemanifesto.org/history.html>. [7]Aguanno, Kevin. "Ever-Changing Requirements: Use Agile Methods to Reduce Project Risk." Proc. Informatics 2004. Canadian Information Processing Society (CIPS). May 2004. [8]Aguanno, Kevin. "Manage Change Better With Scrum." Inside Project Management. 2.8 (2002) 1–6. [9]The Lean Construction Institute Web site is available at <http://www.leanconstruction.org/>. Why do we Need New Methods? 1. 2. In the down face ofrequirements changing requirements, traditional project management "best practices" suggest that we try to Lock to form a baseline, Implement change control, and 3. Fall back on the documented requirements or the contract as means to enforce the change control. Lock Down Requirements. Page 2 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition The purpose behind this technique is to document the requirements as of a single point in time and then get those requirements "approved" (signed off by the sponsor) to provide a baseline against which further changes can be measured. Having such a baseline allows the impact of new changes to be assessed and a set of metrics (usually budget and timeline) that are used as negotiating points for accepting the changes. Implement Change Control. Once the baseline is in place, any scope discussions can refer back to the baseline to see if features are covered under the existing scope or form new requirements. New requirements will require an impact analysis that estimates the effect of the changed requirements to the budget, timeline, risk, etc. of the project. For changes to be accepted by the project team, and for the baseline to be updated to reflect the newly approved scope, the project sponsor signs a change authorization document that grants the formal approval to update the approved budget, timeline, and scope baselines. In many environments, this includes changing signed contracts. Fall Back on thebeDocumented As discussed above, whenever there is a question about whether a feature is to implemented Baseline. by the project team, the team can refer back to the documented baseline. Any difference will have to be handled through the change control process. Often disputes erupt about whether a feature is new, or just a "clarification" to an existing feature that is already part of the baseline. In most projects, the baseline is never 100% clear, and negotiations are needed to resolve different interpretations of the baseline. While these methods may appear to work in theory, in practice they lead to chaos and dramatic project underperformance. "Junior" project managers — those without a lot of real-world experience — will usually err by being either too lenient, and allowing too much change to the baseline without triggering the change control processes (in the interest of customer satisfaction), or err by being too strict, and refusing to accept changes to the baseline. Sometimes the latter approach leads to irate customers as they are told that changes will be deferred until the next release of the product to avoid delays to the release of the initial project scope baseline. Either approach can lead to project underperformance. In the first case, projects may go way over budget and may be late due to additional features being added in a haphazard way by the project team in response changing customer whims. In the second case,[10] projects may that go over budget and16 may be late the extra work and delays assessing the The StandishtoGroup, in their ground-breaking Chaos Reports first noted approximately percent of due all ITtoprojects are successful. Thecaused rest arebyeither late, over changes the baseline andto the often contentious negotiations with the customers. budget, deliver only a fraction of their original scopetobaseline in order meet their time or budget restrictions, or are cancelled altogether. Many in the IT industry were initially shocked by these results, but soon realized the truth behind them. IT projects, especially software development projects, are different from more traditional projects in that they are new product development projects with a number of unusual n At the early design stages, the intangible nature of most software leadscharacteristics: to difficulties in communicating design and vision in an easily- understandable way. n n n Progress is often hard to assess, given the intangible nature of the deliverables. They are usually trying to create unique products with few available analogs for comparison. The tools for building software (programming languages) are constantly changing, often mid-way through the project. n The industry standards that the software must support are constantly changing. n The building blocks (computer hardware, operating systems) are constantly changing. When dealing with all of this uncertainty, of course there is going to be a high level of change during a project. Now add to this a reality of today's business world: with a global economy and the faster pace of today's business (working in Internet time), no set of requirements will stay the same for very long. A competitor comes out with a new product. Government legislation changes. Your company is bought out by another one with a different strategy. An organizational restructuring results in you having a new boss who wants to make a mark and who wants to redirect your priorities. Many different forces of change are at work in our world, we cannot control these sources of change. The concept of change control is a misnomer: we cannot "control" these factors, nor can we control the [10]Theand Standish Group. The CHAOS Report. 1994. <http://www.standishgroup.com/sample_research/chaos_1994_ 1.php>. changes that they generate. What we can do, however, is manage how we adapt to these changes. What is Different about Agile Methods? Agile methods, at their core, are all about managing the impact of change on a project. When change occurs, these methods provide ways of allowing that change to be introduced to the project in an orderly way that attempts to maximize the benefits for the sponsor, while controlling the risks that the change introduces. In traditional product development lifecycles, such as the Waterfall Method, [11], [12] there is a design developed, then the product is developed according to that design, then the product is tested to determine how well it adhered to the design. Design changes introduced during the development or testing portions of the project cause chaos, in that they require the project to stop dead in its tracks and cycle back to the beginning design phase. If these changes occur late in the project, the resulting delays and increased costs can skyrocket. (See Figure 1-1.) Page 3 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Figure 1-1: Boehm's cost of change curve [13] shows the exponentially higher cost of making changes late in a project. Agile methods share some common characteristics that allow them to respond better to change. These characteristics are discussed at greater length throughout this book. Iterative and Incremental Development. Agile methods break down the development of their new products into a number of repeating cycles called iterations. Each iteration builds upon the last, adding additional layers of functionality. This allows the product to grow much in the same way that an onion or a pearl grows by adding layers. Starting from an initial kernel of functionality, over time (and several iterations) the product becomes more and more complete. This provides delivery of some functionality early in the project, and then regularly throughout the remainder of the project. By using short iterations, agile methods keep the feedback cycle short, allowing responsiveness to change, and reducing the risk of building "the wrong thing" Shortmore Iterations. based on unclear or changing requirements. Progress Viaelements Completed Features. Rather than trying to track progress by measuring percent completeMeasured on intangible such as design, agile methods track progress by fully-completed and tested features. Progress is measured by the percent of features that are complete and ready for the sponsor to review or deploy. This avoids the Vaporware Syndrome, where functionality is "mocked up" (faked) or features are not properly developed in order to meet a timeline or budget constraint. Then, when a sponsor seeks to deploy the product, the truth is revealed — that a lot of additional work is still required to "finish the job." Open, Flexible Design. Designs are flexible and extensible using open standards wherever possible. Since the full set of requirements may be unclear at the beginning of the project, and will likely change anyway, prepare a flexible, extensible design that will allow you to add on features to support new requirements as they emerge. There is always the risk of some rework to incorporate complex requirements, but often the impact is offset by the other benefits gained by using agile methods. Empowered Teams. Teams of specialists who know their jobs well and have the experience (and maturity) to decide for themselves how best to approach the problems at hand. Instead of imposing a design on the team, let the people who know best how to implement the details decide how they are going to do the work. This often allows for more flexibility in a system than is usually found in a more traditional, centralized design. Personal Communications. Rather than focus on producing written documents to communicate design decisions, technical approaches, and other normally-documented items, agile methods suggest that teams work in shared physical environments. Speaking face to face, perhaps with the support of a whiteboard for drawing diagrams, is a much more efficient way of working out design details. It is easier to update a design on a whiteboard, a design that is shared in the minds of a room full of people, than to update hundreds (or thousands) of pages of design documents. As we will see later in this chapter, many large projects have failed because of the reliance on written documentation to communicate design. While written documentation has its place on agile projects (as discussed in Chapter 9) teams need to seek opportunities to discuss approaches verbally to capture nuances not reflected always in documents, and to provide a fast way of asking (and answering) questions to ensure comprehension. Page 4 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Using these common characteristics, the creators of the various agile methods have produced a variety of approaches, each emphasizing different aspects. No single agile method is "better" than the rest — they all have their strengths and weaknesses — yet employing them can often lead to some significant benefits for the sponsor and for the project team. [11]Royce, W.W. "Managing the Development of Large Software Systems: Concepts and Techniquees." Proc. WESCON. (1970) 1–9. [12]Aguanno, Kevin. "The Waterfall Development Method." Inside Project Management. 2.8 (2002). [13]Boehm, Barry. Software Engineering Economics. Upper Saddle River, NJ: Prentice Hall, 1981. What are the Benefits of Being Agile? While agile methods may not fit every project, they do provide valuable benefits when applied against specific business problems. Consider each of these benefits when evaluating whether a particular agile technique may be of use on your own project, as each technique puts a different emphasis on the different benefits. There are three main types of benefits from agile techniques: reducing risk, improving control, and improving communications. Each of these benefits has a number of aspectsReducing that are detailed Risk below. Of all three benefit types, reducing risk is perhaps the most significant. The benefits from improved control and improved communications largely lead to reduced risks themselves, sodifferent we should put extra on will discussing the use of agile techniques forbuilding the reduction of risk. While risks may be categorized in many ways, in thisemphasis chapter we look at three specific risks: the risk of (or doing) the wrong "thing;" the risk of building the right thing, but poorly; and the risk of being stuck in an endless cycle of design updates and reviews due to changing requirements or high levels of complexity. There are other risk-reduction benefits, but these are the three that I have found to be easier to sell to your project sponsors and team members, as they help avoid concrete, measurable impacts when these risks are left uncontrolled. Building the Wrong Thing As one of my primary specialties, I spend a lot of time reviewing (and correcting) troubled software development and systems integration projects. When I first come onto these projects, I interview all the main project stakeholders. Of course, one of my first stops is the desk of the sponsor. Something that I have heard repeatedly from sponsors of troubled projects is a variation of the phrase "They gave me what I may have asked for, but that was not what I meant." This is an indication of a serious disconnect in expectations that can be improved with better communications. There is nothing better on a project than having actively-involved stakeholders who work closely with the project team reviewing the work in progress, answering questions as they arise and providing immediate feedback. Imagine managing one of these projects — you would never be concerned about acceptance of the final deliverables, since the approvers were providing you their feedback throughout the project, ensuring that what you created was aligned with their expectations. Agile techniques realize that documentation is a poor means of communications. Writing down requirements may help some people better understand the "thing" they desire, but you need to Some people are visual learners. No matter how detailed (and thick!) a requirements document becomes, these people will not be able to relate the document to their supplement the written documents with many discussions and joint design reviews to ensure that you capture the nuances that sometimes cannot be put onto paper. mental vision for the product. In fact, I have personally seen one project sponsor hold a two-inch-thick binder filled with detailed technical specifications, shake it up and down a couple of times in her hand, and comment that since the document is so obviously thick and heavy, that it must be correct. She signed off on the document without even opening up the binder! For people like this, creating more and more detailed specifications is not going to solve the problem. Even they do attempt to read the document,Intheir eyes are going to glazea over the first fewofpages, and of they will drift Agile methods adapt a technique borrowed from theifmovie industry called "storyboarding." storyboarding, you create visualafter representation the "flow" a movie, to are sleep. Youthinkers need a will different approach. other than the written script to which they can relate, and get a sketching out visually what each shot will look like. Then, thoseoff who visual have something better sense of what you are proposing. In agile software development, we do this by creating "use cases" or "user stories" that give a simple, task-oriented view of what people will need to be able to do when using the system. The specifications are created from the user's perspective, focusing on the functionality that is demonstrable and that performs some business function. We don't "storyboard" database optimization algorithms — no user or sponsor will likely be able to understand the technical details of such a work component anyways, except at the most general levels — stakeholders do not even think of such features, or if they do, they just assume them to be in the project anyway. You can "storyboard" a transaction or use case by sketching out the user interface (the screen) and the changes that appear on that interface as the various steps of the use case are completed. This will help visual thinkers get a better feel for what you are proposing, they can better understand how it relates to how they perform their jobs Gone are the days when the technical people get a written specification, create andusability then hand it back to the sponsoring group claiming that they are done. Now, today, and you can something, get some early feedback. sponsors are more astute, taking a more holistic view of project success: the real measure of success they use is not conformance to the written requirements, but rather the achievement of the business case benefits that prompted the funding of the project in the first place. Sponsors are demanding a seat at the table, and a chance to provide some feedback during the development of the Page 5 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition project's "product." The close involvement of sponsors and other stakeholders during iterative product development through the use of end of iteration reviews, allows stakeholders to provide guidance to the project team that will avoid the "you built what I asked for, not what I wanted" situation discussed earlier. It also has an added benefit of allowing On many projects, especially where the project is creating something thatapproach the sponsors have never had before, the true requirements are often not known or understood. a more adaptive to changing requirements. Sometimes these projects are reactions to external forces beyond the sponsor's control, and about which little is currently known: n New government legislation that will change regulations affecting how the organization carries out its business, n Changing consumer and Customers demanding nnew features to matchpreferences, a competitor's newly announced offering. In these (and related) situations, the sponsor will not know all of the detailed requirements at the start of the project. Instead, enough will be known to get started, and the rest of the requirements will be discovered or fully explored during the course of the project. In these cases, it is sometimes better to "just get started" and then figure out the details later. I once had the challenge of building a new software system for a government body to allow the automation of some processes to meet service availability and Like most proposed government legislation, by the time it gets approved and turned into law, it goes through many changes as a result of negotiations with the various responsiveness targets proposed by upcoming legislation. The legislation, when passed, would require the immediate availability of the supporting information systems to political parties and the influence of lobbyists. While the final requirements would not be known until the law was passed, we needed a system running days after the support the new regulations. proposal became law. What were we to do? The use of agile techniques made this process much simpler. We started by building the pieces that were not likely to change, and demonstrated increasingly more complete versions of the system through our end of iteration reviews. The specialists in the government department, who were closely monitoring the current state of the legislation and the direction of the political winds, gave us feedback at each stage that allowed us to adapt the system to the prevailing concept of what the final legislation Traditional methods, where one waits for a signed-off requirements document before starting work, would have led to long delays before we could start, numerous change would look like. In four months, we developed and tested the complete system, and it was ready the day the legislation was passed into law. request forms that would have been caught up in the government bureaucracy awaiting approval, and a delivery date that would have been months behind the required (legislated) product availability date. If we had not accepted any change requests until we were done (one common response to this type of situation), we would have built what was originally asked for, but not what was required at the time of completion, due to the many requirements that had changed. The project output would have been useless. In this real-world example, agile techniques saved the day. Building the Right Thing Wrong Assuming we managed to build the right thing for the customer (that is, we completely and accurately understood the customer's requirements and expectations, and managed to build a product that met those expectations) there is still a major product risk left to consider. We may have built the right thing, but we may have done a poor job building it. In other words, we may "have built the right thing wrong." Quality should be a concern for every product development effort, whether that product is computer software, a bridge, or a consulting report. Dr. William Edwards Deming, the guru of the revolution in quality management that took over the business world in the 1980s and 1990s, tells us that quality needs to be designed into a product development process. More simply: we need to find ways of ensuring that barriers to quality are removed at every step in the process. In the software development world, quality is usually addressed through various types of testing at the end of the software development process: unit testing, integration testing, usability testing, and others that all culminate in customer acceptance testing. One of the major reasons why most software development projects run over budget and behind schedule is that this testing happens only at the end of the project. Defects are found late in the project lifecycle, leaving little time to fix them. When a design defect is found, theand implications disastrous project team must revisit the designs,development make updates, change software that wasAll developed One solution to this problem, one easilyare addressed by— thethe agile techniques of iterative andinitial incremental is the use ofthe continuous testing. agile methods uponevery thoseiteration delivers fully-tested and functional deliverables. The completeness of are structured around iterative and incremental development. Using thesebased methods, updated (and the changes may ripple throughout all areas theportions softwarethat application) and then start iteration the testing process all over again. Just these defects thosedesigns deliverables increases with each succeeding iteration, butofthe are developed in each need to be properly working forone the of iteration to be can lead to a delay of many months and the associated increased costs.This We means need tothat findtesting a way needs to design quality into the software considered complete. to happen in every iteration.development process to avoid these costly latecycle quality issues. Testing during each iteration means that defects are found much earlier in the development cycle. This allows more time than the traditional "test at the end" methods for fixing these defects. More importantly, critical design-related defects may be uncovered much sooner. As Boehm points out in Figure 1-1, the later a change (or, by extension, design defect) occurs in a project, the greater the cost of incorporating the change. Identifying design defects early on is critical. Page 6 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition I once had a case where my team was one month into an agile development project. We had two-week iterations, and were at the end of our second end-of-iteration review. The project sponsor had pulled in an external reviewer to assess our progress and approach. With a concerned look on his face, the external reviewer announced that a new corporate standard for user interface design was just announced that we would have to live by on our project. Unfortunately, the new standard required us to significantly redesign how we were building the user interface for our application. Essentially, about half of our work over the prior four weeks had to be discarded and done over again. The sponsor was not happy about this. That is, until I explained the impact on the project (and his budget) if we had not been using an agile development method. If the first time that a reviewer had seen our work and noticed the non-compliance with the new standard was during the traditional "user acceptance testing" phase at the end of our eight month project, we would have needed to discard months of work completed to that point in time — a much greater impact than the couple of lost weeks that we were really facing. The sponsor immediately saw the value in iterative delivery and mandated the use of agile development methods (in this case, Scrum) on his future projects. Another benefit to testing in each iteration is the greater amount of testing that generally takes place under these approaches. Additionally, through the regression tests required to ensure that the incremental development does not break portions that were developed earlier, the initially-developed portions are tested over and over again, increasing the chance that the initially-developed pieces work as they were intended. One way to ensure this is through the practice of test-driven development, where we design the tests first — tests designed to test that the application Getting will meet the requirements — and then use the tests as design input into our development process. This Stuck in "Design Churn" way, we can use what will be the eventual "acceptance tests" as the unit and systems tests performed by the programmers. Running the relevant acceptance tests in each iteration means code is more likely to workfor asevery expected, since there are a do greater of opportunities to of fixproject. identified defectsthat and then retest again during Agile methods arethat not the necessarily the best methods project; however, they havenumber a lot to offer certain types Projects benefit the most from the use of agile methods are those in which the requirements are either unclearsubsequent or evolving.iterations. If you expect a high level of requirements change during a project, then traditional Peter Coad and Jeff DeLuca were brought on to one of these projects methods in their notorious "Singapore" simply will not work. project. [3] This project, to develop a commercial leasing system, had such a complex design that no single team member could keep the entire design in his or her mind. To compensate for this complex design, the team had developed thousands of pages of documentation (over 3,500 pages of use cases, class diagrams, etc.) in which they captured the design and worked out the complex component interaction issues. The problem was that there were continual changes occurring that required them to review and update these 3,500 pages of documentation to incorporate the impact of each change. Obviously, this took a lot of time, and by the time the changes were incorporated into the designs, more change had occurred. The changes were sparking additional changes, and the team was stuck in the dreaded cycle of "design churn." The sponsor, frustrated with this lack of progress, fired the original development team and brought in Coad and DeLuca to try and find a way out of this problem and start developing usable software. To break out of the vicious cycle, Coad and DeLuca decided to take the pieces that they could understand clearly, and that were reasonably well-defined and stable, and build them first. By completing these simpler pieces first, visible progress was demonstrated to the sponsor, usable software started evolving, and the project became "unstuck." While the initial pieces were being built, the design team picked up another discrete piece and designed that piece enough that development could start on it, and so on. This process works as long as the overall design uses open standards, and is flexible and extensible. (A similar process was used to break out of the design churn encountered by Kent Beck, Ron Jeffries, and the rest of the C3 Team on the Chrysler Comprehensive Compensation system, [16] discussed later in this book.) Another side benefit of this overall approach is the ability to procrastinate — that's right, procrastinate. If you are facing a project scope element where the requirements are not stable, why not delay starting on the design and development of that piece as long as possible? Work on other pieces during the initial iterations, and push the scope elements full of uncertainty to future iterations. In this manner, you can deliberately delay working on components whose requirements are likely to change for as long as possible. Thenot longer you wait, the greater of the requirements moreuntil stable is known the solution youthis aretechnique enhancing Now, I am advocating that you push the out chance all components with unclearbecoming requirements lateas in more the project. Thisabout would beemerging foolish. You needthat to use through each iteration. Once a requirement is stable enough to start work, then that is the time to start working on it — to start earlier, you risk too much rework and are wasted judiciously, balancing the benefits of delaying the start of a project component with unstable requirements with other techniques that reduce other risks. In fact, there times when you may wanteffort. to do the exact opposite. Sometimes, the way of getting out of a design dilemma is through experimentation. If you are not sure how to overcome a design issue with certainty, or if you are faced with competing approaches and cannot make up your mind which is best, try conducting an experiment to see which approach is better. Take a page from the Rational Unified Process (RUP) playbook, and schedule the areas of greatest uncertainty (or risk) first, allowing you to perform experiments to validate assumptions, remove technical uncertainty, and establish an approach that can work. Sometimes this approach will allow you to "prove" a design through demonstration long before you could "prove" it on paper with supporting design details. Use these techniques as different tools in your toolbox. Do not pick one tool and try to apply it to every situation, but rather learn all of the tools and learn when each one is best employed. In other words, use the right tool for the job at hand. Improving Control In addition to reducing risk, agile methods allow the project manager to improve his or her control over the project. This may sound Page 7 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition counterintuitive, but in practice, it is true: using a less-rigid, structured approach allows the manager to better control the project in situations where there will be high levels of change on the project. In effect, the agile methods allow the manager to better respond and adapt to changing requirements in a way that does not lead to design churn, confrontational contract negotiations, and angry stakeholders. Generally, control is improved through a number of mechanisms that are common results of all agile methods: n n Frequent delivery of working code means progress is objectively measurable, More chances for stakeholders to provide early feedback and redirect project priorities where necessary increases the chance of delivering real value, n n Misunderstanding are surfaced earlier, avoiding late-lifecycle design changes mentioned earlier in this chapter, and The sponsor has the ability to end a project early and still get measurable benefits. Frequent Delivery means Measurable Progress By breaking the project lifecycle down into a number of short, recurring design-develop-test iterations, the functionality being developed that meets the business requirements can be delivered in small increments, each providing business value. When facing highly-complex or risky projects, sponsors and managers have a much better read on the real progress of a project when actual progress is visible to everyone on a frequent basis. Without the visibility of real progress, there is little management control that can be meaningfully exerted to correct the course of the project or to deal with performance issues. Consider a traditional waterfall-type development process. The team designs a solution, builds it, then tests and perfects it before handing it over to a project sponsor for review and acceptance. If this whole process was 18 months long, the sponsor will have no means by which to measure progress until he or she gets access to the completed forallow the acceptance review. Until into the product is ready review,on the sponsor has no concrete means byFor which to measure the team says Instead, agileproduct methods you to improve visibility real progress byfor focusing user-visible features or transactions. example, let usprogress. look at anIfapplication with ten they are 90% complete, who user-visible can argue? The next(such weeks, say they are 91%,application). 92%, and then 93% complete, there is still nothe evidence features aswhen menuthey options in a software When you can demonstrate that four by which to question or this progress. of the ten are complete and working, you can claim you areargue 40% complete, and have a sound basis against which to measure that progress. Visible progress reduces uncertainty. It also puts sponsors at ease — especially those who may have gambled their careers on the success of your project. Showing them real progress will ease their concerns, increase their satisfaction, and reduce their need for micromanaging you and your team. Feedback and Redirection means Delivering More Value End-of-iteration reviews allow sponsors and other stakeholders a chance to review the work performed to date. This introduces an opportunity for them to provide feedback. You may hear that what was developed was perfect. More likely, you will hear feedback such as one of the following: n What you delivered may be what I asked for, but not what I meant (a misunderstood requirement). n What you delivered does not work properly (a defect). n n Now that I see what you have built, I have thought of something that would make it even better (a new requirement). Now that I see what you have built, I realize we forgot something (a missed requirement). n Something has come up — I need you to do that a different way (a change). No matter which of the above types of feedback you receive, if you can incorporate the feedback into your next iteration, you will bring the project closer to delivering the business value that the sponsor needs. There is no point in sticking to the original scope baseline and deferring change until the end of the project (or for another product version/release) — doing so will mean that you deliver something to the sponsor that he or she cannot use. Since you have not adapted to his or her changing business requirements, your deliverable is now based on obsolete requirements and will exist solely as "shelfware" — a useless effort and expenditure of funds unless you can make the changes to the product Capturing and responding to feedback at the end of each iteration will help you be more responsive to your sponsor's changing business to bring it back in line with the sponsor's current business needs. priorities, and will help you better deliver a product at the end of the project that will deliver some business value, rather than no business value (as would happen if you did not respond to the changes). The feedback will not be just changes to what you have already built, but it will also help you reprioritize what you are planning to build next, to ensure that you are focusing on the pieces that will deliver the greatest benefits. Both the sponsor and the project manager can better control theChange delivery of business value. Early Feedback means Lower Cost of Getting feedback earlier in the project will allow changes to be incorporated earlier. As pointed out in Figure 1-1, this means that design changes have a greater chance of being surfaced and acted upon earlier in the product development cycle, when the costs of those changes are the lowest. Page 8 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition End Early with Measurable Benefits Another benefit of this approach allows the sponsor control over the level of quality (completeness) of the product at the end of the project. At the end of each iteration, the included features should be fully functional and tested. Theoretically, it would be possible for the sponsor to release (deploy) the product at the end of any iteration, allowing the sponsor to realize several benefits: n n If the product is the first to address a niche in the marketplace, early deployment may allow the sponsor to gain marketshare well ahead of any competition. n If the contents of the early iterations are selected carefully, then the sponsor may choose to deploy a partially-completed product to gain immediate benefits of the If the contents of the iterations are continually reprioritized at the start of each iteration, focusing on the items that are most important first, then at some point later in the completed portions, before the full product is completed. In some cases, the benefits from early deployment may help offset (or even pay for) the costs of completing the project, all of the high-priority items will have been developed, and the only remaining items to be developed will be of marginal value to the sponsor. The sponsor may full product. decide to forego developing these low-priority features, deeming the product to be "good enough" for general rollout. Improving Communications Finally, agile methods foster better communications among team members than traditional product development methods. Communications is key to any project, and all good project managers know that 80% of the job of a good project manager is facilitating communications, whether it be communicating status, discussing solutions to problems, notifying others of dependencies, or ensuring that everyone shares the same project vision and strategy. Once, on one of those "take a student to work days," I had a Grade 9 student assigned to me. His task was to shadow me for the day, and then write a report for his class on the role of a project manager. For the entire day, the student followed me to meetings, watched me working at the computer, and listened to me calling project stakeholders to gain insight or to share information. Only at the end of the day, before leaving work, did I find out that the student was the son of an executive several layers above me in the organizational hierarchy. That made me wonder: did I do my job well, did I look professional, did I make a lasting impression? I hoped that when the boy's father asked who he shadowed at work that day, and how things went, that I would get a glowing report. About a week later, I received a copy of his school report via internal company mail along with a short note. The report described the day-to- day job of a project manager as being the most fun job in the company — you get to talk to your friends all day on the phone, stop by their desks for a chat, and send them emails. You don't have to do any real work! I was mortified. What would my executive think about my job performance? I opened the note with shaking hands and read Sounds like my son doesn't get it yet. Maybe he's too young to understand, but it seems to me like you are focusing on exactly the right thing — communications. That's the key to running a successful business, and a successful project. Good work. I learned a lesson that day, about the importance of communications. I was never conscious of what I was doing, but that day opened my eyes. Since then, I have deliberately crafted communications plans for my projects, and have designed project teams to maximize the flow of information and knowledge. Co-Located Teams There is tremendous value to be gained from using collocated teams on a project. These are teams where most (if not all) team members work in the same location, preferably with adjacent desks. Later in this book we will delve into this topic in more detail, but in my experience, the direct benefits of collocated teams are experienced Whiteboarding. through several means. Instead of crafting long-winded, complicated emails or documents describing issues and suggesting design approaches, when the team members are all in one location, someone can simply tap others on the shoulder and ask them to step over to a whiteboard. By drawing diagrams, making quick changes, erasing and redrawing, and through immediate feedback from others, solutions to problems can be quickly and effectively described, modified, and agreed upon or rejected. This is what Cockburn describes [14] as high-bandwidth communications. This beats the long delays in trying to do the same problem solving via long strings of emails back and forth between team members, or via slowly-evolving documents. I once worked in an environment where we needed to boost the productivity of athe team building a of Web application. We moved the graphic designer into the same office as the Looking Over Shoulders Others. two developers. There was an immediate improvement in the performance of the team, all attributable to better communications. When the designer created the mockup for a new Web page, he could simply ask one of the developers to turn around in his chair and take a look at the design while it was on the screen. The developers could immediately say whether the design was "buildPage 9 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition able" or not, and could ask the designer to make immediate corrections that would prevent much later problem solving and rework. Similarly, the designer could review the Web pages as the developers built them to give feedback on whether they were turning out as intended. Finally, the two developers were able to help each other out with technical problems, reducing the time spent on problem-solving and fixing defects. Over all, it was the most effective management change that we implemented on the project. The improved communications gave us greater control over the project's outcome. Non-Verbal Communications. The majority of the information we convey (approximately 70%, by some estimates) is through non-verbal means. This includes body language (nervousness, hesitation), tone of voice (sarcasm, uncertainty), and eye contact (or the lack thereof). Sometimes, more is revealed by the topics that are avoided than by the topics that are discussed. By working in a collocated environment, we avoid the use of impersonal communications vehicles such as email and documents that convey only 30% of the meaning; instead, we get to use face-to-face conversations that allow us to take advantage of the full 100% of what information is being transmitted. This allows faster and more thorough communications. It allows us to "read" the other person in a conversation to try and determine whether they really do understand what we just said. Sometimes we have to work remotely, but even then, if a team has worked together before, and knows each others' working styles and personalities, then teleconferences are an acceptable alternative that still allow a lot of non-verbal transfer of information. Greater understanding and faster transfer of knowledge and information: why would you ever Short want Daily to workMeetings apart again? By holding regular (but short) daily team meetings, team members can share their successes and problems with each other. Following the lead of Scrum, agile 1. What they have justmeetings completed sowhen that others who may be dependent uponpieces the completion of that work may get immediate notice are — best team members briefly share three of information: of its readiness, and to give a measure of visible progress to the team's efforts. 2. What they are about to work on next — so that team members will be aware of what others are doing and can able to help out or provide advice based upon past experiences. This also may bring other dependencies to light that the team may not have been aware of at first. 3. Any issues that are slowing down or halting progress — if facing technical issues, other team members may be able to help, or the project manager may be able to find assistance from outside of the team. If the issues are organizational or administrative, the project manager can take immediate actions to remove the Employing short daily meetings allows thethe project manager to get notice of problems (andor thus more time to help act upon them before intoto big issues). barriers. If the issues are personal, project manager canearlier seek out assistance, training, whatever other is required for thethey teamballoon members maximize Additionally, project managers can better ensure steady progress with these their meetings by highlighting crossdependencies and offering a chance for team members to performance. share their tacit knowledge to solve issues. Of course, the lengthy dialogues that might be required to impart knowledge or solve problems do not happen in the meeting — they are handled through follow-up conversations between the team members affected — rather, the meetings are used to highlight the need for these follow-up conversations. Close Customer (Sponsor) Involvement Another way of improving control over the project through improved communications is by having the project sponsor, or a customer representative involved daily in project meetings. The immediate and regular access to someone who understands the business situation that gave rise to the project, who understands the requirements, and who is authorized to make decisions regarding the project can greatly improve control over the project schedule, budget, and scope. In Extreme Programming, we call this the On-Site Customer, while in Scrum, this is referred to as the Product Owner. There are three main ways in which this improved level of communications with the sponsor can be used to help control the project. By having ready access to a decision-maker who understands the business requirements and the project's business case, the project manager can quickly escalate any issues requiring a decision or action within the sponsor's organization. Usually, this role is held by someone with authority who can move roadblocks that the project and Easyof Escalation. manager cannot resolve without assistance. The quickQuick communication these issues helps speed up the project, avoiding costly delays. Snap Decision-Making. In addition to the ability to quickly escalate issues to the sponsor or other key decision-makers, close customer involvement in the daily happenings within the project allows you to contact a decision-maker immediately when a snap decision is required. No more struggling to find a decision maker and get a decision made. By having someone involved who is authorized (and willing) to make decisions, you can communicate your decision point requests quickly, Instant Feedback. As discussed earlier in this chapter, one of the big benefits of agile development methods is that you have regular opportunities for stakeholder feedback at the end of each iteration. Having close customer involvement in the project, however, leverages this benefit to even higher levels. Instead of waiting for end of iteration reviews for feedback, team members can bounce ideas or approaches off of the customer representative at any point during the project to get immediate, valuable feedback. This increased communications helps control quality by even further reducing the likelihood of "building the wrong thing." Page 10 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition As I have described above, there are three main categories of benefits from deploying agile development methods on projects, and each plays an important role in improving project control. While agile methods are not the right solution for every project situation, they do provide a means by which to increase control over projects where the requirements are constantly changing — projects that are notoriously hard to control using traditional methods. [3]Palmer, Steven. "Feature-Driven Development." Borland Developer Network Web site. <http://bdn.borland.com/article/borcon/files/2136/paper/ 2136.html>. [16]The C3 Team. "Chrysler Goes to 'Extremes.'" Distributed Computing. Oct. 1998, 24–28. [14]See Chapter 5 for more details on the benefits of high-bandwidth communications vehicles. Why do we Need This Book? There are many publications in the marketplace that describe the various agile methods and techniques. Yet, most of these discuss these techniques from the perspective of a team member who will be employing these methods in the performance of their technical development activities. Very few publications present the agile methods from the perspective of a project manager. Additionally, most of the existing publications focus on a single method or agile technique; there are few that discuss all of the most common techniques. This book presents techniques from many different agile methods, and compares the various methods in the context of these techniques. (I should note here that many of the discussions deal primarily with Extreme Programming — not because the techniques are not applicable to other agile methods, but rather because Extreme Programming is the agile method that has been most written about and most studied to date. When reading this book, when you read "Extreme Programming" consider that in most instances the statement will apply to most other agile methods as well.) Part Introduction This book combines the work of many experts into one volume. These areOne: the luminaries of the field — the people who invented some of these agile methods and techniques. The chapters in this book have been prepared by these experts both from previously (and updated) original works, The first section of this book, its introduction, presents an overview of what agile methodspublished are about, andnow a brief historyarticles, of how and they from camenew to be. appearing in this book for the first time. Chapter 1 — This chapter provides a brief overview of reason why agile methods were developed in the first place, and the major benefits to be gained from employing them. The author, Kevin Aguanno, is a consultant, teacher, and keynote speaker on agile development methods. He focuses on bringing agile methods out from under the software development umbrella and into the world of project managers. He has introduced hundreds of companies (and thousands of project managers) to agile development principles and techniques. Chapter 2 — For those who want to understand more about how these methods have evolved, this chapter provides a brief history of the major agile methods and describes how they interrelate with the Software Engineering Institute's Capability Maturity Model (SEI CMM). The authors of this chapter, David Cohen, Mikael Lindvall, Two: Managingmethods Agile Projects and Patricia Costa performed an extensive study of agilePart software development for the U.S.is AirDifferent Force through the Fraunhofer Center for Experimental Software Engineering at the University of Maryland. This chapter is a brief extract from their full report. The second section of this book explores how managing agile projects is different from managing projects following more traditional methods. This section takes a more holistic view from the project management perspective, rather than the specific agile techniques that are deployed on projects. Chapter 3 — Written by Kevin Aguanno, this chapter presents a brief overview of how agile project management is different from the project management approaches Chapter 4 — There is a lot of confusion between the terms and incremental. Each means a very different thing, yet agile methods presented by bodies suchiterative as the Project Management Institute (PMI). bring both together for the first time in a unique way. Pascal Van Cauwenberghe is a noted author, teacher, and speaker on Extreme Programming and other agile methods and techniques, and has prepared an excellent tutorial on the differences between iterative and incremental development approaches and the advantages from each. Chapter 5 — As one of the leading luminaries in the agile development movement, Alistair Cockburn has written numerous books, published scores of articles, and speaks regularly at software development conferences on agile principles and techniques. He is the developer of a group of related agile methods called, collectively, the Crystal Methods, and is one of the early proponents of using "use cases." Mr. Cockburn is one of the founders of the Agile Alliance, and a co-author of the Agile Manifesto. In this chapter, adapted from a series of articles he published in Crosstalk: The Journal of Defense Software Engineering, he takes his experiences from agile software development and applies them to the topic of project management in general. Page 11 / 13 Reprinted for CTS/316124, Cognizant Technology Chapter 6— Agile project managers mustSolutions walk a fine line between too much control, which destroys the benefits from flexibility Inc., thatKevin agileAguanno methods and too little MultiMedia Publications (c)provide, 2004, Copying Prohibited control, which will allow a project to degrade into chaos. Learning from the science of Complex Adaptive Systems, Sanjiv Augustine and Susan Woodcock propose a Managing Agile Projects, First Edition between too much order and too much chaos, the so-called chaordic edge. Chapter 7 — When requirements are constantly changing, documenting and rationalizing requirements — the practice of requirements engineering — becomes very challenging. Jim Tomayko, a professor of computer science at Carnegie Mellon University and a scientist of the Software Engineering Institute (SEI), presents a brief comparison between requirements elicitation in traditional and agile projects, highlights the related difficulties when working with requirements in agile projects, and highlights one of the advantages. Chapter 8 — One way in which agile projects are quite different from traditional projects, is in the level of involvement required from project stakeholders, and in particular, the project sponsor. Scott Ambler, a noted expert on object-oriented software development techniques, the developer of the Agile Modeling technique, and a widelypublished author presents in this chapter the reason behind the need for active stakeholder participation on agile projects. In addition, he presents some tips for ensuring that you get the most benefit out of your stakeholder involvement, and avoid some of the pitfalls. Chapter 9 — Scott Ambler contributes again to this book by providing a chapter on the reliance of agile methods on higher-bandwidth communications; for example, Part Three: With Agile Management Techniques than traditional project methods, agile methods require some focusing on face-to-face communications over written documentation. a different focus on communications extra attention from project managers in this key area. Ambler's contribution in this chapter is an update from material presented in his book Agile Modeling: Effective Now that we have discussed how agile projects are different from traditional projects, this section addresses a number of individual agile management techniques Practices forare Extreme Programming The Unified Process. that common to most agileand methods. Chapter 11 — While Chapter 7 we discussed theoverview need forofathe different approach to requirements engineering, thissection. chapter provides the Chapter 10 —inKevin Aguanno provides an agile management techniques presented in this details on how to conduct such a different approach. Kirstin Kohler and Barbara Paech are active researchers in requirements engineering, having published many journal articles in the field. Kohler is a researcher and consultant with the Fraunhofer Institute for Experimental Software Engineering in Germany, and Paech is the Chair of Software Engineering at the University of Heidelberg. Both share their extensive experience in this area to provide practical approaches to overcoming the challenges surrounding changing requirements on agile projects. Chapter 12 — As a frequent speaker and teacher on agile development methods, perhaps the most frequently-asked question I receive is "How do you estimate and deliver agile projects under fixed-price contracts?" While recognizing that time and materials contracts are the easiest under which to deliver agile projects, the reality in the business world is that these types of contracts require a large amount of trust between the sponsor and the delivery team — trust that is often not present. In this chapter, Pascal Van Cauwenberghe provides us with some good options for preparing fixed price contracts for agile projects. Chapter 13 — The focus that agile methods place on feature-based prioritization, design, and progress reporting changes the paradigm under which a project operates. To focus so much on user-facing features, requires that the project adopt a user-centric view of requirements and design. Larry Constantine, one of the founders (and leading proponents) of usage-centered design, first presented the contents of this chapter as an article in Information Age. This chapter presents the pros and cons of taking such as user-focused design approach, and shares a step-by-step process that managers can understand for performing user-focused design. Chapter 14 — Documentation: how much is enough? In Chapter 9, we talked about the preference for other means of communication. Yet in Chapter 11, we explored the need for requirements documentation. Where is the balance? In this chapter, Scott Ambler answers that question, providing an approach and some tips to help you prepare "just enough" documentation. Chapter 15 — One of the key benefits from (and requirements of) iterative development is the need for continuous testing. In this chapter, Ron Jeffries explores the different types of testing you will need to perform in an agile environment,Part and Four: tips for performing each. He also includes some tips on how to get your project teams to adopt the agile There is No Silver Bullet testing techniques such as automated regression testing. Jeffries is one of the To prepare a balanced view of agile project management, oneProgramming must look at method, the criticisms agile methods well. This section presents some of the shortcomings co-founders of the Extreme and isofathe well-known authoras and speaker in this field. and possible misrepresentations of the agile methods. Chapter 16 — While we discussed how to do create agile documentation in Chapter 14, we still need to focus on face-to-face communications as our primary means Chapter 17information. — No singleInmethod can address all situations. In this chapter, Kevin Aguanno describes theand types projects wherein shares agile methods can for playholding a valuable of sharing this chapter, Linda Rising, one of the leading experts in object-oriented design theofuse of "patterns," techniques agilerole, and those that might best be served through morethat traditional methods. no one-size-fits-all method: project managers should understand a number of different meetings first appeared in There STQE:isSoftware Testing and Quality Engineering. methods and be prepared to select the appropriate one for the project at hand. Chapter 18 — Perhaps the most damning of all the critics of any agile method, Gerold Keefer is known for his in-depth analysis of the research supporting Extreme Page 12 / 13 Programming and for his sharp (and well-supported) Reprinted for CTS/316124, Cognizant Technology Solutions criticism of some of the claims made by XP proponents. Keefer is president of a quality management consultancy MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited that specializes in helping organizations take a common-sense approach to Managing Agile Projects, First Edition implementing best practices like CMMI. Chapter 19 — Sometimes, the rapid pace of agile projects can cause problems. In this chapter, David Hussman, a noted speaker and author on agile development practices, discusses the problems caused by agile projects locally-optimizing for their own projects, and the management problems that result from having multiple agile projects with interface interdependencies. He doesn't leave us high and dry, however: he does provide us with a suggested risk reduction strategy for use when managing this type of situation. Chapter 20 — So, you have decided to adopt a whole agile method, or just some of these agile techniques, into your own organization. How do you combat the resistance of those who are comfortable with the traditional techniques? How can you convince others that their methods are not the best ones for high-change projects? How do you get the organization to change its official project management (and product development) methods? Kevin Aguanno addresses these — and other — questions in this chapter on "stealth" methodology adoption. All of us who have contributed to this book hope that you enjoy it and welcome any questions that you may have about the contents herein. At the end of the book you will find biographical information on each author along with an email address and (in most cases) a Web site address. Feel free to visit the Web sites for more information and email the authors with your questions or feedback. For those wanting more details on these topics, most of the chapters have included extensive end notes including supporting references. Browse through these end notes for additional sources of information. Page 13 / 13 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition by Kevin Aguanno (ed) Multi-Media Publications Inc.. (c) 2004. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Managing Agile Projects, First Edition Chapter 7: The Engineering of Unstable Requirements Overview James Tomayko, Ph.D. Reprinted/derived from an article of the same title printed in the Proceedings of the International Workshop on Time Constrained Requirements Engineering (TCRE), edited by Armin Eberlein and Julio Cesar Sampaio do Prado Leite, September 2002. Used with permission of the author. In a recent cartoon, a manager is seen walking through an area filled with programmers. He says, "You guys start coding and I'll go see what they want." This pretty well characterizes the situation of projects today. There seems to be a common belief that agile development methods reinforce this unfortunate attitude toward requirements. Conversely, my research has shown that an "agile attitude" toward requirements is a very effective means of acquiring them. [1] I have had 12 teams of from four to six engineers participate in Extreme Programming (XP) [2], [2] experiments in the past year. The experiments were primarily aimed at [4] however, observing how these teams go about their work, has led me to several insights into the requirements defect[1]reduction andAnot requirements acquisition; Smith, John. Comparison of RUP and XP. Rational Software White Paper, 2001. [2]Beck, Kent. Extreme Programming. Boston: acquisition process. 2000. Others have come to the same conclusions. [3] Addison-Wesley, [2]Cockburn, Alistair. Agile Software Development. Boston: Addison-Wesley, 2002. [4]Tomayko, James E. "A Comparison of Pair Programming to Inspections for Software Defect Reduction." Computer Science Education. 2002. [3]Tomayko, James E. "Using Extreme Programming to Develop Software Requirements." Soft-Ware 2002. Berlin: Springer-Verlag, 2002. 315–31. The (Old) Method of Up-Front Requirements Elicitation Current requirements elicitation methods reinforce improper beliefs. Many projects try to follow the waterfall software life cycle and other obsolete software development life cycle models. The requirements are gathered first in one big effort. [4] Frequently, these requirements turn out to be rife with omissions and misconceptions. Correcting them costs time and money. The result has been a movement toward more iterative models. [5] At first, these took the form of prototypes, both to find missing requirements and to examine the feasibility of solutions. [6] The history of iterative requirements gathering has itself gone through several cycles, of which agile methods are the latest. The trouble is that with each new iterative method the requirements elicitation process appears to become less defined. I feel [4] that the attitude towardsRequirements. requirements gathered early in the process is incorrect in that ones missed at that stage are considered defects when added later. My Davis, Alan. Software Englewood Cliffs, N.J.: Prentice-Hall, 1990. observations,[5]and the entire point of iterative processes, is that requirements are seldom omitted, they are just unknown. There is simply no way that the requirements of Tomayko, James E.problems "An Historian's View of Software Engineering." Proc. of the IEEEare Conference Software Engineering and even well understood could be known. Therefore, why even try? Requirements elicited byon agile methods in a more Education practical way. Training. Los Alamitos, California: IEEE Computer Society Press, 2000. [6]Leffingwell, D. and Widrig, D. Managing Software Requirements: A Unified Approach. Boston: Addison-Wesley, 2000. Requirements Elicitation in Agile Methods "User stories" or the like are just the beginning points of both the requirements gathering and development processes in agile methods. Early requirements are simply a place to start. We expect to add more requirements as more is known about the product. Conversely, the method of trying to gather all the requirements before starting development is almost certainly rife with errors and surely takes too long. "I'll know it when I see it (IKIWISI)" [7] has become a well-known requirements elicitation method. In effect, the early version of the product becomes a prototype. Agile methods are designed to appeal to clients that insist on IKIWISI. Prototyping in agile methods is even more rapid and produces smaller amounts of code than traditional prototypes. [2], [4] Developers that use Page 2 / 3 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition prototype-based life cycle models are familiar with the case of the client falling in love with the prototype so that they want to take it away as the product. Avoiding a situation where bad code and poor documentation characterizes the product makes the developer produce a less robust prototype. As a result, they are not as useful. Agile methods, which have the concept of a "spike"— a rapid development of a prototype that answers a single question about requirements content—avoid this problem of showing the client too much. In this way, client is kept from the responsibility of "getting the requirements right." There are no wrong requirements. There are simply some waiting to be [7]the Boehm, Barry. "Requirements that Handle IKIWISI, COTS, and Rapid Change." Computer. Los Alamitos, California: IEEE Press. July 2000. discovered. 99–102. Difficulties Caused by Agile Methods of Gathering Requirements This attitude toward requirements makes estimation and software architecture development more difficult, and verification easier, than traditional methods. Without knowing the final form of the product, or marketplace demands, estimation is going to be impossible to get correct. [10] It is little comfort that requirements omissions and changes caused by reacting to the competition make most estimates incorrect right now. Agile methods are likely to be right about the costs involved in the current cycle, but estimating is poorly understood for the unknown requirements of the next cycle. One thing that can be done is to fund the project one cycle at a time. However, there will be a time when knowing the total cost is necessary, as in contract work. In these cases, customers express the requirements as well as they can, and estimates are adjusted by the probable cost of later changes. For instance, if a project is estimated at $1 million, and prior projects of roughly those same characteristics have had the cost of "changed" requirements at around 20 per cent, then the estimate should be $1.2 million. Of course, as with all estimations, this can not be used without considerable historical data. The architecture chosen by the team during the early cycles may become just plain wrong, as later requirements become known. Rework of the architecture matches the [10]Thayer, Richard and Dorfman, eds.Programming. Software Requirements Los Alamitos, California: IEEE Society Press, refactoring principle Merlin, of Extreme Most of myEngineering. XP teams embrace refactoring, claiming thatComputer they would 1997. do it anyway, even if the requirements were stable. One student identified refactoring as rework, with its attendant negative properties, notably increased cost. Either way, Advantages of Agileare Methods Correctness significant refactoring is to be expected in an atmosphere where requirements relativelyfor unknown. Confidence in the requirements translates to confidence in the architecture. Aside from refactoring and effective prototyping, agile methods have other advantages for a situation in which requirements are unstable. Reliance on test-driven programming, a core principle of XP, means early detection of most minor errors, more certain detection of defects at integration, and early thinking-through of tests for a Graphical User Interface. [5] This is an advantage to any system. For this reason alone, requirements engineering is advanced by the developer knowing right away if a [5]Tomayko, James E. "Using Extreme Programming to Develop requirement can be tested. Software Requirements." Soft-Ware 2002. Berlin: Springer-Verlag, 2002. 315–31. Page 3 / 3 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition by Kevin Aguanno (ed) Multi-Media Publications Inc.. (c) 2004. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Managing Agile Projects, First Edition Chapter 4: An Introduction to Iterative and Incremental Delivery Pascal Van Cauwenberghe Overview Surprisingly, many people still wonder what is wrong with the safe and predictable, sequential-phased approach, also known as "waterfall." This is despite the fact that a lot has been written about iterative and incremental development over many years. Still, most people involved in software development cannot give you a clear definition of what those two words mean to them. When they are able to give definitions, they often contradict each other. Into this confused world, the proponents of Agile Development and especially Extreme Programming proclaim that they go beyond "traditional" iterative and incremental Definingdevelopment Our Termsmethods. What are we to do? How do we approach software projects? How do we reach our targets reliably, quickly, and efficiently? "When I use a word," Humpty Dumpty said in a rather scornful tone, "it means just what I choose it to mean — neither more nor less." Lewis Carrol, Through The Looking Glass. We must first choose what we want our terms to mean. A Phase: A period in which some clearly defined task is performed. Just imagine that we require the following phases: Analysis, Design, Coding, Testing, Integration, Deployment. has some inputs and some To Iterate: To perform some task inand multiple passes. Each Each phase pass improves the result, until the outputs. result is "finished." Also called rework. An Iteration: A period in which a number of predefined tasks are performed. The results are evaluated to feed back to the next iteration. An Increment: A period in which some functionality is completed to a production-quality level. A Release: Some coherent set of completed functionalities that is useful and useable to the intended users of the system. To illustrate the difference between iterative and incremental, imagine a project where we need to develop a system that has three functions: A, B and C. Each of the functions requires the same amount of work: one month. Thus, we have a three month project. With these definitions we can have a look at different ways to organize a software project. Figure 4-1: A comparison of iterative and incremental development models. Different Ways to Plan a Project The Waterfall — Straight to the Target The sequential, phased approach, better known as "Waterfall" is the simplest and potentially fastest approach: we analyze the problem, design the solution, implement the code, is test code (are fixsteps the coding bugs?), integrate then deploy. Done. The attraction of this process model itsthe simplicity: youwe doallowed each ofto the and then you are done. ifIf necessary, you want toand know how long the project takes, just add up the time required for each phase. These times are just estimates, so your total is also an estimate. But it makes following up on the project's schedule easier. For example, once analysis and design are complete, they will not be worked on again. n Remote stakeholders like upper level managers or The end-users whoofhave needattracts to know thekinds exactofprocess. simplicity this no model two people: They really just want to know when the outputs will be delivered. n Teachers and educators who need to present a simplified model of a process as a first, simplified introduction to the subject. Page 2 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Unfortunately, it is this first approximation that sticks in the minds. Or do students skip all the following lectures? The Spiral — Iterate to Incorporate Feedback Of course, it is never as simple as the waterfall process suggests: we do make errors during analysis and design. When Walker Royce [1] originally described his process, there were feedback loops back to analysis and design. They were quickly "simplified" away. So, this was the original phased, iterative approach: n Perform analysis, until you think you are ready n Design, until you think you are ready. Should you find any problems in the analysis, feed them back to the analysis. Perform another iteration of the analysis, to improve it. n Code the design, until ready. Should you find any problems in the design, feed them back. Perform another iteration of the design, to improve it. n Test the code. Should you find any problems, start another iteration of the coding. n Integrate and deploy. Feed back any problems you encounter. As Boehm [2] noted, the later a defect is caught, the higher the cost to fix it. We are therefore encouraged to only proceed cautiously to the next phase if the previous phase relatively complete. As software have noted, the likelihood finding becomes asoutput we come to the laterisphases. ThisIn is more because Inisshort, you go sequentially throughengineers the phases. Some phases have moreofthan onedefects iteration if we seehigher that the of that phase not perfect. thaneach one phase delivers more precise, more "testable" output than previous phases. sense, theawaterfall is the optimist's interpretation of thethe spiral model. There is one management problem with the spiral model: how do you schedule the iterations? How many iterations will be needed? This makes estimating and tracking the project's progress — more difficult Better and unpredictable. Iterative Development Getting All the Time Where the spiral process views feedback and iteration as exceptional events, iterative development assumes we will make mistakes, we will need feedback, and we will need several iterations before we get it right. In iterative, phased development we design our project plan around the idea of iterations and fit the phases in them. For example, we can plan to have five iterations: n n In the second iteration we will do 30% analysis, 50% design, 20% coding n n In the first iteration we will do 90% analysis, 10% design In the third iteration we will do 10% analysis, 30% design, 70% coding In the fourth iteration we will do 10% design, 50% coding, 40% testing and bug fixing Iterative Development with Incremental Delivery — Growing Software n In the fifth iteration we will do 50% testing and bug fixing, 30% integration, 20% deployment. One complaint we could have with the previous process is that it takes too long to see the results of the work. Indeed, the software is not ready until the absolute end of the This processproject. takes into account the reality that we almost never get anything completely right the firstincremental time. At first,delivery, we will get a lot of feedback. Gradually, with each iteration, What if we need the results faster? We could use iterative development with a variation on the previous process. the output from each phase stabilizes and we need to do less rework. The basic idea is to release the software several times to its users, each time with more functionality. Each release is complete, useable and useful to its users. Each release adds more functionality, preferably the most important functionality first. How do we schedule our project? First, we go through several iterations of analysis and design, until we are pretty sure these phases are mostly complete. We can then select the content and schedule of the increments to be developed. Let's say we have identified three increments A, B and C, to be delivered in this order to the users. n For increment B, we iterate through all required phases, until the software can be released. We expect almost no analysis or design work. n For increment A, we iterate through all required phases, until the software can be released. We expect to rework the analysis and design very little. For increment C, we iterate through all required phases, until the software can be released. We expect almost no analysis or design work. We can picture this process n n as four applications of the above process. The amount of analysis and (architectural) design decreases in each Page 3 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition step. The process delivers functionality after the second, third and fourth steps. How do we select the contents of the increments? Architecture-driven processes would select the elements that have the most impact on the architecture (and thus the design). Risk-driven processes would select the most risky elements. Users would prefer the most useful or urgent functionalities. Agile Software Development — Extremely Incremental Agile software methods like Extreme Programming [3] take another approach, based on the following assumptions: n n n You should deliver software to your users in small increments and deliver functionality in the order that the users want. The development process is then scheduled as follows: can be added at any time. Gather an initial list of requirements. New requirements n n You should welcome feedback and rework, instead of trying to avoid it Decide length of incremental increments are theprioritize same length. Decide which ones will be releases internally for evaluation and Beforeon thethe start of each increment: releases. users (or All their representative) the requirements and assign theinternal requirements to (used releases. As many releases as required feedback) and external toone the being end-users). can be planned, but typically the contents of all releases releases,(released except the implemented, are subject to change. n n n During the increment, the requirements are analyzed and broken down into small micro-increments. These increments are small enough to be fully implemented in a day or less. To implement a micro-increment, the developers analyze, design code, test, integrate and deploy iteratively. They iterate very quickly, so as to get a lot of feedback to guidefor their [1]See <http://www.sei.cmu.edu/cbs/spiral2000/february2000/Royce/> an work. overview of RUP as an example of a "Spiral process." [2]Boehm, Barry. Software Each increment has a fixed length. needed, scope is Prentice reduced/increased Engineering Economics. UpperIfSaddle River, NJ: Hall, 1981.by the user to meet the target date. [3]Beck, Kent. Extreme Programming Explained. Boston: Addison-Wesley, 2000. What's So Extreme in Extreme Programming? What is the difference between Extreme Programming-style planning and iterative development with incremental delivery, such as is possible with the well-known and accepted Unified Process framework? Incremental Architecture and Design One difference is the assumption that you can do architecture and design incrementally. Indeed, XP spends very little time up front to define an architecture and overall design. Instead, we immediately start with the first increment to deliver functionality. All architecture and design work is done to satisfy the requirements of the n A System Metaphor describes an overall architecture and vocabulary that all participants understand and agree with. The Metaphor is refined iteratively over the current increment. XP does design in the following ways: whole project. n Test-First programming designs the code incrementally by defining executable tests with which the program unit must comply. n Refactoring reworks the design to iteratively adapt the design to changing knowledge, environment, or requirements. n Whiteboard design sessions, CRC card sessions, and other group design techniques. Incremental Analysis An even more controversial assumption is that you can do analysis incrementally. At the start of each increment, we only examine the requirements that have been this increment. XP does analysis in the following ways: n Brief requirements, called Stories, arescheduled elaboratedfor interactively between the development team and the story author just before and during implementation. n Requirements are formalized into executable "Acceptance" tests, which specify and verify the compliance of the software with the requirement. n Requirements are allocated to releases using the Planning Game, where developers and customers optimize delivered value versus Page 4 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition development cost. Incremental Development in a Customer-Selected Order A final difference is the assumption that you can deliver software features incrementally, in whatever order yields most benefit for the customer. If the software can be delivered incrementally, the users will get the benefit of the functionality sooner and thus get a faster return on their investment. As the customers can choose the delivery order, they receive the most important and valuable features first. The use of these increments generates lots of valuable feedback to drive the following increments. What's the Best Way to Plan a Project? The short answer is that it depends. It depends on your project, your team, and your environment. If the assumptions of XP hold, we can gain a lot of benefits from working incrementally: n Early delivery of useful software. n Delivery of functionality based on the value users give to that functionality (business value-driven instead of architecture-or risk-driven). n Clear, tangible feedback on progress: each increment delivers finished, production-quality functionality. n Clear and regular feedback on the quality and fit of the software from the users to the development team. n n n The ability to adapt the project plan. Clear scheduling and predictable delivery. n By only looking of at the small piecespossible (increments) of the have to dowithout massive which might have been avoided if we analyzed designedofthe The development simplest system thatsoftware, satisfies we the may requirements, anyrework, unnecessary adornments and complexity. What are theordangers this whole system correctly. approach? n We might "paint ourselves into a corner;" that is, we can get a system that is incapable of supporting some new requirement. n We may be unable to add global requirements, such as alternate language support, performance, and security. A typical example is trying to retrofit "security" to an application that was not designed with this requirement in mind. A Few Heuristics We might go slower because we have to restart analysis and design sessions for each increment, instead of doing it once at the start of the project. If your requirements are volatile or incomplete, if the environment changes, or if you wish to be able to anticipate to future events, work incrementally. If the requirements and environment are stable, you can optimize your process by looking at all the requirements upfront. n If you are not familiar with the domain, or have not built a similar architecture, work incrementally. Use the feedback to design your system and to avoid unnecessary complexity. If you have created many similar systems, you can do more design work up front. Still, you can always use the feedback to keep your system simple. If you cannot deliver incrementally, then don't deliver incrementally. But, even if you cannot deliver incrementally to your final user, you might deliver incrementally to internal users, such as the quality assurance team, or product managers. Even if you cannot do that, deliver incrementally within your team. That way you still get the benefit of early feedback. If you know a requirement is going to be more difficult to work on if you only tackle it later, work on it now. This might happen with global properties of software systems like localization, scalability, and security. You can still get the benefit of business value-driven scheduling for most requirements if you take those few exceptions into account: "Did you want security with that, Sir? With security, this feature will cost you X. Without security, it will cost you Y. If you wish to add security later, it will cost you Z." Iterative Conclusion (re) design techniques like refactoring and the emphasis on simplicity does help to keep your software "soft"—more malleable—more accepting of changes. Incremental software withwork shortupfront increments, project andyou functional risk and allows us toondeliver value on faster users. release provides If your team development, is big, do enough with areduces small team so that can decompose the work the system the to basis of aEach reasonable opportunities for useful external (customer/user) feedback and replanning, so thatorwe arearchitecture. more likely to deliver what the customer needs. Within those increments, one (but not perfect final) iterates based on internal feedback (tests, reviews), to reduce technical risk, so that we are more likely to deliver the quality the customer needs. The project is at its most agile when we use fast iteration and short increments, as the regular feedback allows us to make continuous small course corrections to our project. Page 5 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Page 6 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Agile Project Management for Dummies by Mark C. Layton John Wiley & Sons (US). (c) 2012. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Agile Project Management for Dummies Chapter 7: Defining the Product Vision and Product Roadmap In This Chapter n Planning agile projects n Establishing the product vision To start, let's dispel a common myth. If you've heard that agile projects don't include planning, dismiss that thought right now. Not only will you plan the overall project, you n Creating features and aalso product roadmap will plan every release, every sprint, and every day. Planning is fundamental to agile project success. If you're a project manager, you probably do the bulk of your planning at the beginning of a project. You may have heard the phrase, "Plan the work, then work the plan," which sums up non-agile project management approaches. Agile projects, in contrast, involve planning up front and throughout the entire project. By planning at the last responsible moment, right before an activity starts, you know the most about that activity. This type of planning, called just-in-time planning or a situationally informed strategy (introduced in Chapter 3), is a key to agile's success. TECHNICAL STUFF Helmuth von Moltke, a nineteenth-century German field marshal and military strategist, once said, "No plan survives contact with the enemy." That is, in the heat of a battle — much like in the thick of a project — plans always change. The agile focus on just-in- time planning allows you to accommodate real situations and to be well informed as you plan specific tasks. Planning in Agile This chapter describes how just-in-time planning works with agile. You also go through the first two steps of planning an agile project: the product vision and the product Planning happens at a number of points in an agile project. A great way to look atroadmap. the planning activities in agile projects is with the Roadmap to Value. Figure 7-1 shows the roadmap as a whole. n Figure 7-1: Planning in agile with the Roadmap to Value The Roadmap to Value has seven stages: In Stage 1, the product owner identifies the product vision. The product vision is your project's destination; it's a definition of what your product is, how it will support your company or organization's strategy, who will use the product, and why people will use the product. On longer projects, revisit the product vision about once a year. n In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a Page 2 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies n n n n n loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. Revise the product roadmap biannually with support from the development team. In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. The release serves as a mid-term goal that the scrum team can mobilize around. An agile project will have many releases, with the highest-priority features appearing first. You create a release plan at the beginning of each release. Find out more about release planning in Chapter 8. In Stage 4, the product owner, the scrum master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, with requirements that support the goal and can be completed in the sprint, and outlines how to complete those requirements. Get more information about sprint planning in Chapter 8. In Stage 5, during each sprint, the development team has daily scrum meetings to coordinate the day's priorities. In the daily scrum meeting, you discuss what you completed yesterday, what you will work on today, and any roadblocks you have, so that you can address issues immediately. Read about daily scrums in Chapter 9. In Stage 6, the scrum team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product to the product stakeholders. Find out how to conduct sprint reviews in Chapter 10. In Stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint. Find out how to conduct sprint retrospectives in Chapter 10. Each stage in the Roadmap to Value is repeatable, and each stage contains planning activities. Planning in agile, like development in agile, is iterative. REMEMBER The various teams on agile projects — the development team, the scrum team, and the project team — have different roles and responsibilities, as you see throughout this chapter and the rest of the book. Figure 7-2 shows how these teams fit together. Figure 7-2: Teams in agile Planning as Necessary During each stage in an agile project, you plan only as much as you need to plan. In the early stages of your project, you plan widely and holistically to create a broad outline of how the product will shape up over time. In later stages, you narrow your planning and add more details to ensure success in the immediate development effort. Planning broadly at first and in detail later, when necessary, prevents you from wasting time on planning lower-priority product requirements that may never be implemented. This model also lets you add high-value requirements during the project without disrupting the development flow. The more just-in-time your detailed planning is, the more efficient your planning process becomes. REMEMBER Some studies show customers rarely or never use 64 percent of the features in an application. In the first few development cycles of an agile project, you complete features that are high priority and that people will use. Typically, you release those groups of features Page 3 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies as early as possible. Inspect and Adapt Just-in-time planning brings into play a fundamental tenet of agile techniques: inspect and adapt. At each stage of a project, you need to look at the product and the process (inspect)cycle and make changesand as adapting. necessaryConsider (adapt). the following: Planning in agile is a rhythmic of inspecting n During the sprint, the product owner provides feedback to help improve the product as the development team creates the product. n n n At the end of each sprint, in the sprint review, stakeholders provide feedback to further improve the product. Also at the end of each sprint, in the sprint retrospective, the scrum team discusses the lessons they learned during the past sprint to improve the development process. After a release, the customers using the product can provide feedback for improvement. Feedback might be direct, when a customer contacts the company about the product, or indirect, when potential customers either do or don't purchase the product. Inspect and adapt is a fantastic tool for delivering the right product in the most efficient manner. REMEMBER At the beginning of a project, you know the least about the product creating, so trying to plan fine details at that time just doesn't work. With agile, you Defining theyou're Product Vision do the detailed planning when you need it, and immediately develop the specific requirements you defined with that planning. The first stage in an agile project is defining your product vision. The product vision statement is an elevator pitch, or a quick summary, to communicate how your Now that you know aor little more about strategies. how planning agile, it's must time to complete the first for step in product. an agile project: defining the product vision. product supports the company's organization's Theworks visioninstatement articulate the goals the The product might be a commercial product for release to the marketplace or an internal solution that will support your organization's day-to- day functions. For example, say your company is XYZ Bank and your product is a mobile banking application. What company strategies does a mobile banking application support? How does the application support the company's strategies? Your vision statement clearly and concisely links the product to your business strategy. Figure 7-3 shows how the vision statement — Stage 1 on the Roadmap to Value — fits with the rest of the stages and activities in an agile project. Figure 7-3: The product vision statement as part of the Roadmap to Value The product owner is responsible for knowing about the product, its goals, and its requirements throughout the project. For those reasons, the product owner creates the vision statement, although other people may have input. After the vision statement is complete, it becomes a guiding light, the "what we are trying to achieve" statement that the development team, scrum master, and stakeholders refer to throughout the project. When creating a product vision statement, follow these four steps: 1. Develop the product objective. 2. Create a draft vision statement. 3. Validate the vision statement with product and project stakeholders. Revise the vision statement based on feedback. 4. Finalize the vision statement. The look of a vision statement follows no hard-and-fast rules. However, anyone involved with the project, from the development team to the CEO, should be able to understand the statement. The vision statement should be internally focused, clear, nontechnical, and as brief as possible. The vision statement should also be explicit and avoid marketing fluff. Step 1: Developing the Product Objective Page 4 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies To write your vision statement, you must understand and be able to communicate the product's objective. You need to identify the following: n Key product goals: How will the product benefit the company that is creating it? The goals may include benefits for a specific department within your company, such as customer service or the marketing department, as well as the company as a whole. What specific company strategies does the product support? n n Customer: will use the features product?are This question might have more than one answer. n Need: Why does the customer need theWho product? What critical to the customer? Competition: How does the product compare with similar products? n Primary differentiation: What makes this product different from the status quo or the competition or both? Step 2: Creating a Draft Vision Statement After you have a good grasp of the product's objective, create a first draft of your vision statement. You can find many templates for a product vision statement. For an excellent guide to defining the overall product vision, see Crossing the Chasm, by Geoffrey Moore (published HarperCollins), which focuses on how to bridge the gap ("chasm") between early adopters of new technologies and the majority who follow. Will the market take to the product? Will there be an adequate return The adoption of any new product is a gamble. Will users like the product? on investment for developing the product? In Crossing the Chasm, Moore describes how early adopters are driven by vision, whereas the majority are skeptical of visionaries and interested in down-to-earth issues of quality, product maintenance, and longevity. TECHNICAL STUFF Return on investment, or ROI, is the benefit a company gets from paying for something. ROI can be quantitative, such as the additional money ABC Products makes from selling widgets online after investing in a new website. ROI can also be something intangible, such as better customer satisfaction for XYZ Bank customers who use the bank's new mobile banking application. By creating your vision statement, you help convey your product's quality, maintenance needs, and longevity. Moore's product vision template is pragmatic. In Figure 7-4, I expand the template to more explicitly connect the product to the company's strategies. If you use this template for your product vision statement, it will stand the test of time as your product goes from early adoption to mainstream usage. Figure 7-4: Expansion of Moore's template for a vision statement TIP One way to make your product vision statement more compelling is to write it in the present tense, as if the product already exists. Using present tense helps readers imagine the product in use. Using my expansion of Moore's template, a vision statement for a mobile banking application might look like the following: For XYZ Bank customers who want access to online banking capability while on the go, the MyXYZ mobile banking application by XYZ Bank is a mobile application that can be downloaded and used on smartphones and tablets Page 5 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies that allows bank customers to conduct secure, on-demand banking, 24 hours a day. Unlike traditional banking at a branch or online banking from your home or office computer, our product allows users immediate 24-hour access to their financial accounts wherever they have mobile carrier service. Platinum Edge addition: This supports our company strategy to provide quick, convenient banking services, anytime, anywhere. As you can see, a vision statement identifies a future state for the product when the product reaches completion. The vision focuses on the conditions that should exist when the product is complete. WARNING! Avoid generalizations in your vision statement such as "make customers happy" or "sell more products." Also watch out for too much technological specificity, such as "using release 9.x of Java, create a program with four modules that…." At this early stage, defining specific technologies might limit you later. Here are a few extracts from vision statements that should ring warning bells: n n n Secure additional customers for the MyXYZ application. Satisfy our customers by December. Eliminate all defects and improve quality. n Create a new application in Java. n Beat the Widget Company to market by six months. Step 3: Validating and Revising the Vision Statement After you draft your vision statement, review it against the following quality checklist: n Does the statement a compelling description how the product meets customer needs? Isn this vision statementprovide clear, focused, and written for anof internal audience? n n n Does the vision describe the best possible outcome? Is the business objective specific enough that the goal is achievable? Does the statement deliver value that is consistent with corporate strategies and goals? n Is the project vision statement compelling? These yes-or-no questions will help you determine whether your vision statement is thorough. If any answers are no, revise the vision statement. n n When all answers are yes, move on to reviewing the statement with others, including the following: Project stakeholders: The stakeholders will be able to identify that the vision statement includes everything the product should accomplish. Your development the team willproduct create the must understand whatroadblocks the product needs to accomplish. n Scrum master: Ateam: strongBecause understanding of the willproduct, help the itscrum master remove and ensure that the development team is on the right path later in the project. n Agile mentor: Share the vision statement with your agile mentor, if you have one. The agile mentor is independent of the organization and can provide an external See whether others think the vision statement is clear andperspective, delivers thequalities messagethat youcan want to convey. Review and revise make for a great objective voice.the vision statement until the project stakeholders, the development team, and the scrum master fully understand the statement. REMEMBER At this stage of your project, you might not have a development team or scrum master. After you form a scrum team, be sure to review the vision statement with it. Step 4: Finalizing the Vision Statement After you finish revising the vision statement, make sure your development team, scrum master, and stakeholders have the final copy. You might even put a copy on the wall in the scrum team's work area, where you can see it every day. You will refer to the vision statement throughout the life of the project. If your project is more than a year long, you may want to revisit the vision statement. I like to review and revise the product vision statement once a year to make sure the product reflects the marketplace and supports any changes in the company's needs. Page 6 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies REMEMBER The product owner owns the product vision statement and is responsible for its preparation and communication across and outside the organization. The product vision sets expectations for stakeholders and helps the development team stay focused on the goal. Congratulations. You have just completed the first stage your agile project. Now it's time to create a product roadmap. Creating a in Product Roadmap The product roadmap, Stage 2 in the Roadmap to Value (see Figure 7-5), is an overall view of the product's requirements and a valuable tool for planning and organizing the journey of product development. Use the product roadmap to categorize requirements, to prioritize them, and to determine a timetable for their release. Figure 7-5: The product roadmap as part of the Roadmap to Value As he or she does with the product vision statement, the product owner creates the product roadmap, with help from the development team. The development team participates to a greater degree than it did during the creation of the vision statement. TIP Keep in mind that you will refine requirements and effort estimates throughout the project. In the product roadmap phase, it is okay for your requirements, estimates, and timeframes to be at a very high level. 1. 2. 3. 4. Identify product requirements and add them toTo the roadmap. create your product roadmap, you Arrange the product requirements into logical groups. Estimate requirement effort at a high level and prioritize the product's requirements. Envision high-level time frames for the groups on the roadmap. Because priorities can change, expect to update your product roadmap throughout the project. I like to update the product roadmap at least twice a year. TIP Your product roadmap can be as simple as sticky notes arranged on a white board — which makes updates as easy as moving a sticky note from one section of the white board to another. You use the product roadmap to plan releases — Stage 3 in the Roadmap to Value. Releases are groups of usable product functionality that you release to customers to gather real-world feedback and to generate return on investment. The following section goes through the steps to create a product roadmap in detail. Step 1: Identifying Product Requirements The first step in creating a product roadmap is to identify, or define, the different requirements for your product. Decomposing requirements Throughout the project, you will break those requirements down into smaller, more manageable parts using a process called decomposition. You can break requirements down into the following sizes, listed from largest to smallest: n Themes: A theme is a logical group of features and is also a requirement at its highest level. You may group features into themes in Themes: A theme is a logical group of features and is also a requirement at its highest level. You may group features your product roadmap. n n n Epic user stories: Epics are very large requirements that support a feature and contain multiple actions. You need to epics before you can start will see how creating a product requirement from them. You can find out how you will use epics for release p Chapter 8. n Tasks: Tasks are the execution steps required to develop a requirement. You break down user stories into different tasks during sprint User stories: User stories are requirements that contain a single action and are small enough to start implementing. You you define user stories and use them at the release and sprint level in Chapter 8. Page 7 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions n once the Features: Features are parts of products at a very high level. Features describe a new capability the customers will have feature is complete. You n Epic user stories: Epics are very large requirements that support a feature and contain multiple actions. You need to break down your will use features in your product roadmap. lanning in n Wiley & Sons (US),planning. John WileyYou & Sons, (c)out 2012, Copying Prohibited Tasks: Tasks are the execution steps required to develop a requirement. You break down user John stories into different canInc. find about tasks and sprint planning in Chapter 8. Agile Project Management for Dummies at the user Keep in mind that each requirement may not go through all these sizes. For example, you may create a particular requirement story level, and never think y be a lowerof it on the theme or epic scale. You may create a requirement at theyou epicmay usernot story but ittoma priority requirement. Because of user just-in-time planning, priority requirement. Because of just-in-time planning, takelevel, the time decompose that lower priority epic story until you you may not take the time to decompose that lower priority epic user complete development of all the higher-priority requirements. When you first create your product roadmap, you likely will start with large, high-level requirements. The requirements on your product roadmap will most likely be at two different levels: themes and features. Themes are logical groups of features and requirements at their highest levels. Features are parts of the product at a very high level. Features describe a new capability will have once the help feature is complete. To identify product themes and features, the product owner can work with stakeholders andthe thecustomer development teams. It may to have a requirements session, where the stakeholders and the development team meet and write down as many requirements as they can think of. TIP When you start creating requirements at the theme and feature level, it can help to write those requirements on index cards or big sticky notes. Using a physical card that you can move from one category to another and back again can make organizing and prioritizing those requirements very easy. While you are creating the product roadmap, the features you identify start to make up your product backlog — the full list of what is in scope for a product, regardless of level of detail. Once you have your first requirement, you have your product backlog started. Step 2: Arranging Product Features After you identify your product requirements features, you work with the development team to group the requirements into themes — common, logical groups of requirements. A stakeholder meeting works well for grouping requirements, just like it works for creating requirements. You can group features by usage flow, technical Here are questions to consider when grouping your requirements:similarity, or business need. n n How would customers use our product? If we offered this requirement, what else would customers need to do? What else might they want to do? n Can the development team identify technical affinities or dependencies? Use the answers to these questions to identify your themes. Then group the features by these themes. For example, in the mobile banking application, the themes might be n Account information n n Transactions Customer service functions n Mobile functions Figure 7-6 shows features grouped by themes. Page 8 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Figure 7-6: Features grouped by themes If you are using sticky notes, you can group your features on a white board, like the example in Figure 7-7. Figure 7-7: Requirement categories on a white board Step 3: Estimating and Ordering the Product's Features You have identified your product requirements and arranged those requirements into logical groups. Next, you estimate and order the requirements. Here are a few terms you need to be familiar with: n Effort is the ease or difficulty of creating a particular requirement. n An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement. Page 9 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies n n Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create. Ordering, or prioritizing, a requirement means to determine that requirement's value in relation to other requirements. n Value means just how beneficial a particular product requirement might be to the organization creating that product. TIP You can use the estimating and prioritizing techniques in this section for requirements at any level, from themes and features down to single user stories. Scoring Requirement Value and Effort To order requirements, you must first estimate a score to represent the value and effort for each requirement. To order your requirements, you also want to know any dependencies. Dependencies mean that one requirement is a predecessor for another requirement. For example, if you were to have an application that needs someone to log in with a username and password, the requirement for creating the username would be a dependency for the requirement for creating the password, because you generally need a username to set up a password. Estimating, or scoring, requirements on value and effort is a key first step to ordering those requirements. You work with two different groups to score your requirements: n The product owner, with support from the stakeholders, determines the value of the requirement to the customer and the business. n The development team determines the effort to create the requirement for each requirement. Scrum teams often use the Fibonacci sizing sequence for creating requirement scores. The Fibonacci sequence goes in a progression like this: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on Each number after the first two is the sum of the prior two numbers. REMEMBER The concept of breaking down requirements into smaller pieces is called decomposition. STUFF The Fibonacci named Leonardo Fibonacci, an Italian mathematician theas sequence in Use your scoresTECHNICAL relatively. Choose a requirement that sequence the projectisteam canafter agree has a small value and effort, score it, and usewho thatdescribed requirement a benchmark. To score hisorbook backbenchmark in 1202! requirement, and whether they are easier or harder than your other requirements, decide whether other requirements have more less Liber value Abaci than your benchmark requirement. When you are creating your product roadmap, your requirements will be on the feature scale. Most of them will have effort scores from 55 to You mightwhen use two requirements, one features for valuedown and one for effort. In the end, relative the13absolute score, matters. Next up is ainformula 144. Later, you benchmark plan releases, you break your to epic user stories with the scores of noscore, largernot than to 34. And after you start planning sprints,for your calculating relative priority. user stories should have effort scores of 1 to 8. After you have your value and effort scores for your requirements, you can calculate the relative priority of each requirement. Relative priority helps you understand how one requirement relates to another in terms of value. Once you know the relative priority of your requirements, you can order them on your product roadmap. Calculating Relative Priority Calculate relative priority with the following formula: Relative priority = value/effort For example, if you have a requirement with a value of 89 and an effort of 55, the relative priority would be 1.62 (89/55 = 1.62), which you could round to 2. Using this formula n n A requirement with high value and low effort will have a high relative priority. For example, if the value is 144 and the effort is 3, the relative priority is 48. A requirement with a low value and high effort will have a lower relative priority. For example, if the value is 2 and the effort is 89, the relative priority is 0.0224. n This formula usually produces fractional results. If you want, you can round those to the nearest whole number. WARNING! Relative priority is only a tool to help the product owner make decisions and prioritize requirements. It isn't a mathematical universal that you must follow. Make sure your tools help, rather than hinder. Note the relative priority for each requirement. From here, you can review your requirements simultaneously and prioritize them. Reprinted for CTS/316124, Cognizant Technology Solutions Page 10 / 11 John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Prioritizing Requirements Agile Project Management for Dummies To determine the overall priority for your requirements, answer the following questions: n n n What is the relative priority of the requirement? What are the prerequisites for any requirement? What set of requirements belong together and will constitute a solid release? Using the answers to these questions, you will be able to place the highest-priority requirements first in the product roadmap. When you have finished prioritizing your requirements, you will have something that looks like Figure 7-8. Figure 7-8: Product roadmap with prioritized requirements Your prioritized list of user stories is called a product backlog. Your product backlog is an important agile document, or in agile terms, an artifact. You will use this backlog throughout your entire project. With a product backlog in hand, you can start adding target releases to your product roadmap. Step 4: Determining High-Level Time Frames When you first create your product roadmap, your time frames for releasing product requirements will be at a very high level. For the initial roadmap, choose a logical time increment for your project, such as a certain number of days, weeks, months, quarters (three-month periods), or even larger increments. Using both the requirement the priority, you can add requirements to each increment of time. REMEMBER Creating a product roadmap might seem like a lot of work, but after you get the hang of it, you can create one in a short time. Some scrum teams can create a Saving Work product vision, product roadmap, and release plan, and be ready to start their sprintYour in as little as one day! To begin coding the product, you need only enough requirements for your first sprint. You can determine the rest as the project progresses. Up until now, you could do all your roadmap planning with white boards and sticky notes. After your first full draft is complete, however, save the product roadmap, especially if you need to share the roadmap with remote stakeholders or development team members. You could take a photo of your sticky notes and white board, or you could type the information into a document and save it electronically. You will update the product roadmap throughout the project, as priorities change. For now, the contents of the first release should be clear — and that's all you need to worry about at this stage. Page 11 / 11 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies by Mark C. Layton John Wiley & Sons (US). (c) 2012. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Agile Project Management for Dummies Chapter 8: Planning Releases and Sprints In This Chapter n Decomposing requirements and creating user stories n Planning agilea sprints n Creating product backlog, release plan, and sprint backlog After you create a product roadmap for your agile project (see Chapter 7), it's time to start elaborating on your product details. In this chapter, you discover how to break down your requirements to a more granular level, refine your product backlog, create a release plan, and build a sprint backlog. First, you will see how to break down the larger requirements from your product roadmap into smaller, more manageable requirements called user stories. REMEMBER The concept of breaking down requirements into smaller pieces is called decomposition. Refining Requirements and Estimates You start agile projects with very large requirements. As the project progresses and you get closer to developing those requirements, you will break them down into smaller parts. One clear, effective format for defining product requirements is the user story. The user story and its larger cousin, the epic user story, are good-sized requirements for release planning and sprint planning. In this section, you find out What how to is create a user story, how to prioritize user stories, and how to estimate user story effort. a User Story? The user story is a simple description of a product requirement in terms of what that requirement must accomplish for whom. Your user story will have, at a minimum, the following parts: n Title: <a name for the user story> As a <user or persona> I want to <take this action> n so that <I get this benefit> It will also include the following validation steps; steps to take to know that the working requirement for the user story is correct: n When I <take this action>, this happens <description of action> User stories may also include the following: n n n A user story ID: A number to differentiate this user story from other user stories. n The user story value and effort estimate: Value is how beneficial a user story might be to the organization creating that product. Effort is the ease or difficulty in creating that user story. You find out how to score user story value and effort later in this chapter. The name of so thetryperson who cards thought of thenotes userfor story: Anyone on the project team can create Agile techniques encouragen low-tech tools, using index or sticky your user stories. Even if you eventually wantatouser usestory. an electronic tool, it is a good idea to become familiar with the process of creating user stories first. Once you know how to create user stories, then consider taking on the overhead of complex electronic tools. TIP Agile project management approaches encourage low-tech tools, but agile approaches also encourage scrum teams to find out what works best for each team in each situation. There are a lot of electronic user story tools out there. Some cost money; some are free. Some are simple, and are just for user stories. Others are complex and will integrate with your other product documents. Personally, I love index cards, but that solution may not be for everyone. Use what works best for your scrum team and for your project. Figure 8-1 shows a typical user story card, back and front. The front has the main description of the user story. The back shows how you will confirm that the requirement works correctly, after the development team has created the requirement. Page 2 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Figure 8-1: Card-based user story example The product owner gathers and manages the user stories. However, the development team and other stakeholders also will be involved in creating and decomposing user stories. TIP It's important to note that user stories aren't the only way to describe product requirements. You could simply make a list of requirements without any given structure. However, because user stories include a lot of useful information in a simple, compact format, I find them to be very effective at conveying exactly what a requirement needs to do. The big benefit of the user story format is when the development team starts to create and test requirements. The development team members know exactly whom they are creating the requirement for, what the requirement should do, and how to double-check that the requirement satisfies the intention of the requirement. to examples Create aofUser Story throughout this chapter and throughout the book. Keep in mind that anything I describe that you can do with user stories, you I use user Steps stories as requirements can do with more generically expressed requirements. creating a user story, stakeholders. follow these steps: 1.When Identify the project 2. 3. Identify who will use the product. Working with the stakeholders, write down the requirements that the product will need and use the format I describe earlier in this chapter to create your user stories. Find out how to follow these three steps in the following sections. REMEMBER Agile is iterative. Don't spend a ton of time trying to identify every single requirement your product might have. You can always add requirements later in the project. The best changes often come at the end of a project, when you know the most about the product and the customers. Identifying Project Stakeholders You probably have a good idea about who your project stakeholders are — anyone involved with, or affected by, the product and its creation. REMEMBER You will also work with stakeholders when you create your product vision and your product roadmap. Make sure the stakeholders are available to help you create requirements. Stakeholders might include n n People who interact with customers on a regular basis, such as customer service representatives or bank branch personnel. Business experts for the different areas where your product's customers interact. For example, XYZ Bank, the sample company I tell you about in Chapter 7, might have one manager in charge of checking accounts, another manager in charge of savings accounts, and a third manager in charge of online bill payment services. If you're creating a mobile banking application, all these people would be project stakeholders. n Users of your product, if they are available. n Experts on the type of product you are creating. For example, a developer who has created mobile applications, a marketing manager who knows how to create mobileTechnical campaigns, and a user people experience specializes mobile interfaces all with mightyour be helpful stakeholders, who specialist work with who the systems thatinmight need to interact product.on the sample XYZ Bank mobile banking project. Identifying Customers When thinking about the customers who will use your product, it's often helpful to assign them personas, such as a salesperson or a customer service representative. n TECHNICAL STUFF Development teams of all types often create personas, character descriptions of people who are likely to use a Page 3 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies product. Think of a persona as a character in a book or a movie. You can give a persona its own background: a name, age, gender, job, likes, dislikes, and needs. Using personas can help you understand exactly what your product may need to do. You can also think of personas in terms of specific representatives of those roles, such as someone in a particular demographic or a type of user. An example is a 30REMEMBER Keep the customer you described in your productdirector vision statement in mind when creating personas. You can find out more something female marketing who travels a lot on business. about the vision statement in Chapter 7. Suppose that you are the product owner for the XYZ Bank's mobile banking project described previously. You are responsible for the department that will bring the product to market, preferably in the next six months. You have the following ideas about the application's users: n n n Maybe customers are probably about to buy large-ticket and they want to make suretheir theybalances can charge it.recent transactions. The customers (the end users the of the application) wanta quick accessitem, to up-to-date information about and Maybe the customers' ATM cards were just refused, but they have no idea why, and they want to check recent transactions for possible fraudulent activities. n Maybe the customers just realized that they forgot to pay their credit card bill and will have penalty charges if they don't pay the card today. Who are your personas for this application? Here are a few examples: n n Persona #1:nJason is a young, tech-savvy executive who travels lot. When he has when a spare moment, he wants to their handle personal quickly. He carefully Persona #2: Carol is a small-business owner whoastages properties clients are trying to sell home. She business shops at consignment centers and sees aportfolios. couch sheHe wants to buy for a client. invests his money in high-interest keeps his available cash low. Persona #3: Nick is a student who lives on student loans and a part-time job. He knows he can be flaky with money because he's flaky with everything else. He just lost his checkbook. Determining Product Requirements and Creating TIP Your product stakeholders can help you create personas.User Find Stories people who are experts on the day-to-day business for your product. Those stakeholders will know After you have identified your different customers, ayou start to potential determine product requirements and create user stories for the personas. A lot can about your customers. good way to create user stories is to bring your stakeholders together for a user story creation session. Have the stakeholders write down as many requirements as they can think of, using the user story format. One user story for the project and personas from the preceding sections might be n Front side of card: As a busy, tech-savvy, on-the-go customer of XYZ Bank (Jason) ¡ I want to see my checking account balance on my smartphone ¡ Title: See bank account balance. ¡ so that I can see how much money I have in my checking account n Back side of card: ¡ ¡ When I sign into the XYZ Bank mobile application, my checking account balance appears at the top of the page. ¡ When I sign into the XYZ Bank mobile application after making a purchase or a deposit, my checking account balance reflects that purchase or deposit. You can see sample user stories in card format in Figure 8-2. Page 4 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Figure 8-2: Sample user stories REMEMBER Be sure to continuously add new user stories to your product backlog. Keeping your product backlog up-to-date will help you have the highest priority user stories when it is time to plan your sprint. Throughout an agile project, you will create new user stories. You will also take existing large requirements and decompose them until they are manageable enough to work on during a sprint. Breaking down Requirements n You will refine requirements many times throughout an agile project. For example: When you create the product roadmap (see Chapter 7), you create features, a capability your customers will have after you develop the feature that they don't have prior, as well as themes, which are logical groups of features. Although features are intentionally large, at Platinum Edge, we require features at the product roadmap level to be no larger than 144 story points. When you plan releases, you break down the features into more concise user stories. User stories at the release plan level can be either epics, very large user stories with multiple actions, or individual user stories that will contain a single action. For our clients, user stories at the release plan level should be no larger than 34 story points. You find out more about releases later in this chapter. n When you plan sprints, you can break down user stories even further. You also identify individual tasks associated with each user story in the sprint. For our clients, user stories at the sprint level should be no larger than eight story points. To decompose requirements, you will want to think about how to break the requirement down into individual actions. Table 8-1 shows a requirement decomposed from the theme leveleffort down the user story level. REMEMBER A story point is a relative score to represent value and fortoeach requirement. Scrum teams often use numbers in the Fibonacci sequence — where each number after the first two is the sum of the prior two numbers — for their story points. You can find out more about story points and the Fibonacci sequence in Table 8-1: Decomposing a Requirement Requirement Level Chapter 7. Requirement n Theme Features See account data with a mobile application. See account balances. See a list of recent withdrawals or purchases. See a list of recent deposits. Epic User Stories — decomposed from "see account balances" User Stories — decomposed from "see checking account balance" See my upcoming automatic bill payments. See checking account balance. See savings See investment my accountaccount alerts. account balance. See balance. See retirement account balance. Log into mobile account. Securely log into mobile account. Page 5 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies See a list of my accounts. Select and view my checking account. See account balance changes after withdrawals. See account balance changes after purchases. See day's end account balance. See available account balance. Estimation Poker See mobile application navigation items. Change account view. Logtime out of As you refine your requirements, you need to refine your estimates as well. It's tomobile have application. some fun! One of the most popular ways of estimating user stories is by playing estimation poker, sometimes called Planning Poker, a game to determine user story size and to build consensus with the development team members. REMEMBER The scrum master can help coordinate estimation, and the product owner can provide information about features, but the development team is responsible for estimating the level of effort required for the user stories. After all, the development team has to do the work to create the features that those stories User stories and the INVEST approach describe. You may just be asking, just how decomposed user story to be? in Billhis Wake, in XP123.com his blog at XP123.com describes thetoINVEST You may be asking, how decomposed does a userdoes storya have to be?have Bill Wake, blog at describes the approach ensure quality in user stories. I like his method so much I include it here. n Independent: To the extent possible, a the story should approach, need no other implement Using INVEST userstories storiestoshould be the feature that the story describes. n Independent: To the extent possible, a story should need no other stories to implement the feature that the story task. The story is in the user's language and is easy to explain. The people using the product or system can understand the story. n Negotiable: Not overly detailed. There is room for discussion and expansion of details. n Valuable: The story demonstrates product value to the customer. The story describes features, not a single-thread start-to task. The story is in the n Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not take one user's language and is easy to explain. The people using the product or system can understand -finish user n Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary functionality in the user to create the To play estimation poker, you need a deck of cards like the one in Figure 8-3. story. You can get them online at my website (www.platinumedge.com/estimationpoker), or you can make your own with index cards and markers. The numbers on the cards are from the Fibonacci sequence. n Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not person on the development team longer than half of a sprint to complete. n Testable: You can easily validate the user story, and the results are definitive. Figure 8-3: A deck of estimation poker cards Only the development team plays estimation poker. The scrum master and product owner don't get a deck and don't provide estimates. However, the scrum master can act as a facilitator, and the product owner will read the user stories and provide details on user stories as needed. Page 6 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies To play estimation poker, follow these steps: 1. Provide each member of the development team with a deck of estimation poker cards. 2. Starting with a simple user story, the players decide on an estimate — as a story point — that they can all agree on for that user story. This user story becomes the baseline story. 3. The product owner reads a high-priority user story to the players. 4. Each player selects a card representing his or her estimate of the effort involved in the user story and lays the card facedown on the table. The players should compare the user story to other user stories they have estimated. (The first time through, the players compare the user story only to the baseline story.) Make sure no other players can see your card. 5. Once each development team member selects a card, all players turn over their cards simultaneously. 6. If the players have different story points: a. It's time for discussion. The players with the highest and lowest scores talk about their assumptions and why they think the estimate for the user story should be higher or lower, respectively. The players compare the effort for the user story against the baseline story. The product owner provides more information about the story, as necessary. b. Once everyone agrees on assumptions and has any necessary clarifications, the players reevaluate their estimates and place their new selected cards c. on the table. d. If the story points are different, the players repeat the process, usually up to three times. 7. The players repeat Steps 3 through 6 for each user story. If the players can't agreeeach on the estimated effort, the scrum— master helps the development a score that you all the players can support or REMEMBER Consider part of the definition of done developed, integrated, tested,team and determine documented — when create estimates. thatplay the user story requires more development detail or needs to as be you further broken down. You can play estimation poker at any point —determine but definitely during product roadmap and progressively break down user stories for inclusion in releases and sprints. With practice, the development team gets into a planning rhythm and becomes more adept at quickly estimating. TIP On the average, development teams will spend about ten percent of their time on a project estimating and re-estimating. Make your estimation poker games fun! Bring in snacks, use humor, and keep the mood light to help speed the task of estimating. Affinity Estimating Estimation poker can be effective, but what if you have many user stories? Playing estimation poker for, say, 500 user stories could take a long time. You need a way to focus only on the user stories you need to discuss to gain consensus. When you have a large number of user stories, many of them are probably similar and would require a similar amount of effort to complete. One way to determine the right stories for discussion is to use affinity estimating. In affinity estimating, you quickly categorize your user stories and then apply estimates to these categories of stories. Affinity can be by a fast and write furious activity the development team may choose to havetypes the scrum help facilitate sessions. stories. To TIP estimating When estimating affinity, your user — stories on index cards or sticky notes. These of usermaster story cards work wellaffinity when estimating quickly categorizing estimate by affinity, follow these steps: 1. Taking no more than one minute for each category, the development team agrees on a single user story in each of the following categories: a. Extra-small user story b. Small user story c. e. d. f. Medium user story Extra-large user story Large user story Epic user story that is too large to come into the sprint Page 7 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies The sizes are like T-shirt sizes and should correspond to Fibonacci scale numbers, as shown in Figure 8-4. You can find out about Fibonacci scale numbers in Chapter 7. 2. 3. 4. 5. Figure 8-4: Story sizes as T-shirt sizes and their Fibonacci numbers Taking no more than 30 seconds per user story, the development team puts all remaining stories into the categories listed in Step 1. If you're using index cards or sticky notes for your user stories, you can physically place those cards into categories on a table or a whiteboard, respectively. If you split the user stories among the development team members, having each development team member categorize a group of stories, this step can go quickly! Taking another 60 minutes, maximum, for each 100 stories, the development team reviews and adjusts the placement of the user stories. The entire development team must agree on the placement of the user stories into size categories. The product owner reviews the categorization. When the product owner's expected estimate and the team's actual estimate differ by more than one story size, they discuss that user story. The development team may or may not decide to adjust the story size. REMEMBER Note that after the product owner and the team discuss clarifications, the team has final say on the user story size. User stories in the same size category will have the same user story score. You can play a round of estimation poker to double-check a few, but you won't need to waste time in unnecessary discussion for every single user story. TIP You can use the estimating and prioritizing techniques in this chapter for requirements at any level, from themes and features down to single user stories. Release Planning A release, in agile terms, is a group of usable product features that you release to production. A release does not need to include all the functionality outlined in the roadmap but should include at least the minimal marketable features, the smallest group of product features that you can effectively deploy and promote in the marketplace. Your early releases will exclude many of the medium- and low-priority requirements you created during the product roadmap stage. When planning a release, you establish the next set of minimal marketable features and identify an imminent product launch date around which the team can mobilize. As when creating the vision statement and the product roadmap, the product owner is responsible for creating the release goal and establishing the release date. However, the development team, with the scrum master's facilitation, contributes to the process. Release planning is Stage 3 in the Roadmap to Value (refer to Figure 7.1 in Chapter 7 to see the roadmap as a whole). Figure 8-5 shows how release planning fits into an agile project. Page 8 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Figure 8-5: Release planning as part of the Roadmap to Value Release planning involves completing two key activities: n Revising the product backlog: In Chapter 7, I told you that the product backlog is a comprehensive list of all the user stories you currently know for your project, whether or not they belong in the current release. Keep in mind that your list of user stories will probably change throughout the project. Release plan: The release goal, release target date, and prioritization of product backlog items that support the release goal. The release plan provides a WARNING! Don't create a new, separate backlog during release planning. The task is unnecessary and reduces the product owner's midrange goal that the team can accomplish. flexibility. Prioritizing the existing product backlog based on the release goal is sufficient and enables the product owner to have the latest information when he or she commits communication to scope duringchannels sprint planning. The product backlog and release plan are some of the most important between the product owner and the team. The following sections describe n how to complete a product backlog and a release plan. Completing the Product Backlog As Chapter 7 explains, the product roadmap contains themes, epic user stories, and some tentative release timelines. The requirements on your product roadmap are the firstproject. versionThe of your product backlog. The product backlog is the list of all user stories associated with the product owner is responsible for creating and maintaining the product backlog by adding and prioritizing user stories. The scrum team uses the backlog during release planning and throughout the project. Figure 8-6 shows a sample product backlog. At a minimum, when creating your product backlog, be sure to n Include a description of your requirement. n n Order the user stories based on priority. You can find out how to determine priority in Chapter 7. Add the effort estimate. Figure 8-6: Product backlog sample REMEMBER In Chapter 2, I explain how documents for agile projects should be barely sufficient, with only information that is absolutely necessary to create the product. Keep your product backlog format simple and barely sufficient, and you will save time on updating it throughout the project. The scrum team refers to the product backlog as the main source for project requirements. If a requirement exists, it is in the product backlog. The user stories in your product backlog will change throughout the project in several ways. For example, as the team completes user stories, you mark those stories as complete within the backlog. You also record any new user stories. Additionally, you update the priority and effort Page 9 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies scores of existing user stories as needed. The total number of story points in the product backlog — all user story points added together — is your current product backlog estimate. This estimate changes daily as user stories are completed and new user stories are added. Discover more about using the product backlog estimate to predict the project length and cost in Chapter 13. REMEMBER Keep your product backlog up to date so that you always have accurate cost and schedule estimates. A current product backlog also gives you the flexibility to prioritize new product features — a key benefit of agile — against existing features. After you have a product backlog, create your first release plan, as described next. Creating the Release Plan The release plan contains a release schedule for a specific set of features. The product owner creates a release plan at the start of each release. To create a release 1. Establish the release goal. plan, follow these steps: The release goal is an overall business goal for the product features in your release. The product owner and development team collaborate to create a release goal based on business priorities, the development team's development speed, and the development team's capabilities. 2. Review the product backlog and the product roadmap to determine the highest-priority user stories that support your release goal. These user stories will make up your first release. I like to have my releases be achieved with about 80 percent of the user stories, using the final 20 percent to add robust features that will meet the release goal while adding to the product's "wow" factor. 3. Determine a date for the release. The release date is typically at least three sprints out, but the actual date depends on your specific project. Some scrum teams determine release dates based on completion of functionality; others may have hard dates, like March 31 or September 1. TIP Some project teams add a release sprint to each release in order to conduct activities that are not related to product development, but still necessary to release the product to customers. If you need a release sprint, be sure to factor that into the date you choose. You can find more about release sprints in Chapter 11. 4. Consult the development team when updating your revised stories. If you haven'testimates done so for already, refineuser the user stories in your release goal. 5. Get the development team's buy-in and commitment for the first release. Be sure you have consensus on both the release date and the release goal. TIP Not all agile projects use release planning. Some scrum teams release functionality for customer use with every sprint. The development team, product, organization, customers, stakeholders, and technological complexity can all help determine your approach to product releases. The planned releases now go from a tentative plan to a more concrete goal. Figure 8-7 represents a typical release plan. Figure 8-7: Sample release plan TIP Bear in mind the pen-pencil rule: You can commit to (write in pen) the plan for the first release, but anything beyond the first release is tentative (written in pencil). In other words, use just-in-time planning (see Chapter 7) for each release. After all, things change, so why bother getting microscopic too early? Sprint Planning In agile projects, a sprint is a consistent iteration of time in which the development team creates a specific group of product capabilities from Page 10 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies start to finish. At the end of each sprint, the product that the development team has created should be working and ready to demonstrate. Sprints should be the same length within a project. Keeping the sprint lengths consistent helps you measure the development team's performance and plan better at each new sprint. Sprints generally last one, two, three, or four weeks. Four weeks is the longest amount of time any sprint should last; longer iterations make changes riskier, defeating Each sprint includes the following: the purpose of agile. n Sprint planning at the beginning of the sprint n Daily scrum meetings n Development time — the bulk of the sprint n A sprint review and a sprint retrospective at the end of the sprint Discover more about daily scrums, sprint development, the sprint review, and the sprint retrospective in Chapters 9 and 10. In this chapter, you find out how to plan sprints. Sprint planning is Stage 4 on the Roadmap to Value, as you can see in Figure 8-8. The entire scrum team — the product owner, the scrum master, and the development team — works together to plan sprints. Figure 8-8: Sprint planning as part of the Roadmap to Value The Sprint Backlog The sprint backlog is a list of user stories associated with the current sprint and related tasks. When planning your sprint, you n Establish goals for your sprint. n n Choose the user stories that support those goals. Break user stories into specific development tasks. n Create a sprint backlog. The sprint backlog includes ¡ The list of user stories within the sprint in order of priority. ¡ The relative effort estimate for each user story. ¡ The tasks necessary to develop each user story. At the task level, you estimate the number of hours each task will take to complete, instead of using story points. Since your sprint has a specific length, and thus a set number of available working hours, you can use the time each task takes to determine whether the tasks will fit into your sprint. ¡ The effort, in hours, to complete each task. ¡ Each task should take one day or less for the development team to complete. A burndown chart, which shows the status of the work the development team has completed. TECHNICAL STUFF Tasks in agile projects should take a day or less to complete for two reasons. The first reason involves basic psychology: People are motivated to get to the finish line. If you have a task that you know you can complete quickly, you are more likely to finish it on time, just to check it off your to-do list. The second reason is that one-day tasks provide good red flags that a project might be veering off course. If a development team member reports that he or she is working on the same task for more than one or two days, that team member probably has a roadblock. The scrum master should take the opportunity to investigate what might be keeping the team member from finishing work. (For more on managing roadblocks, see Chapter 9.) The development team collaborates to create and maintain the sprint backlog, and only the development team can modify the sprint backlog. The sprint backlog should Page 11 / 14 reflect anforup-to-the-day snapshot of the sprint's progress. Figure 8-9 shows a sample sprint backlog. You can use this example, find other samples, or even use a white Reprinted CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited board. Agile Project Management for Dummies Figure 8-9: Sprint backlog example The Sprint Planning Meeting On the first day of each sprint, often a Monday morning, the scrum team holds the sprint planning meeting. Base the length of your planning meeting on the length make of yoursure sprints: Meet involved for no more than two hours for everyto week of your Thismeeting. timebox is one of the TIP For asprint successful sprint planning meeting, everyone in the session is dedicated the effort forsprints. the entire rules of scrum. Figure 8-10 illustrates this and is a good quick reference for your meeting lengths. Figure 8-10: Sprint planning meeting to sprint length ratio TECHNICAL STUFF On agile projects, the practice of limiting the time of your meetings is sometimes called timeboxing. Keeping your meetings timeboxed ensures that the development team has the time it needs to create the product. You will split your sprint planning meetings into two parts: one to set a sprint goal and choose user stories for the sprint, and another to break down your user stories into individual tasks. The details on each part are discussed next. In the first part of your sprint planning meeting, the product owner and development team, with support from the scrum master, do the following: Part 1: Setting Goals and Choosing User Stories 1. Discuss and set a sprint goal. Page 12 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies 2. Review the user stories from the product backlog that support the sprint goal and revisit their relative estimates. 3. Determine what the team can commit to in the current sprint. At the beginning of your sprint planning meeting, the product owner and the development team should determine a goal for the sprint. The sprint goal should be an overall description supported by the highest-priority user stories in the product backlog. A sample sprint goal for the mobile banking application (refer to Chapter 7) might be As a mobile banking customer, I want to log in to my account so I can view my account balances and pending and prior transactions. Using the sprint goal, you determine the user stories that belong in this sprint. You also take another look at the estimates for those stories and make changes to the estimates if you need to. For the mobile banking application sample, the group of user stories for the sprint might include n Log in and access my accounts. n n View account balances. View pending transactions. n View prior transactions All these would be high-priority user stories that support the sprint goal. The second part of reviewing user stories is confirming that the effort estimates for each user story look correct. Adjust the estimate if necessary. With the product owner in the meeting, resolve any outstanding questions. Finally, once you know which user stories support the sprint goal, the development team should agree and confirm it can complete the goal planned for this sprint. If any of In the the second part of the planning meeting, theinscrum team sprint, does the following: stories yousprint discussed earlier don't theuser current them from the sprint and add themeach backpart intoof the product backlog. 1. Create user the sprint backlog tasks associated withfiteach story. Makeremove sure that there are tasks encompassing the definition of done: developed, integrated, tested, and future documented. WARNING! Always plan and work one sprint at a time. Don't place user stories into specific sprints — it's an easy trap to fall into. For example, don't decide that 2. user story X should go into sprint 3 or 4. Instead, keep the ordered list of user stories up to date the product backlog Double-check that the team can complete the tasks in the time available in the sprint. Eachindevelopment team and focus on always developing the remaining highest-priority stories. Commit only to planning for the current sprint. 3. TIP Developmentmember team members should onher only one task one user story at a time to enable swarming — the practice of having the shouldrequirement choosework his or first task to on accomplish. wholeadevelopment team work on until completion. a very efficient to complete work in a short of time. meeting Once you have sprint goal, user stories for one the sprint, and commitment to the Swarming goal, movecan on be to the second part way of sprint planning. Because youramount sprint planning may last a few hours, you might want to take a break between the two parts of the meeting. At the beginning of part two of the meeting, break the user stories into individual tasks and allocate a number of hours to each task. The development team should target being able to complete a task in a Part day or2:less. For example, a user forBacklog the XYZ Bank mobile application might be Creating Tasks for the story Sprint Log in and access my accounts. The team decomposes this user story into tasks, like the following: n Create an authentication screen for a username and password, with a Submit button. n n Create an error screen for the user to reenter credentials. Create a logged-in screen (includes list of accounts — to be completed in next user story). n Using codedo from the check online to banking application, for an iPhone/iPad Once you know the number of hours that authentication each task will take, a final make sure that the rewrite numbercode of hours available to the application. development team reasonably matches the total of the tasks' estimates. If the tasks exceed the hours available, one or more user stories will have to come out of the sprint. Discuss with the product owner what n Create calls toor the database verify the username tasks user stories to are the best to remove.and password. n Refactor forbe mobile devices. If extra time is available within the sprint, the development teamcode might able to include another user story. Just be careful about over- Reprinted for CTS/316124, Cognizant Technology Solutions Page 13 / 14 John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies committing at the beginning of a sprint, especially in the project's first few sprints. After you know which tasks will be part of the sprint, choose what you will work on first. Each development team member should select his or her initial task to accomplish for the sprint. Team members should focus on one task at a time. TIP As the development team thinks about what they can complete in a sprint, use the following guidelines to ensure that they don't take on more work than they can handle: n Sprint 2: 50 percent of what the team thinks it can accomplish. n Sprintn 3: 75 percent of what of thewhat team thinks can accomplish. Sprint 1: 25 percent the teamitthinks it can accomplish. Include overhead for learning the new process and starting a new project. n Sprint 4 and forward: 100 percent. The team will have developed a rhythm, gained insight into agile and the project, and will be working at close to full pace. The team should constantly evaluate the sprint backlog against the development team's progress on the tasks. At the end of the sprint, the team can also assess estimation skills and capacity for work. This evaluation is especially important for the first sprint. TECHNICAL STUFF For the sprint, how many total working hours are available? In a 40-hour week, you could wisely assume, for a two- week sprint, that nine working days are available to develop user stories. If you assume each full-time team member has 35 hours per week (seven productive hours per day) to focus on the project, the number of working hours available is Number of team × 7 hours × 9working days on the tasks to create the product! After the sprint planning is finished, the development teammembers can immediately start Why nine days? Half of day one is taken planning, and half of day ten is taken up with the sprint the stakeholders review thetocompleted and the The scrum master should make sure up thewith product roadmap, product backlog, and sprint backlog arereview all in a(when prominent place and accessible everyone.work) This allows sprintand retrospective (when parties the team improvements futureonsprints). That leaves nine daysthe of development. managers other interested to identifies view the artifacts and getfor status progress without interrupting development team. Page 14 / 14 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies by Mark C. Layton John Wiley & Sons (US). (c) 2012. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Agile Project Management for Dummies Chapter 1: Modernizing Project Management In This Chapter n Understanding why project management needs to change Agile projectn management is a style project management that focuses on early delivery of business value, continuous improvement of the project's product and Finding out about agileof project management processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs. In this chapter, you find out why agile processes emerged as an approach to software development project management in the mid-1990s and why agile methodologies have caught the attention of project managers, customers who invest in the development of new software, and executives whose companies fund software development departments. This chapter also explains the advantages of agile methodologies over long-standing approaches to project management. Project Management Needed Makeover A project is a planned program of work that requires a definitive amount of time, effort, and planning to complete. Projects have goals and objectives and often must be completed in some fixed period of time and within a certain budget. If you approaches are reading this book, it's likely thatneed you are either a project manager, or you To areunderstand someone who projects, works on projects, or projects, is affected by projects in some Agile are a response to the to modernize project management. howinitiates agile approaches are revolutionizing it helps to know a way. little about the history and purpose of project management and the issues that projects face today. The Origins of Modern Project Management Projects have been around since ancient times. From the Great Wall of China to the Mayan pyramids at Tikal, from the invention of the printing press to the invention of the Internet, people have accomplished endeavors big and small in projects. As a formal discipline, project management as we know it has only been around since the middle of the twentieth century. Around the time of World War II, researchers around the world were making major advances in building and programming computers, mostly for the United States military. To complete those projects, they started creating formal project management processes. The first processes were based on step-by- step manufacturing models the United States military used during World War II. People in the computing field adopted these step-based manufacturing processes because early computer-related projects relied heavily on hardware, with computers that filled up entire rooms. Software, by contrast, was a smaller part of computer projects. In the 1940s and ‘50s, computers might have thousands of physical vacuum tubes but fewer than 30 lines of programming code. The 1940s’ manufacturing process used on these initial computers is the foundation of the project management methodology known as waterfall. 1. Requirements. 2. Design. In 1970, a computer scientist named Winston Royce wrote "Managing the Development of Large Software Systems," an article for the IEEE that described the phases in the 3. waterfall methodology. The term waterfall was coined later, but the phases, even if they are sometimes titled differently, are essentially the same as originally defined by Development. 4. Integration. Royce: 5. 6. Testing. Deployment. On waterfall projects, you move to the next phase only when the prior one is complete — hence, the name waterfall. TECHNICAL STUFF Pure waterfall project management — completing each step in full before moving to the next step — is actually a misinterpretation of Royce's suggestions. Royce identified that this approach was inherently risky and recommended prototyping and working within iterations to create products — suggestions were overlooked by many that adopted methodology. Until improved approaches based on agile techniques that surpassed it around 2008, the organizations waterfall methodology was the the waterfall most common project management approach in software development. Software project success and failure Unfortunately, the stagnation in project management approaches is catching up with the software industry. In 2009, a software company called the Standish Group did a study on software project success and failure in the United States. The results of the statistical study Page 2 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies showed that n n 24% of projects failed outright. This means that the projects were cancelled before they finished, and did not result in any releases. These projects delivered valuefinished, whatsoever. n 44% of projects were challenged. This means that the no projects but they had gaps between expected and actual product cost, time, 44% of projects were challenged. This means that the projects finished, but they had gaps between expected and actual quality, or a combination of n 32% of projects succeeded. This means the projects finished and delivered the expected product in the originally expected time and oking at time, these elements. The average difference between the expected and actual project results — lo cost, and features not delivered — was 189%. n In 2009, companies and organizations theprojects U.S. spent $491.2 on application development. Thatoriginally means that more than $103 billion 32% of projects succeeded. This meansinthe finished andbillion delivered the expected product in the budget. In 2009, companies and organizations in the U.S. spent $491.2 billion on application development. That means that more was wasted on failed The Problem with the Status Quo projects. Computer technology has, of course, changed a great deal since the last century. I have a computer in my pocket with more power, memory, and capabilities than the largest, most expensive machine that existed when people first started using waterfall methodologies — and my computer has a telephone attached. At the same time, the people using computers have changed as well. Instead of creating behemoth machines with minimal programs for a few researchers and the military, people create hardware and software for the general public. In many countries, almost everyone uses a computer, directly or indirectly, every day. Software runs our cars; it provides our daily information and daily entertainment. Even tiny children use computers — my friends' two-year-old is almost more adept with the iPhone than her parents. The demand for newer, better software products is constant. Somehow, during all this growth of technology, the processes were left behind. Software developers are still using project management methodologies from the 1950s, and these approaches were all derived from manufacturing processes meant for the hardware-heavy computers of the mid-twentieth century. Today traditional projects that do succeed often suffer from one problem: scope bloat, the introduction of unnecessary product features in a project. Think about the software products you use every day. For example, the word-processing program I'm typing on right now has a lot of features and tools. Even though I write on this program every day, I use only some of the features all the time. There are some elements that I use less frequently. There are quite a few tools that I have never used, and come to think of it, I don't know anyone else who has used them, either. These features that few people or no one uses are the result of scope bloat. Scope bloat appears in all kinds of software, from complex enterprise applications, to websites that everyone uses. The chart in Figure 1-1 shows data from another Standish Group study that illustrates just how common scope bloat is. In the figure, you can see the proportion of requested features that are actually used when the software goes into production. Sixty-four percent of the features are rarely or never used. Copyright 2011 by Standish Group. Page 3 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Figure 1-1: Actual use of software features The numbers in Figure 1-1 illustrate an enormous waste of time and money. That waste is a direct result of traditional project management processes that are unable to accommodate change. Project managers and stakeholders know that change is not welcome mid-project, and that their best chance of getting a potentially desirable feature is at the project start, so they ask for n n Everything they think they may need n n Everything they need Everything they want Everything they think they may want The result is the bloat in features that results in the statistics in Figure 1-1. Introducing Agile Projectare Management The problems associated with using outdated management and development approaches not trivial. These problems waste billions of dollars a year. The $103 billion lost in project failure in 2009 (see the sidebar, "Software project success and failure") could equate to millions of jobs around the world. The seeds for agile techniques have been around for a long time. Figure 1-2 shows a quick history of agile project management, dating back to the 1930s with Walter Sherwart's (PDSA) approach project quality. Over the past two decades, people working on projects have Plan-Do-Study-Act recognized the growing problems withtotraditional project management and have been working to create a better model: agile project management. Figure 1-2: Agile project management timeline In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called "New New Product Development Game in the Harvard Business Review." Takeuchi and Nonaka's article described a rapid, flexible development strategy to meet fast-paced product demands. This article first coined the term scrum in conjunction with product development, comparing product development to a game of rugby. Scrum eventually became one of the most popular agile project management approaches. In 2001, a group of software and project experts got together to talk about what their successful projects had in common. This group created the Agile Manifesto, a statement of values for successful software development: Manifesto for Agile Software Development[*] Working software over comprehensive documentation We are collaboration uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Customer over contract negotiation Individuals and interactions over processes and tools 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. These experts also created the Agile Principles, 12 practices that help support the values in the Agile Manifesto. I list the Agile Principles and describe the Agile Manifesto in more detail in Chapter 2. Agile, in product development terms, is a description for project management methodologies that focus on people, communications, the Reprinted for CTS/316124, Cognizant Technology Solutions Page 4 / 6 John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies product, and flexibility. There are many agile methodologies, including scrum, extreme programming, and lean, but they all have one thing in common: adherence to the Agile Manifesto and the Agile Principles. How Agile Projects Work Agile approaches are based on an empirical control method — a process of making decisions based on the realities observed in the actual project. In the context of software development methodologies, an empirical approach can be very effective in both new product development and enhancement and upgrade projects. By using frequent and firsthand inspection of the work to date, you can make immediate adjustments, if necessary. Empirical control requires n Frequent ninspection: The people whoinvolved are invested the product and process most regularly evaluate the product and Transparency: Everyone on aninagile project knows what isthe going onshould and how the project is progressing. process. n Adaptation: Make adjustments quickly to minimize problems; if inspection shows that you change, thenOn change To accommodate frequent inspection and adaptation, agile projects work in iterations (smaller segments ofshould the overall project). agile immediately. projects, you still have the same type of work that is involved on a traditional waterfall project: You have to create requirements and designs, you develop your product, and if necessary, you integrate your product with other products. You test the product, fix any problems, and deploy it for use. However, instead of completing these steps for all of your product features at once, you break the project into iterations, also called sprints. Figure 1-3 shows the difference between a linear waterfall project and an agile project. Figure 1-3: Waterfall versus agile project WARNING! Mixing traditional project management methods with agile approaches is like saying, "I have a Porsche 911 Turbo. However, I'm using a wagon wheel on the front left side and right rear side. How can I make my car as fast as the other Porsches?" The answer, of course, is you can't. If you fully commit to an agile approach, you will find you have a better chance at project success. Why Agile Projects Work Better Throughout this book, you will see how agile projects work better than traditional projects. Agile project management methodologies have been able to produce more successful projects. The Standish Group, mentioned in the sidebar "Software project success and failure", also did a study of project success rates in 2009. That year, the group found that 26 percent of projects failed outright — but in 2011, that number fell by 5 percent. The decrease in failure has, in part, been attributed to wider adoption of agile approaches. Here are some key areas where agile approaches are superior to traditional project management methods: Page 5 / 6 Reprinted for CTS/316124, Cognizant Technology n Project success rates:Solutions In Chapter 15, you will find out how the risk of catastrophic project failure falls to almost nothing on agile projects. John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management for Dummies Agile approaches of prioritizing by business value and risk ensures early success or failure. Agile approaches to testing throughout the project help ensure that you find problems early, instead of after spending a large amount of time and money. n n Scope creep: In Chapters 7, 8, and 12, you see how agile approaches accommodate changes throughout a project, minimizing the idea of scope creep. On agile projects, you can add new requirements at the beginning of each sprint without disrupting development flow. By fully developing prioritized features first, you'll prevent scope creep from threatening critical functionality. Inspecting and adaptation: In Chapters 10 and 14, you find details of how regular inspecting and adaptation work on agile projects. Agile project teams can improve their processes and their products with each sprint armed with information from complete development cycles and actual product. Throughout many of the chapters in this book, you discover how you gain control of the outcome of agile projects. Testing early and often, adjusting priorities as needed, [*]Agile using betterManifesto communication techniques, regularly demonstrating andvan releasing product functionality allowWard you toCunningham, fine-tune yourMartin controlFowler, over a James wide variety of factors Copyright © 2001:and Kent Beck, Mike Beedle, Arie Bennekum, Alistair Cockburn, Grenning, Jim on agile projects. Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas If you're interested the possibility of agile, thenthis thisnotice. is the perfect book for you. This declaration may be freely copied in any form, butinonly in its entirety through Page 6 / 6 Reprinted for CTS/316124, Cognizant Technology Solutions John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited Agile Project Management For Dummies From Agile Project Management For Dummies by Mark C. Layton Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management methodologies include scrum, extreme programming (XP), and lean, among others. These methodologies all adhere to the Agile Manifesto and the 12 Agile Principles, which focus on people, communications, the product, A Manifesto for Agile Software Developers and flexibility. The Agile Software Development Manifesto© is an intentionally streamlined expression of the core values of agile project management. Use this manifesto as a guide to implement agile methodologies in your projects. "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." ©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. This declaration may be freely copied in any form, but only in its entirety through this notice. The 12 Agile Principles The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts to implement agile methodologies in your projects. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. 4. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. 8. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity — the art of maximizing the amount of work not done — is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The Agile Roadmap to Value The Roadmap to Value is a high-level view of an agile project. The stages of the Roadmap to Value are described in the list following the diagram: • • In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision at least once a year. In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year. • In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release. • In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration. • In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have. • In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders. • In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint. Agile Project Management Roles It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the following five roles: • Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team. • Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer's needs and priorities. The product owner works with the development team daily to help clarify requirements. The product owner is sometimes called a customer representative. • Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator. • • Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project's outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies. Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level. Agile Project Management Artifacts Project progress needs to be measurable. Agile project teams often use six main artifacts, or deliverables, to develop products and track progress, as listed here: • Product vision statement: An elevator pitch, or a quick summary, to communicate how your product supports the company's or organization's strategies. The vision statement must articulate the goals for the product. • Product backlog: The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement, you have a product backlog. • Product roadmap: The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. • • • Release plan: A high-level timetable for the release of working software. Sprint backlog: The goal, user stories, and tasks associated with the current sprint. Increment: The working product functionality at the end of each sprint. Agile Project Management Events Most projects have stages. Agile projects include seven events for product development. These events are meetings and stages and are described in the following list: • Project planning: The initial planning for your project. Project planning includes creating a product vision statement and a product roadmap, and can take place in as little time as one day. • Release planning: Planning the next set of product features to release and identifying an imminent product launch date around which the team can mobilize. On agile projects, you plan one release at a time. • Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. Sprints, sometimes called iterations, typically last between one and four weeks. Sprints can last as little as one day, but should not be longer than four weeks. Sprints should remain the same length throughout the entire projects. • Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement. • Daily scrum: A 15-minute meeting held each day in a sprint, where development team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks. • Sprint review: A meeting at the end of each sprint, introduced by the product owner, where the development team demonstrates the working product functionality it completed during the sprint. • Sprint retrospective: A meeting at the end of each sprint where the scrum team discusses what went well, what could change, and how to make any changes. Agile Project Management Organizations, Certifications, and Resources There is a big agile project management world out there. Here are a few of the useful links to members of the agile practitioner community: • Agile Alliance: The Agile Alliance is the original global agile community, with a mission to help advance agile principles and practices, regardless of methodology. • Scrum Alliance: The Scrum Alliance is a nonprofit professional membership organization that promotes understanding and usage of scrum. The Scrum Alliance offers a number of professional certifications: • Certified Scrum Master (CSM) • Certified Scrum Product Owner (CSPO) • Certified Scrum Developer (CSD) • Certified Scrum Professional (CSP) • Certified Scrum Coach (CSC) • Certified Scrum Trainer (CST) XProgramming.com: Ron Jeffries, one of the originators of the extreme programming (XP) development approach, provides resources and services in support of XP's advancement on the XProgramming.com site. Lean Essays: Lean Essays is a blog from Mary and Tom Poppendieck, thought leaders in the use of lean concepts within the software development space. PMI Agile Community: The Project Management Institute (PMI) is the largest nonprofit project management membership association in the world. The agile section of PMI's website provides access to papers, books, and seminars about agile project management. PMI supports an agile community of practice and a certification, the PMI Agile Certified Practitioner (PMI-ACP). Platinum Edge: Since 2001, my team at Platinum Edge has been helping companies successfully take their project management practices to a higher level. We provide training classes worldwide and also develop transition strategies and coaching for organizations moving to agile project management. Visit the training section of our site to find an upcoming Certified Scrum Master, Certified Scrum Product Owner, PMI-ACP preparation, or agile overview class near you. Agile Estimating & Planing Agile Estimating and Planning Introduction & Review Course Outline Agile Overview Why Plan and What Makes a Good Plan? Why Traditional Planning Fails Agile Planning Estimating with Story Points {15-minute break} Estimating with Ideal Days 3-Step Feature Prioritization Process Measuring and Forecasting Velocity Critical Chain Estimating and Scheduling Why Agile Works Wrap Up Planning & Evaluations © 2011 Kevin Aguanno. All rights reserved. An Overview of Agile (C) 2011 Kevin Aguanno. 2 Agile Estimating & Planing Agile Manifesto Adherents stress: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation That is, while there is value in the items on the right, we Responding to change value the items onover the following left more. a plan © 2001 The Agile Alliance © 2011 Kevin Aguanno. All rights reserved. Agile Development Principles Project Characteristics: Early and continuous delivery of usable deliverables Usable deliverables measure progress Accept changing requirements, even late in project Simplicity in all aspects Short delivery cycles is essential Sound, flexible design/architecture © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 3 Agile Estimating & Planing Iterative and Incremental Delivery Month 1 Month 2 A/B/C A B Waterfall Iterative A B A1 A B1 Incremental Agile C C1 A1,2 Month 3 C A+B B1,2 C1,2 A B C A+B+C A1,2,3 B1,2,3 C1,2,3 The Agile Approach is Iterative AND Incremental © 2011 Kevin Aguanno. All rights reserved. Predictability Varies as should Metrics Deterministic (Plan-Based) (ObservationBased) Focus is on adherence to plan Empirical Focus is on delivering value to customer © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 4 Agile Estimating & Planing To Recap… Agile methods are built upon the engine of iterative and incremental delivery Benefits: Improved responsiveness to change More customer input/control/feedback allowed Less risk (building the wrong thing, building the right thing wrong) Visible/verifiable progress © 2011 Kevin Aguanno. All rights reserved. How Scrum Manages Requirements Changes SCRUM Structure Initial List of Features Grouped List of Features Feature 1 Feature 1 Feature 3 Sprint #1 Feature 2 Feature 7 Feature 3 Feature 4 Planning Feature 2 Feature 5 Feature 4 Sprint #2 Feature 6 Feature 5 Feature 7 Closure Feature 6 Product Backlog By Kevin Aguanno. (C) 2002 Element K Journals. (C) 2011 Kevin Aguanno. 5 Agile Estimating & Planing Progress Metrics XP: Velocity (Features Completed / Planned) Scrum: Sprint Burndown Chart (Est. Hours Remaining vs. Date) FDD: Cumulative Features Completed (# Features vs. Week) © 2011 Kevin Aguanno. All rights reserved. Quality Management Common quality management techniques suggested by agile methods include Early and continuous testing (more time to fix defects, less cost for remedial activities) Test-Driven Development (focus on objective quality criteria) 100% functional testing each build (or at least each iteration) Code/Design inspections/pair programming © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 6 Agile Estimating & Planing Deliverables Acceptance Using agile methods, final sign-off/acceptance of deliverables is usually trouble-free, due to Test-Driven Development (start with useracceptance tests) Customer involvement in (re)prioritization Short iterations with demonstrations at iteration end (frequent customer feedback) These elements of agile methods make sign-off easier when dealing with multiple sponsors. © 2011 Kevin Aguanno. All rights reserved. Agile Methods are Harder to Implement in Some Situations Large teams Complex team organizational structures Geographically-scattered teams Life- or mission-critical applications © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 7 Agile Estimating & Planing Why Plan and What Makes a Good Plan? “Planning is everything. Plans are nothing.” Field Marshal Helmuth Graf von Moltke (1800-1891) Why Plan? Planning is a quest for value, an attempt to find the optimal solution to what should be built and how to build it. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 8 Agile Estimating & Planing Planning improves the chances of success Reducing by: Risk Thinking through the possibilities allows us to take preventative actions Improving Understanding Helps prevent building the wrong thing Supporting Making trade offs, Data provides a basis Decision for understanding etc. Conveying Information Conveys expectations Describes one possibility of future project events Trust & plans CreatingEstablishing reliable estimates What makes a good plan? Stakeholders should find it “good enough” to use as a basis for decision making © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 9 Agile Estimating & Planing Why Traditional Planning Fails “No plan survives contact with the enemy.” Field Marshal Helmuth Graf von Moltke (1800-1891) The Cost of Traditional Planning Feature Usage Within Deployed Applications Often 13% Always 7% Never 45% Sometimes 16% Rarely 19% Source: Chaos Report v3 www.standishgroup.com © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 10 Agile Estimating & Planing We traditionally plan by task, not byfocus feature Traditional methods on the completion of tasks rather than delivering features. Customers get little value from the completion of tasks. Features are the true measure of customer value. When we review traditional task-based schedules, we tend With effort attasks feature prioritization across multiple to look forlittle forgotten rather than for missing features. releases, we tend to build all features in one release, regardless of importance/value to the business. © 2011 Kevin Aguanno. All rights reserved. Tasks rarely finish early Parkinson’s Law : “Work expands to fill the time available for its completion.” People’s natural tendency is to not work as fast when there is lots of time available for a task. An official schedule showing a week to complete a task gives implicit “permission” to take that full week. If done early, people may “gold plate” the solution by adding extra features not requested by the sponsor. People also spend more time researching novel approaches to the solution if they perceive that they have lots of time. There may be a fear that if people finish early, they may be accused of “padding” their estimates or that they will be expected to complete their ©other work too. 2011 Kevin Aguanno.early All rights reserved. (C) 2011 Kevin Aguanno. 11 Agile Estimating & Planing Delays cascade through the schedule Traditionalproject task-based plans focus on dependencies between tasks. Late completion of one task can cause following tasks to also be late. This is exacerbated by the earlier point that tasks rarely finish early. As a result, in traditionally-planned projects, testing rarely gets to start early and early completion is rare. Multi-tasking causes further delays Multi-tasking hurts productivity . With two tasks, productivity improves as athe person switch to one while other can is blocked by something. We rarely only have two tasks, however, and productivity drops off after two tasksrapidly are assigned concurrently. Apart from time lost when switching between tasks (or projects), a person loses focus/concentration. (C) 2011 Kevin Aguanno. Effects of Multi-Tasking on Productivity 90 80 70 60 50 40 30 20 10 0 1 2 3 4 5 # Concurrent Tasks Source: K. Clark and S. Wheelwright. Managing New Product and Process Development: Text and Cases. The Free Press, 1993. © 2011 Kevin Aguanno. All rights reserved. 12 Agile Estimating & Planing Multi-tasking causes further delays Multi-tasking becomes(cont’d) a significant issue once some tasks finish late. It is usually encouraged to increase overall team member utilization, rather than maintaining sufficient slack to cope with typical project Loading the team tovariability. 100% capacity is like loading a highway to 100% capacity - no one makes any progress. © 2011 Kevin Aguanno. All rights reserved. Features are not developed by priority In traditional plans: Work is prioritized and sequenced for the convenience of the development team. All requirements/work must be completed, so the sponsor should not care about the sequence. Near the end of the project, the team scrambles to meet the schedule by dropping features, but with no effort to prioritize features up front, critical features could get dropped. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 13 Agile Estimating & Planing We tend to ignore uncertainty We assume that the requirements analysis led to a complete and perfect specification. We assume that sponsors will not change their minds, refine their opinions, or come up with new needs during the project. We ignore uncertainty about how we will build the product. We assign precise estimates to this uncertain work. © 2011 Kevin Aguanno. All rights reserved. Estimates become commitments The only way we will know the project costs for sure is to look at the actuals when the project is Humans cannot seeover. the future, so we estimate based on our experience and the information at hand including inherent uncertainties. Each estimate has its a confidence level (probability) associated with it. In traditional projects, these estimates get seen as commitments, even when they are at less than 100% probability. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 14 Agile Estimating & Planing Reduction in Uncertainty 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 Agile Planning “A good plan […] executed now is better than a perfect plan executed next week.” General George S. Patton Jr. (1885-1945) (C) 2011 Kevin Aguanno. 15 Agile Estimating & Planing Agile approach to projects Plan on a multi-disciplinary team. Include sponsor/product owner, project manager, developers, designers, and testers/QA. Break project into short iterations. Timebox each iteration. Typically, 2-4 weeks. Deliver something each iteration. Iterations deliver products that are of releasable quality. on business priorities. Deliver featuresFocus (not tasks) using user stories, prioritized by the business. Inspect and adapt. Update the plan to reflect actual experiences and the benefits of new knowledge. Adjust priorities at the start of each iteration to maximize the ROI. © 2011 Kevin Aguanno. All rights reserved. Agile teams have three levels of planning Release Plans To prepare project-level schedule, resource plans, and overall scope. Iteration Plans To identify high-priority features to be completed in the next iteration. To plan the work (tasks) required to build the selected features. Day Plans task. (C) 2011 Kevin Aguanno. Informal discussion during the daily meeting/call to coordinate work and share information. Planning the activities leading up to the completion of a © 2011 Kevin Aguanno. All rights reserved. 16 Agile Estimating & Planing What is Release Planning? Building a high-level project schedule identifying: # Iterations & their start/end dates Releases & their start/end dates Key business milestones Interlocks with other projects Initial contents for each iteration (stories/features, not tasks) © 2011 Kevin Aguanno. All rights reserved. Release Planning Constraints - Schedule Requirements - User Stories - Features Estimate Size Prioritization and Grouping 1) Business Priority 2) Technical Dependencies 3) Logical Groupings - Budget Divide into Iterations 1) Choose Iteration Length 2) Estimate Velocity 3) Divide Into Iterations 4) Prepare High-Level Schedule © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 17 Agile Estimating & Planing 3-Step Feature Prioritization Process "Strategy is a style of thinking, a conscious and deliberate process, an intensive implementation system, the science of insuring future success." Dr. Pete Johnson (a.k.a. “Dr. Strategy”) Factors: After estimating story size, prioritize the list 1. Calculate the business priority a) Financial value (NPV, IRR, payback, etc.) or customer service value b) Cost of developing/supporting (can divide actual costs for last iteration by # story points for an avg. $/point to use in foreward c) Amount of learning (about planning) product and process) and personal skill development (tools, etc.) d) Amount of risk removed e) Legal/Compliance requirements 2. Factor in technical dependencies 3. Adjust for logical groupings © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 18 Agile Estimating & Planing Risk can be an important deciding factor Avoid Do First Do Last Do Second Value © 2011 Kevin Aguanno. All rights reserved. Project Backlog Contents: Example - Identify Backlog Items © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 19 Agile Estimating & Planing Project Backlog Prioritization 1. Calculate the business priority Factors: a) Financial value (NPV, IRR, payback, etc.) or customer service value b) Cost of developing/supporting (can divide actual costs for$/point last iteration byforeward # story points for an avg. to use in planning) c) Amount of learning (about product and process) and personal skill development (tools, etc.) d) Amount of risk removed e) Legal/Compliance requirements © 2011 Kevin Aguanno. All rights reserved. Project Backlog Prioritization: Example - Assign Business Value © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 20 Agile Estimating & Planing Project Backlog Prioritization: Example - Sort by Business Value © 2011 Kevin Aguanno. All rights reserved. Project Backlog Prioritization: Example - Factor in Logical Dependencies © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 21 Agile Estimating & Planing Project Backlog Prioritization: Example - Estimate Complexity (Points) © 2011 Kevin Aguanno. All rights reserved. Estimating for Release Plans When at the “Estimating Size” step of the release planning process, you can use one of two methods: Story Points A unit of measure for expressing overall size, complexity, risk, etc. of a user story/feature. An abstract unit, not directly convertible to hours, days, etc. Based on completion of the story/feature by the whole team. A day of developmentIdeal workDays with full utilization (no multitasking, no interruptions, no technical difficulties). Needs to be added up for all people involved in defining and completing the story. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 22 Agile Estimating & Planing Estimating With Story Points “It is better to be roughly right than precisely wrong.” John Maynard Keynes (1883-1946) Estimating with Story Points Use one of two techniques to get started: Find the smallest user story and assign it a value of “1”. Or, find a medium-sized story and assign it a value of Then, as a group, assign “5”. all remaining stories a value between 1 and 10 based upon their relative and riskshould to the be other stories. E.g. acomplexity story that is a “4” twice as complex as a story that is a “2”. Don’t over-analyze. Ask a few questions of the product owner, make some assumptions, take a guess, and move on to the next story. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 23 Agile Estimating & Planing Estimating with Story Points Use a 0-10 point(cont’d) scale (zero for simple “freebies”) You can spend too much time trying to distinguish between a 6 and a 7, for example, so try to use: 0 for simple, “free” no-cost or low-cost stories. (Explain that by putting too many of these in a single iteration, they will start to up into points. 13x0 Studies > 0.) show that we 1, 2, and 3 foradd low-complexity stories. are good at distinguishing between simpler levels of complexity. 58 forfor medium complexity. high complexity. 10 for very high complexity. You can use 20, 40, and 100 for estimating epics and themes. Epics are large user stories you have not bothered to break down yet. Themes are groupings of related stories that can be treated as one unit for planning purposes. E.g. reports. © 2011 Kevin Aguanno. All rights reserved. The Agile Planning Game (C) 2011 Kevin Aguanno. 24 Agile Estimating & Planing Avoiding the dangers of group estimating There is a human tendency towards “group think” If you go around a room asking estimates to gain a consensus, some with deviating opinions will not speak up due to inadvertent To fix this, everyone needs to present their group pressure estimates simultaneously. © 2011 Kevin Aguanno. All rights reserved. An example User Story As a site visitor, I want to be able to subscribe to the company newsletter Initial Simultaneous Estimate John Mary Paul 13 5 8 Simultaneous Re-estimating after a Brief Discussion User Story John Mary Paul As a site visitor, I want to 8 5 5 be able to subscribe to the company newsletter © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 25 Agile Estimating & Planing Handle simultaneous estimating using “planning poker” Each estimator has a setcards of cards Special-purpose Fibonacci series cards - printedcards out and laminated (1,2,3,5,8,13,21,34) Regular playing cards (Ace = 1 point; 2-10 = face value, J/Q/K = 20/50/100 points, and ace=infinity) Basic Planning PokerTM process Facilitator reads out the user story + notes Team may ask product owner questions (high level) When questions answered, or timebox is out, everyone selects the card with the # points and puts it facedown on the table. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 26 Agile Estimating & Planing Dealing with discrepancies On the facilitator’s cue, everyone turns over their card If there was a big range, team discusses high and low estimates; perhaps, because someone thought of something others forgot Everyone puts their card backabout. in the deck and rethinks the story. The team then comes back to the table to try again for a theand second round. The process isconsensus repeated, on over over until a consensus is reached, or all remote concerns have been dealt with outside of this project. Process ends when consensus is reached, or when the difference is minimal and explainable. Please note that timeboxing is a good way to constrain the time for these activities. © 2011 Kevin Aguanno. All rights reserved. Finally, apply adjustment factors to A best practicethe is toestimates add adjustment factors to the estimates after the planning poker rounds have completed. These “fudge areoptions added in to: Discourage poorlyfactors” conceived Adjust for fuzzy requirements or lack of stakeholder buy-in for the project Adjust for resource availability issues for largework teams Add time forAdjust dysfunctional environments Adjust for technical or business risk Etc. Don’t get too granular or heavy-handed with these adjustment factors. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 27 Agile Estimating & Planing Estimating With Ideal Days “Ideals are like stars: you will not succeed in touching them with your hands, but like the seafaring man on the ocean desert of waters, themdestiny.” as your guides, and following them,you youchoose reach your Carl Schurz (1829 - 1906) Estimating with Ideal Days Ideal time differs from elapsed time because of the natural overhead and distractions we experience: Supporting the current release Sick time Meetings Demonstrations HR activities Phone calls Email Training Reviews / walk-throughs Task switching when multi-tasking © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 28 Agile Estimating & Planing Estimating with Ideal Days (cont’d) Problems arise when estimates are given in “days” with no qualification as to what a “day” means. Using the term “Ideal Days” helps to relieve this situation. Ideal Days is a measure of size, not duration. Assign one estimate to a story that is the sum of the Ideal Days estimates for each role required to complete the story (management, analysis, design, development, and testing). © 2011 Kevin Aguanno. All rights reserved. Story Points vs. Ideal Days Story Points Help drive cross-functional behaviour Estimates do not decay as skills develop, etc. A pure measure of size Faster than Days estimating Ideal Ideal Days More in-depth analysis of the tasks required story.to build a Easier to explain to outsiders, though there is acompared risk of having Ideal Days to calendar days Easier than Story Points to estimate at first My Ideal Days are not your Ideal Days (skillestimates) levels affect Ideal Days Chance of missing input from a key role © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 29 Agile Estimating & Planing Measuring & Forecasting Velocity “The order in which you do something determines the velocity with which you can act, or, the velocity with which you act determines the order in which you can do something.” Tim O’Connor Velocity A measure of the team’s rate of progress. Calculated by summing up the number of story points or ideal days that the teamif completed in its most iteration. For example, a team completed tenrecent story points last iteration, assume they can do ten again this iteration. Agile methods estimate size, not duration. Duration is derived from the size. Story points or ideal days are turned into a schedule by applying velocity. Add up all of the story point or ideal days totals for the project. Get the team’s velocity for a specific iteration length. Divide the point or day total by the velocity to determine the This number forms the for the release plan. of basis required iterations. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 30 Agile Estimating & Planing Velocity (cont’d) The beauty of using velocity as a measure for planning, is that it doesn’t matter if our estimates are correct, just that they are consistent. With consistent estimates, measuring velocity over the first few iterations will allow us to prepare a more reliablenew schedule. To estimate velocity projects, you can use: historical values (if team, tools, technology, etc. are the same) run an iteration to get actuals (or 3 iterations and take avg. or range) Or, make ©a2011 forecast Kevin Aguanno. All rights reserved. Estimating Initial Velocity: Using Historical Values For iteration 1, use the actual velocity from a past project only if: Same team Same technology/solution (e.g. developing version 6.1 based on existing version 6.0) Similar types of scope/backlog items For iterations 2 to n inside a project, use the last iteration’s velocity © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 31 Agile Estimating & Planing Estimating Initial Velocity (Simple): Forecasting Velocity for Fixed Team NOT the best approach, but one that we need in our toolkit. Steps: Estimate the # hours/day available to work on the project for each team member. (Typically, 60%-70% productivity for dedicated resources.) 2. Select the number of team members to be used - only those producing deliverables, not managers, etc. 3. Select an iteration length 4. Determine the total # hours spent on the project during an iteration. (= # hrs/day x # people on team x # days in iteration) Pick a few random stories and expand them into tasks and estimate the # effort hours per task, getting a total # hours for each story. Gather enough stories so that the # hours for each story adds up to the # hours available in an iteration. 7. Count up the story points for the selected stories to determine projected velocity. 1. 5. 6. Weakness: Assumes all team members included in calculation are equally productive and that they are all equally producing deliverables - does not identify overburdened resources © 2011 Kevin Aguanno. All rights reserved. Estimating Initial Velocity (Advanced): Forecasting Velocity for Optimal Team This method is more accurate than the simple method. Steps: Select a sampling of user stories of varying size and importance (usually 5-8 is enough). 2. Do an old-fashioned, detailed, bottom-up estimate in hours per resource type to design/build each story. 3. Select an iteration length 4. Determine how many stories will fill up the hours available in an iteration for the most utilized resource (i.e. most # hours of work for each story - usually the developers) 5. Now keep adding developers to increase the number of stories that can fit in the iteration until you optimize the less-utilized resources; or, stop when you hit the # developers available to the team. 6. Add up the story points assigned to all the stories that can fit into the iteration with the chosen team size - this number is your initial forecast velocity. 1. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 32 Agile Estimating & Planing Building the Initial Release Plan: Carving Up the Project Backlog Using the forecast velocity, carve up the project backlog into chunks of the appropriate size (+/- a two willthan likelythe bevelocity OK) forecast, If a chunk ispoint muchorsmaller but the next piece would push it way over, then look down the list for the next piece that would fit and Eachmove chunkit represents the the scope for one iteration up the list into current chunk For our ongoing example, let’s assume an initial forecast velocity of 10 points. © 2011 Kevin Aguanno. All rights reserved. Building the Initial Release Plan: Example - Carving Up the Project Backlog © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 33 Agile Estimating & Planing Building the Initial Release Plan: Plotting Iterations on a Calendar View Plot the iterations on a calendar view with real project start dates to get a realistic view. On high-uncertainty/high-risk projects where the end date will not move, it is good practice to leave one or two iterations before the end of the project to Scope increases absorb: The risk of technology challenges and defect correction work affecting velocity The risk of poor team performance © 2011 Kevin Aguanno. All rights reserved. Building the Initial Release Plan: Example - Plotting on a Calendar View Note: In this example, we dropped the original scope for Iteration 9 (Additional Resources, Bibliography, Dedication) as it was not possible to achieve this by our Feb. 15 deadline while still having some 2011unmovable Kevin Aguanno.project All rights end reserved. contingency/buffer to protect©our date. (C) 2011 Kevin Aguanno. 34 Agile Estimating & Planing Identifying Constraint Dates Mark on the calendar: Interlocks/dependencies with other projects Using another’s deliverable Providing deliverables to another Key business milestones/constraint dates/periods Major presentations (e.g. architecture review board meetings, trade show demos, board of directors presentations, Business events affecting theetc.) project (e.g. system change blackouts, office closures, etc.) Holidays/vacation periods (e.g. Christmas week, Canada Day/Independence Day week, etc.) that affect productivity © 2011 Kevin Aguanno. All rights reserved. Building the Initial Release Plan: Example - Identify Constraint Dates © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 35 Agile Estimating & Planing Defining Releases Release: A wave of solution development ending in a deployment/use of the solution by the business, consisting of one or more iterations. Most projects have 1-3 releases, though some release every iteration. A release should have enough “critical mass” for the business to bother going through the costs of acceptance testing and deployment. © 2011 Kevin Aguanno. All rights reserved. Building the Initial Release Plan: Example - Defining Releases © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 36 Agile Estimating & Planing Adjusting Release Plan Now move stories/features from iteration to iteration to reflect: Dependencies Key business milestones/constraint dates/periods (demos, blackouts, etc.) Lower productivity periods due to planned holidays Resource leveling Required release functionality © 2011 Kevin Aguanno. All rights reserved. Building the Initial Release Plan: Example - Adjusted Release Plan By reducing the # points achievable in the Christmas period, scope items (features) flow out to the right, cascading through the remainder of the schedule. We had to drop feature 17 (Index) to leave a buffer in Iteration 9. We could now include features 18, 15, and 2 (Additional Resources, Bibliography, Dedication) to fill in unused © 2011 8. Kevin Aguanno. All rights reserved. capacity in Iteration Release 1, to be used for early endorsements, would not include 3 chapters that will appear in the final release. (C) 2011 Kevin Aguanno. 37 Agile Estimating & Planing Iteration Planning - Actual Velocity Requirements - Reprioritized Analysis Release Plan Inputs Gather Acceptance Criteria Plan by Task Verify Resource Requirements 1) Identify Tasks (WBS) 2) Estimate by Hours of Effort 3) Prepare Schedules Very similar to how we plan/estimate today, except focus is only on#ahours smallas portion of possible, the project. By estimating late as we can be more precise as risks pass and uncertainty goes down. © 2011 Kevin Aguanno. All rights reserved. Critical Chain Estimating & Scheduling “An expert is not someone who gives you the answer, it is someone that asks you the right question.” Eliyahu Goldratt (1948- ) (C) 2011 Kevin Aguanno. 38 Agile Estimating & Planing Estimating Hours of Effort Hypothetically, if we run a project over and over again, the random variances in the actual duration of tasks will follow a standard Beta distribution. Note the tail showing worst-case scenarios. Median Duration Estimating Hours of Effort We (cont’d) normally estimate at that 90% of the time, our estimate is big enough. If we estimate confidence, half at the50% time we will have enough time and thewon’t. other half we Parkinson’s Law says that if wemost estimate 90%, then of thatattime we could have finished much earlier, but to thefilltask expanded its available duration. © 2011 (C) 2011 Kevin Aguanno. 90% confidence, meaning 50% Median 90% Duration Kevin Aguanno. All rights reserved. 39 Agile Estimating & Planing Estimating Hours of Effort (cont’d) Agile estimating says that we should estimate at 50% confidence at the task level, avoiding buffers on each task, and instead strategically place buffers in the This is called the Critical Chain Method of schedule. estimating/scheduling. Two buffer types: Feeder buffers (when two work streams come together) Project buffers (before key milestones or at the end of the project to protect key dates) These buffers can be much smaller than having buffers on individual tasks © 2011 Kevin Aguanno. All rights reserved. Within an iteration, use Critical Chain scheduling with buffers © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 40 Agile Estimating & Planing Why Agile Planning Works “If anything is certain, it is that change is certain. The world weexist are planning fortomorrow.” today will not in this form Philip Crosby (1926-2001) Why Agile Planning Works Replanning occurs frequently Estimates of size and duration are separated Plans are made at different levels Plans are based on features, not tasks Small stories keep the work moving Work in Progress is eliminated every iteration Uncertainty andlevel, planned Trackingisisacknowledged done at the team not for individual level © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 41 Agile Estimating & Planing Wrap Up “We should be taught not to wait for inspiration to start a thing. Action always generates inspiration.” Frank Tibolt (1897-1989) Techniques You can Start Using Today Design around Iterative and Incremental Development Immediate, visible, verifiable progress Simplifies solution, lowers risk Increase customer satisfaction Procrastinate your estimating to reduce risk, improve Do Just-In-Time Estimating accuracy, and speed up initial estimating Plan at Different Levels Create plans with different levels of details for different audiences. © 2011 Kevin Aguanno. All rights reserved. (C) 2011 Kevin Aguanno. 42 Agile Estimating & Planing Help is Available Agile adoption strategy workshop Agile methodology customization for your organization Agile methodology training (developers) Agile methodology training (managers) Agile health check training for auditors and Ongoing mentoring of agile pilot projects PMO reps © 2011 Kevin Aguanno. All rights reserved. Questions? Kevin Aguanno (your speaker) is available for consultation at [email protected]. He is the author of over 20 books, audiobooks, DVDs, and CD-ROMs related to this subject matter: (C) 2011 Kevin Aguanno. Books: CD-ROMs: Audiobooks: DVDs: 43 Agile Glossary A glossary of commonly-used terms unique to agile projects. The most prominent definition of each term is used, and where there is debate within the agile community on the meaning of these terms, other definitions may be mentioned. Active Customer Participation Regular involvement by the project sponsor or a delegate and possibly key stakeholders in the day-to-day decision making on the project. One of the key principles of agile management methods. Active customer participation provides transparency, improved customer control, improved customer satisfaction, faster decision making,many and faster clarification of requirements. Adaptive Software An agile method that applies agile management techniques Development to earlier rapid application development methods. See http://en.wikipedia.org/wiki/Adaptive_Software_Development. Agile A management philosophy that focuses on delivering value with approaches that are lightweight and responsive to change. Agile Manifesto A statement describing the core agile philosophy. The original signers of the Agile Manifesto were proponents of several agile software development methods, resulting in a software development flavour to how the manifesto was worded; however, the underlying concepts apply across many different management www.agilemanifesto.com. not just software development. See ASD See Adaptive Softwareareas, Development. Backlog A list of items that have still to be completed. There are several types of Backlogs used in agile methods. See Product Backlog, Project Backlog and Iteration Backlog. Backlog Maintenance The process whereby new deliverables/user stories/features are added to the list of work to be potentially completed during a project; this list is called the Project Backlog. (See also Project Backlog and Product Backlog.) Budget Burndown A graph showing the amount of authorized funding (budget) Chart remaining on a project, trended over time. Typically, it is updated once per Iteration to reflect the amount remaining after the actual costs for completed subtracted. Burndown Chart A graph showing thethe changes in a Iteration total that are represents a quantity remaining, trended over time. It starts at an original value (plotted on the vertical axis), and trends to the right, with the goal of reaching zero as it crosses the horizontal axis. Burndown Charts cometoina several types; seethat Budget Burndown Chart,atProduct Burnup Chart A graph similar Burndown Chart trends data starting Burndown Project zero on the left-hand side andChart, trendsand upwards to Burndown the right asChart. the number grows over time. See Burndown Chart. Agile Glossary © 2011 Multi-Media Publications Inc. Page 1 of 11 Chicken Colocation Critical Chain Crystal Methods (Crystal Clear/Orange/Red/etc.) Daily Scrum Defined Method Deterministic Method DSDM A term used in the Scrum method for a project stakeholder who does not have direct control over a project. The contrast for a Chicken is the project sponsor (called Product Owner in Scrum) Moving team members so that they together at one location, whoare is called a Pig. allowing the use of face-to-face communications. See also Onsite Customer. A method of preparing task estimates and project schedules that removes hidden contingencies in task estimates and strategically places a portion of those removed contingencies in specific places on the project schedule. Specific techniques are used for sizing these contingencies (called Buffers) and unique metrics are used http://en.wikipedia.org/wiki/Critical_Chain_Project_Management. for tracking the use of these contingencies (e.g. Buffer Burn A scalable family of iterative incremental Rate). See development methods that provides different levels of formality for projects of varying complexity. The simplest, least-formal method flavour is called teams. teamand size, orfor complexity increases, of CrystalAs Clear is risk, meant lower-risk projects the withlevel small method formality increases, moving through several flavours through Crystal Orange, Crystal Red, etc. See http://alistair.cockburn.us/Crystal+light+methods. A short daily meeting wherein team collaboration and knowledge sharing are encouraged, issues are identified to management, and commitment is reinforced through the asking of three standard questions. The first question (“Did you complete everything you planned on doing yesterday?”) is about the past and is intended to uncover issues within 24 hours of them appearing. The second question (“What are you going to work on today?”) is to facilitate completing work this Iteration?”) is again intended mentoring and your knowledge sharing among team members andtoalso identify issues to the project management within 24 hours of them to reinforce commitment from team members. The last question appearing. The meetings are usually held with participants (“Is there anything going to slow you down or stop you from standing up (i.e. no chairs) which encourages the participants to See Deterministic Method the meeting short. A method that is based upon akeep preparing a detailed forecast of the future (estimates and a plan) and then measuring and managing any variances to that plan in order to get the project “back on plan.”. See Dynamic Systems Development Method. Agile Glossary © 2011 Multi-Media Publications Inc. Page 2 of 11 Dynamic Systems Development Method A method managed by the DSDM Consortium that formalizes earlier Rapid Application Development techniques with a greater focus on the delivery of business value in an iterative, incremental fashion. See www.dsdm.org. Empirical Method A method based upon developing only a high-level plan for the project, getting started, and then monitoring and controlling several variables (such as budget burn rate, quality levels, Velocity, and others) to keep the project’s parameters within tolerance rages. Extreme Programming An agile method foracceptable solution development that focuses mostly on Extreme Project Management FDD Feature-Driven Development Ideal Day IID Increment the technical development work, rather than project management activities. XP was developed concurrently with Scrum, and is most commonly implemented simultaneously where provides the solution development processes. with MoreScrum information Scrum provides the project management processes and XP A term often used asata http://www.extremeprogramming.org/. synonym for “Agile Project Management,” usually when referring the project management processes that need to be in place to manage Extreme Programming projects. See Feature-Driven Development. An agile method that contains both project management processes and some solution development processes. FDD is notable for its significant guidance and structure for Iteration Zero activities. An agile unit of high-level estimating that assesses work effort for a User Story. Compared to Story Points, Ideal Days have a number of drawbacks: key roles may be missed, the work effort associated with some tasks may be missed without preparing a Work Breakdown Structure first, the estimated work effort may not consider the impact of an individual’s skill level or performance, estimates do not typically include the impacts of multi-tasking interruptions, and estimates can degrade in accuracy over time as Development. skill levels improve later in the project lifecycle. See Iterative Incremental A piece ofOverwhelmingly, working/completed new that will be agilefunctionality community prefers estimating in Story added on to an existing base the solution. Points over estimating in Ideal Days. Agile Glossary © 2011 Multi-Media Publications Inc. Page 3 of 11 Incremental Development A classification of solution development methodologies characterized by their up-front prioritization of features and then the building of the features with one Increment being completed every Iteration. One benefit of Iterative Development methods is the ability to deliver business value early as, after several Iterations, the emerging solution may have enough working features to be considered useful for some business purpose. At this point, the project could be terminated, saving time and money, or it could continue adding Increments of functionality until the solution is deemed complete. Another benefit of these methodswill is abe high level into of quality to the ability to put the Iteration A project schedule divided severaldue Iterations wherein work will be performed that will slowly evolve the entire solution riskiest elements in early Iterations so that the design can be over time. Iterations are managed as a Timebox with fixed start validated through a Spike, plus the Regression Testing that and every end dates. Iteration Backlog A list containing all of happens the work (expressed as tasks) that needs to Iteration. be completed during an Iteration. Along with the task name, the Iteration Backlog usually contains a task owner, original effort estimate in hours, and an estimate to complete the task in hours. tasksplan in the effectively Iteration Plan The detailedThe project forIteration the tasksBacklog to be performed by form the the Work Breakdown Structure (WBS) for the Iteration. project team members during an Iteration. Iteration plans are developed at the start of each Iteration and are based on the contents of the Iteration Backlog. A complete iteration plan would include a schedule (perhaps but not necessarily shown as a Gantt Chart), a resource plan, and a financial plan - but only for the specific Iteration. Higher-level project plans, such as a quality plan risk arewhere handled at the Release Iteration Zero The agile termorfor themanagement first projectplan phase important pieces Planning level. before a team proceeds of preparation work are performed through the solution design/build Iterations. Iteration Zero activities include initial high-level requirements gathering, analysis, and prioritization; high-level design; high-level prioritized Project Backlog, thePoints), initial Release Plan, the andinitial perhaps estimating (usually in Story and building the Iteration Plan for the first design/build Release Plan. Outputs of Iteration Zeroiteration include (Iteration the initial #1). Agile Glossary © 2011 Multi-Media Publications Inc. Page 4 of 11 Iterative Development Building a product or service over the course of multiple Iterations, with the goal of performing design activities in early Iterations, constructing in middle Iterations, and quality assurance activities in later Iterations. With Iterative Development, features of the solution are completed across several Iterations. The difference between Iterative Development and Linear Development is that Iterative Development provides opportunities Iterative Incremental An approach for to developing a new product or service that prepares demonstrating in progress Development a high-level design of the entirework solution up front,and the capturing slowly project stakeholder the end of each Iteration. builds that solution feedback over time,atwith functionality being delivered during every Iteration, in order of business priority. Agile methods are Iterative Incremental Development methods, but are lightweight/flexible than other IID methods such as the Kaizen A Japanese more term that comes from Lean management. See Rational Unified Process. Retrospective. Kanban Board A technique derived from Toyota’s implementation of Lean Manufacturing where a signs are used to notify others of the status of a particular production stage. On agile projects, teams often implement this via a “Kanban Board” which is divided into columns, each column referring to the status of a User Story; for example, not started, designing, building, testing, and completed. User Stories, summarized on Story Cards or Post-It Notes, are moved by the team from one column to another as the User Story works its way through the solution design/build process. The Kanban Board gives a very visible way for any stakeholder to Lean Development An agile thatofapplies the basic principles of be lean quickly seemethod the status an Iteration, it candevelopment. also used by manufacturing and applies them toand product the solution development team to signal the next team member in Model Storming A term covering the just-in-time design modeling sessions that agile team members perform throughout the project. In agile the development process that a piece of work is now ready for his projects, detailed solution design is not completed at the start of or her action. the project (see Iteration Zero); rather, only a high-level design is completed, and then during the various Iterations of the project, the team members perform the detailed design activities for the User Stories they are developing on a just-in-time basis - this is Muda A Japanese term that comes from Lean management. See Waste. called Model Storming. Agile Glossary © 2011 Multi-Media Publications Inc. Page 5 of 11 Onsite Customer Agile methods require frequent interaction with the key business stakeholders who give direction to the team, provide clarification on, make decisions on the spot, and immediately escalate issues. In Extreme Programming, this is called Onsite Customer, with the thatand at risk leastmanagement one key business stakeholder is working Pair Programming Aintent quality technique from Extreme the core team members. Programmingcollocated where twowith programmers are sitting at one computer creating software. One writes the software, while the other looks over his or her shoulder to inspect the newly-written code for defects at the time they are created. Another benefit is that the two can brainstorm alternate solutions to problems, gaining the benefits of the knowledge and experience of both programmers, resulting in a better solution. This technique can apply more Pig A term from Scrumtoidentifying a project stakeholderforwho has one could broadly non-programming direct control over aspects of asituations; project. Pigs example, include project team have two designers working together on one design task to ensure members, the project manager (called Scrum Master), and the that the resulting wasThe optimal and of defect sponsor (called Productdesign Owner). opposite a Pigfree. is known Planning Game A method of estimating the Story Points required to complete a as a Chicken. Chicken. User Story. In the Planning Game,See a cross-functional team briefly discusses a User Story with the Product Owner (or delegate) to understand the relative complexity of building the feature. Then, the team members simultaneously turn over cards that have their estimate written on the reverse. By showing their cards simultaneously, the team members avoid the impacts of “group think” - a process whereby a dominant voice (or peer pressure) sways meeker team members into providing the estimate favoured by the dominant members of the group. Using the Planning Game, the voices of dominant team members are allotted equal weight as those of other team members, allowing a brief discussion to ensue to better understand outlying (higher or lower than average) estimates. Once the team has discussed the reasons behind the outlying estimates, the team members once again each turn over a card that reflects their possibly-revised estimate. Over the course of a few estimating rounds, the team will likely converge on a common estimate. Another benefit to the Planning Game isInc. the group bonding and improved cross-functional Agile Glossary © 2011 Multi-Media Publications Page 6 of 11 knowledge sharing that can take place during the discussions of Product Backlog Product Owner Project Backlog A list of all possible features that could be included in a product over the course of its lifecycle. The Product Backlog may be divided into a number of product versions, each of which will constitute a project and each of which will have its own Project Backlog. The Product Backlog is usually owned and maintained by a strategic business unit such as marketing or product A term fromdevelopment. the Scrum method for the business person The Product Backlog used toinbuild strategic responsible for delivering value via theisproject exchange for a product detailing theThis product lifecycle. monetary and roadmaps resource investment. person may also be known as the project sponsor. In some projects, the Product Owner may delegate day-to-day project interaction and decisions to another business as a business A list of solution features andresource other keysuch deliverables that analyst remain or subject to be completed on thematter project. At a minimum, the Project expert. Backlog contains a list of the features and other deliverables to be created during the project, listed in priority sequence, along with a size estimate for each, usually expressed in Story Points. The Project Backlog is owned by the business sponsor (Product Owner). Both internal (the core project team) and external stakeholders (Chickens) can add items to the Project Backlog as they are uncovered during the project. The business sponsor will then be responsible for inserting the new items into the Project Backlog at the appropriate level of priority, with some guidance from the core project team (so that dependencies between features are respected). The Project Backlog gets updated frequently throughout the project using the Backlog Maintenance process. In Project Burndown A line graph showing a trend line for the total number of Story the Scrum Backlog is oftenThis called the Chart Points remaining withinmethod, a projectthe asProject it changes over time. total“Product number Backlog” of points remaining from the Project Backlog. though thiscomes is often confusing given the The vertical axis reflects the total number of points of work alternate meaning of Product Backlog described in this document. remaining to be completed, while the horizontal axis is divided The alternate meaning in this document is the newly-emerging, into the Iteration planned for themeaning. project. The slope of the trend preferred line, if extended to the right, will show the number of required iterations to complete all of the scope on the Project Backlog, where it crosses the x axis. In the Scrum method, this graph is often called the “Product Burndown Chart” but emerging usage tries to eliminate confusion by deprecating thisPage alternate name. Agile Glossary © 2011 Multi-Media Publications Inc. 7 of 11 Refactoring Over time, multiple changes to a component to accommodate new User Stories/features can lead to a sloppy implementation of the component. This can lead to poor solution performance, or a design that is so convoluted that it makes it difficult to understand, maintain, or to extend with new functionality. Refactoring is the process whereby sloppy solution components Regression Testing Retestingare portions of a solutiontothat were already tested inand earlier laterRegression restructured make them moreonefficient Iterations. testing is important agile projects, understandable. where designs emerge over time, and that changes made in later Iterations may impact solution components built in earlier Release A planning construct that includes one or more Iterations. Iterations. Generally, Iterations build small increments of functionality into a solution and there is often little justification of deploying the output of each Iteration to the extended business stakeholder community. Releases are a way of recognizing that, while the business still reviews an end-of-iteration demonstration of the work completed in each Iteration in order to assess progress and provide feedback, there still needs to be a critical mass of functionality created before the business would go through the cost of and effort required to deploy it; for therefore, a Release is a Release Plan The equivalent a high-level project schedule agile projects. The Release Plan contains a view ofenough the overall timeline for of the grouping of Iterations that includes functionality the project, showing key milestones, the start and end dates for business to achieve some value in taking on the costs of bothering Releases, andit.the start and endconsist dates of forone each Release to deploy A project will orIteration. more Releases. Plans also list the User Stories/features to be delivered during each Iteration. The Release Plan gets updated at the start of each Retrospective A continuous improvement activity performed at the of an and any Iteration to learned reflect actual productivity (seeend Velocity) Iteration where lessons are captured for immediate changed project scope or prioritization. application in the upcoming Iteration. Running Tested A measurement used in Extreme Programming to track the Features growing “completeness” of a solution as it evolves over many Iterations. Scrum An agile method developed by Jeff Sutherland with later contributions by Ken Schwaber. Scrum is an agile method that focuses on project management processes rather than solution development processes. It is the most common agile method. Scrum Master The Scrum term for a project manager. Agile Glossary © 2011 Multi-Media Publications Inc. Page 8 of 11 Spike Sprint Sprint Backlog Sprint Burndown Stand-Up Meeting Story Story Card Story Point A functional test or proof of concept that assesses whether a solution design approach is feasible. A spike requires detailed design of one simple transaction or message (possibly an artificial transaction used just to perform the spike) that tests whether overall design decisions are valid and whether the selected approach is possible. Spikes often travel through many interconnected components, testing the interfaces between the components and how the system will behave as a whole. Spikes See Iteration. are not used to build required functional components of the See Iterationsolution; Backlog. rather, they are used only to gather data to make design See Burndown Chart. decisions or to validate whether prior decisions were correct. See Daily Scrum. See User Story. An index card (or Post-ItTM Note) used to capture User Stories during planning sessions. Story Cards contain a brief summary of a User Story (usually expressed in a sentence or even just a few words), the estimate of the story’s complexity (usually in Story Points), the story’s priority, and any notable information about the story that emerged during stakeholder discussions. Story Cards are a low-tech for documenting User Stories that allows A unit of measure for themethod complexity of completing a User Story. stakeholders rapidly and prioritize the stories moving Story Points to include thegroup following factors: work effort,by technical the cards around on a table or when posted on a wall. risk, resource constraints, business risk, requirements instability, stakeholder commitment, and others. Story Points are the preferred unit of measure for estimating User Stories as they have many advantages over other alternatives such as Ideal Days. Agile Glossary © 2011 Multi-Media Publications Inc. Page 9 of 11 Test-Driven Development Timebox User Story Velocity Waste An agile management practice for quality management. There are two different aspects to Test-Driven Development, one that affects solution designers and one that affects solution builders. For the former, customer acceptance criteria are gathered for each User Story at the time the story is documented, and these acceptance criteria are passed on to the solution designers; to achieve a high level of efficiency, the designers, in turn, will use these acceptance criteria as illustrations of requirements, designing a solution that satisfies the acceptance criteria, but no more than that. Solution builders will take these same acceptance criteria and turn them into test cases, which get written before the solution satisfying those acceptance criteria isand built. These same A fixed period of time in which work will be scheduled test cases are used to verify whether the solution meets the performed. If the forecast duration of the work exceeds the original customer’s to ensure the solution passes Timebox length,expectations, then work needs to bethat removed from the easily through acceptance testing at the end of the project, and Timebox or resources need to be added to complete the work to A way of documenting awithin feature of given a solution that meets a help optimize the project delivery. time. See Iteration. business requirement.the Generally, User Stories reflect steps within a larger business transaction workflow (often defined in a Use Case) and can be documented on Story Cards, among other A measure of the amountUser of work completedupduring Iteration. Stories onnumber thean Project Backlog. It ismethods. usually expressed as anshow absolute of points or ideal days. Alternately, it can also be expressed as a percentage showing the ratio between the number of points completed versus the number of points planned for a given Iteration. Velocity can be a measure of actual performance (historical Velocity) or (forecast Velocity Any task onpredicted a project performance that uses resources butVelocity). which does not is used to translate Project Backlog Release is Plan, to assess a team’s createabusiness value forinto the acustomer considered Waste. Features that are not completed during an iteration are often performance, and to the accuracy of a team’s estimates. thought of as waste, asassess they consumed resources but did not make it into the customer deliverables, which means that they are (as of yet) creating no business value. Waste also includes items that delay the project, features added above the optimal number for maximizing the business case/delivery of value, and misunderstanding requirements (also known as “building the wrong thing.”) Agile Glossary © 2011 Multi-Media Publications Inc. Page 10 of 11 Whole Team XP An agile concept whereby a holistic team, representing all required roles, works together to perform planning, design, estimating, and similar activities. By working together across job functions, the team members can better collaborate, the project can benefit from the knowledge and experience from all of the roles, and the team can build closer working relationships See Extremeproject Programming. across an organization’s functional boundaries. Agile Glossary © 2011 Multi-Media Publications Inc. Page 11 of 11 Kevin Aguanno PMP, IPMA-B, MAPM, Cert.APM Certified Executive Project Management Strategy Consultant Specialist in Adoption of Agile Management Methods Phone: (416) 540-8570 / Fax: (905) 986-5777 Web: www.AgilePM.com / Email: [email protected] PM Consulting Offerings Project KickStartTM - Getting a project started in the right direction is a big contributor to project success. Tis offering will help teams new to project management or the project approach and plans will help those reducewith the large, risk ofcomplex project projects, where an independent review of Don’t Forget PM Training! failure and identify additional efficiencies. Kevin Aguanno is an award-winning trainProject HealthCheckTM - When things don’t appear to be going er and university instructor with courses well, an outside expert assessment will identify what you’re doing on the following PMDevelopment topics: • Introduction to Systems well, and what could be improved. Trough interviewing stakeLifecycles (SDLCs): Waterfall to Agile holders, team members, the project sponsor and the project manag• Introduction to Recovering Troubled er—in addition to reviewing key project documents—this offering Projects Troubled Project Despite ourproject. best-laid plans, someassessesRecovery the health of- an in-flight • Project Scheduling from Traditional to times projects get mired in technical, management or personnel isExtreme sues and needless bureaucracy. Let us help you with our expertise in • Earned Value Management, Metrics and quickly assessing the situation and making the necessary changes to Financial Controls • Project Closeout Best Practices get a project back on track. Individual PM Competence Assessments - Tap into years of ex• Rewarding Team Members to Improve perience assessing project managers of all experience levels to meaProject Performance sure their competence against international standards. We provide • Project Risk Management individualized recommendations for skills development and project • Fundamentals of Project Management management career planning—a great reward for your star perform• IPMA Level-D Exam Preparation Project Management/SDLC ers. Methodology Consulting - Over time, our standard project governance and delivery processes tend to get inefficient as new elements get added to prevent the reoccurrence of past failed projects. Eventually, productivity suffers as all projects become burdened with needless bureaucracy. Let us help you identify the right methodologies for your projects, and then help you adapt them to match your individualized business environment, smoothing the transition to the new methods with phased adoption roadmaps. We can also help improve existing methodologies with incremental changes to improve project efficiency while still preserving necessary project oversight. Agile Consulting Offerings Agile Project KickStartTM - Scrum and other agile methods tell us how to efficiently execute highly-complex or high-change projects; however, most fail to give guidance on how to effectively steer a project through the various stages of pre-initiation reviews and funding approvals. Tis offering helps you estimate an agile project business case and plan your agile project at the right level of detail to get it through your project fundingAgile approval process, while still maintaining a quick, lightweight Contract Review - Once your agile project’s businessapproach. case is Get Agile Training Also Available approved, you’ll need to get some form of help agreement in place befrom an expert in making agile work in large enterprises. tween the business sponsor and the delivery team. Tis might be a Kevin Aguanno is an award-winning formal contract between two companies, or it may be a less formal trainer and university instructor with the document of understanding (DOU) between two departments in following agile courses available as public the same organization. Tis offering gets you expert help to build or private sessions. Prepare to write the your agile contract—either time and materials or fixed price—to PMAC’s Certified Agile Project Manager • Introduction to Agile Project Manageminimize your risk while still giving the sponsor the flexibility deexam or the newment PMI agile exam. Agile Project HealthCheckTM - Agile projects use different metsired from an agile approach. rics and reporting techniques than traditional project management • Agile PM Upgrade for ScrumMasters approaches. As a result, PMOs and risk managers have a difficult • ScrumMaster Bootcamp time assessing whether an agile project is healthy or if there are early • Agile Estimating and Planning warning signs that it is getting into trouble. Tis offering brings in • Agile Bootcamp for Project Sponsors, Product Owners and Business Analysts an expert assessor to review your agile project and let you know if Organizational Agile Readiness Assessment Considering a move • Conducting an Agile Project Health your project is agile... or fragile. Check: New Perspectives for PMOs, to agile? If so, you should know what challenges to expect—specific Risk Managers, and Auditors to your organization—and what to do about them. Get help from • Advanced Agile Management Techa top industry expert in enterprise agile adoption as he assesses your niques personnel, your processes, your support systems and tools, and your governance structure to see how ready is your organization. Te final Agile - Transitioning to agile requires significant changes in your report includes findings and andAdoption recommendedStrategy improvements. management processes and metrics, your project delivery processes, and how your team members work together. Most organizations face serious challenges—some quite significant—when adopting agile methods. Why reinvent the wheel where others have already gone before you. Have one of the top industry experts on agile transformations Agile help Methodology Consulting - Having trouble adapting agileyour methods you develop a customized, phased, agile adoption strategy for group.to your unique company circumstances or to your individual project? Get help from an agile methodology guru who can assist you with incorporating individual agile techniques or tailoring a whole agile method. Phone: (416) 540-8570 / Fax: (905) 986-5777 / Web: www.AgilePM.com / Email: [email protected] Managing Agile Projects, First Edition by Kevin Aguanno (ed) Multi-Media Publications Inc.. (c) 2004. Copying Prohibited. Reprinted for Jayalakshmi L, Cognizant Technology Solutions [email protected] Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. Managing Agile Projects, First Edition Chapter 11: Requirements Documents that Win the Race Kirstin Kohler Time-constrained projects ask for requirements approaches that are agile: that is, adapted to the project needs and without comprehensive documentation. But how can Barbara Paech this be achieved? Our approach provides the steps toward the solution of this question. It supports the identification of the essential content of the requirements document as well as the selection of the appropriate modeling technique. The essential content is determined by conducting a systematic risk analysis, which allows identifying the most important elements of the requirements documentation. For the requirement document to be useful, it must be precise and understandable for all project participants. The appropriate modeling technique is selected by taking the identified content and the context of the project into account. This chapter reports work in progress. It describes the motivation, related work and first ideas. Introduction It is well known and widely accepted that a lot of problems in software development are caused by deficiencies in the requirements phase. [20] Nevertheless, a lot of companies lack requirements engineering activities. [17] Especially in projects where time-to-market is critical to success, there is usually not enough time for investments in the requirements engineering process. [16] In order to overcome this resistance against requirements engineering in industrial settings, it is not necessary to invent a new and hopefully better method. Instead, one should focus on making existing methods more attractive. [22] The goal of our work is to make documentation of requirements more attractive for time-to-market projects. Creating and maintaining requirements documents requires substantial effort. [19] This is why it is often neglected, especially when schedules are tight. Whereas Extreme Programming puts the onsite customer on a project, and thereby reduces most kinds of documentation, [5] our experience in industrial projects shows that documentation of requirements is crucial for the transfer of knowledge between stakeholders of the actual project as well as to subsequent development projects. Thus, it cannot be completely disregarded. With our approach, we want to balance the divergent goals of creating good documentation and keeping a tight schedule. Our slogan is "keep the documentation as small as possible but as substantial and useful as needed for the project." Our approach gives advice on how to put this slogan into practice. It supports the following two steps: (1) identify the essential part of the documentation, and (2) choose the appropriate modeling technique to document them. We reflect the project context [23] in both of these steps, especially in the definition of "essential" and "appropriate". With our work, we do not invent a new requirements engineering method, but rather provide[20] guidance van Lamsweerde, on how to use A. "Requirements existing methods Engineering efficiently. So in the far Year we have 00: A limited Research the framework Perspective." according Proc. 22nd to twoInternational dimensions: Conference (1) it supports ononly documentation of requirements, (2) it considers only GUI-intensive systems. Softwareand Engineering, Ireland, June 2000. [17]Morris, P., Masera, M., and Wilikens, M. "Requirements Engineering and Industrial Uptake." Requirements Engineering. 3, 1998. [16]Mead, N. R. "Why Is It so Difficult to Introduce Requirements Engineering Research Results into Mainstream Requirements Engineering Practice?" Proc. Fourth International Conference on Requirements Engineering. Illinois, June 2000. [22]Wiegers, K.E. "Read My Lips: No New Models!" IEEE Software. September/October 1998. [19]van Schouwen A.J., Parnas, D. L., and Madey J. "Documentation of Requirements for Computer Systems." Proc. IEEE International Symposium On Requirements Engineering, San Diego, California, 1993. [5]Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000. [23]With context we mean important factors influencing the software project. Basic Steps of the Approach In order to document requirements for time to market projects, it is important to make a trade off between quality and schedule. Gaps or faults in the requirements phase, as a consequence of missing documentation, lead to dissatisfied customers due to quality problems in the end product. In contrast, "high quality" software development including comprehensive documentation takes longer, so customers often choose competing products. The product is of less value due to an unsatisfying market penetration. Narrowing these conflicting dependencies to the scope of requirements documentation means making the tradeoff between no documentation leading to bad quality and complete documentation leading to delayed product delivery. The solution is to keep the documentation as small as possible but as substantial and useful as needed for the project. We accomplish this by supporting the two steps "Identify essential content" (ensures small and substantial) and "Choose appropriate modeling technique" (ensures useful). Figure 11-1 shows the two basic steps of our framework in relationship to the basic ingredients: the project risk, conceptual information model, the project context, and the modeling technique. How these ingredients are integrated in our approach is described in the following subsections, where the steps are Page 2 / 9 elaborated in more detail. Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Figure 11-1: Steps and concepts of the approach. Identify Essential Content The basic idea is not to document the complete requirements, but instead concentrate on the most important or essential parts. Finding and separating these essential parts poses a classical filtering problem: separating the requirements that are worth being documented from those that are not critical and need not be documented. In general, a filter separates material or waves according to specific characteristics like grain size or frequency. The materials in our case are the requirements, and we use a conceptual information model to classify the requirements. The filter in our approach separates requirements according to risk. It separates those requirements that are accompanied with a high risk from those that are accompanied with a low risk. The size of the risk (comparable to the size of grains passing the filter) is influenced by the project context. We provide an approach for assessing the risk by considering different risk types, as shown later in this chapter. The next step is to document the requirements; therefore, one has to choose a Requirements documents are a medium of communication and knowledge transfer. In order to gain the most benefit out of them, they have to be precise and representation technique. understandable for project participants and involved stakeholders (besides other qualities like correctness, consistency, and so on). Choosing the appropriate modeling Choose Modeling Technique. technique is essential. The modeling technique has to fit to the contentthe thatAppropriate is documented, as well as to the people who will read the document. For example, the navigation of dialogues can be documented by using Constantine's abstract prototypes, [9] whereas the interaction between system and users in terms of function calls might be documented by use cases. [7] Depending on the individual project team members (who might include graphic designers, for example) specification languages like UML might not be suitable. This means that, when deciding about the appropriate modeling language, the content as well as the project context have to be considered in order to make the documentation valuable. Later in this chapter, we will describe how The arrow leading back to the start in Figure 11-1 indicates thatcontext our approach not limited to waterfall projects wherein all requirements are known at the the project guides is the selection of classical the modeling technique. beginning. The technique should be applied in iterative projects too. It can be applied independent of the process model of the project, and fits at the point where one has roughly understood the requirements (or a subset of them) and has to document them in more detail. Our approach helps to decide which part of these to document and how to document them. [9]Constantine, L., Lockwood, L. Software Forrequirements Use. Boston: Addison Wesley, 1999. [7]Cockburn, A. Writing Effective Use Cases. Boston: Addison Wesley, 2001. Identify the Essential Documentation Content We elaborate on the step of identifying the essential documentation content by explaining the three concepts we have built on: the conceptual information model, the project risk, projectWhat context. Before filtering the essential requirements, we have to make explicit what weand arethe filtering. is the totality of requirements we are choosing from? To improve the understanding of a complex subject, physicists and chemists usually introduce models to help with representation. We Page 3 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition needed a similar model that allows us to think and argue about requirements, especially in the context of the filtering process. Unfortunately, however, there is not a standard model for GUI-intensive applications comparable to the Parnas' model for embedded systems [19] (at least we are not aware of one after an extensive literature search). Thus, we developed our own conceptual information model for GUI-intensive applications. Conceptual Information Model The conceptual information model describes the various elements and abstraction levels for requirements of interactive applications (excluding non-functional requirements). The model is based on Kovitz' understanding [13] that requirements activities lead to design decisions. During the requirements phase, decisions about the effect generated by the software to be developed are made. For interactive applications we identified 12 types of these "design decisions" (see Figure 11-2). Figure 11-2: Conceptual information model consisting of 12 types of design decisions. These can be categorized into 4 groups (decisions about tasks to be supported by the software, decisions about functions implemented by the software, decisions about the application kernel, and decisions about the user interface). Each of these groups is on a different abstraction level. For the sake of brevity, we will not go in the details of this model, but rather we will refer the reader to Kohler and Paech. [11] The elements of the model allow us to argue on a conceptual level about different types of requirements. Therefore, one can explicitly name which type of the requirements should or need not be documented. As a simple example, if a new interface for an existing legacy system has to be implemented, it is important to specify the dialogs and navigation of the user interface, whereas the documentation of the application kernel requirements is less important. The 12 elements in this model form a tree, in the sense that the elements of lower levels depend on the decisions made before. The decision to support "the task of book ordering" leads to specific dialogs and functions like a "dialog to confirm selection" and "a function to calculate invoice." The tasks span a tree of dependent decisions. The set of all "tasks" to be supported builds a set of trees as illustrated in Figure 11-3. Each triangle in the picture represents one "task tree". This does not mean that the decision to document a lower level requirement implies that the corresponding higher-level requirement must be documented. It must only be clear which tasks a specific functional requirement belongs to. Figure 11-3: Set of task trees. Dots indicate the design decisions of Figure 11-2. It is so far an open question of how to identify the essential tasks, and which ones should be documented at all. Page 4 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Now we come back to the filtering process. Similar to testing of time-constrained projects, [3] we use the concept of risk analysis to guide the selection of the essential requirements. Risk We define risk as the possibility of suffering a loss. [10] This means that to asses the risk, we have to know the probability and the loss linked with the risk. We base our risk analysis on a method introduced by Kontios [12] who defined an effect chain consisting of risk factor, risk event, risk outcome, risk effect, and utility loss (see Figure 11-4, left side). Without going into the details of Kontios' method, we explain the elements in the context of the requirements documentation (see Figure 11-4, right side). Figure 11-4: Kontios' risk effect chain instantiated for the requirements documentation. The risk event in our example is the missing documentation of requirements concerning the user interface (the design decisions we explicitly decide not to document). Missing documentation of user interface requirements can cause misunderstandings, which lead to wrong, superfluous, or missing navigation and dialogs in the software (risk outcomes). To judge the extent of the risk event and outcome, one has to investigate which risk factors make the event likely (for example, on a distributed team, the probability [24] to cause a misunderstanding due to missing documentation is high) and which risk effects cause a high damage (for example, a late product delivery due to superfluous functionality that might result in a missed window of opportunity and a loss of market share). The project context is essential for both of these questions. The project context defines the risk factors and therefore the probability that the risk event happens. And the project goals that are also defined through the context define the risk effects caused by the risk (the utility loss). Therefore, the risk analysis can be n What factors of the project context increase the probability of a misunderstanding? reduced to the questions: n What project goals increase the utility loss caused by a misunderstanding? The reflections about risk can be transferred to our conceptual information model. For each of the 12 elements of the model one has to consider which context factors enlarge the risk that a missing requirement of this type leads to a misunderstanding. But before this can be done, we have to define how to describe the context. How can one be sure to consider all relevant factors? Project Context The problem of context description gained importance within the last years in the domain of knowledge engineering, and constructing experience factories for software projects. [4] But due to the fact that this is a young research community, and the relevant factors pretty much depend on the usage of the packaged experience, there is no silver bullet of context description. We used a scheme proposed by Birk [6] and adapted it to our needs in requirement engineering. Table 11-1 contains all factors to consider for a project characterization. Table 11-1: Attributes for the context description. Reprinted for CTS/316124, Cognizant Technology Solutions Page 5 / 9 MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition Attribute Number Experience Roles Customer Suppliers Distribution of stakeholders Availability of stakeholders Application domain Lifecycle & history Type of product System size Lifetime of the product Architecture Product quality goal Business goals Development process Techniques Tools Standards Weighting of activities Duration of the project Work products Example Stakeholders Number of people in the development team Experience in OO technologies Requirements engineer, user interface developer, graphic designer, etc. Development for customer X Usage of COTS products Requirements engineers and developers at the same location, or a distributed development team People that developed the former product version left the company. User access. Product Web system, embedded system Reimplementation of an existing product. Maintenance. Consumer product 20 components. 100 KLOC. The product has to be supported until the end of 2010 Client/Server architecture Goals Reliability is more important than usability Time-to-market is more important than usability Process/Technology Iterative development. RUP. Onsite customer interviews for elicitation of requirements. Prototyping of user interfaces. DOORS to manage requirements Documentation of requirements according to standard IEEE 1233-1998 30% of the total development effort is spent on the requirements phase The development of the project will be finished within one year Test cases have to be documented With the information model, the risk analysis, and the attributes of a project context description, we have now all tools at hand to support the filtering of essential requirements. A risk analysis of a given project can be conducted by combining the elements of our information model with the various attributes of the project context. For each project attribute, one has to determine the effect and the probability of a misunderstanding caused by missing documentation. Our approach supports practitioners not only by guiding them to the risk analysis. In addition, we provide a set of heuristics. By conducting the risk analysis on a generic level (without considering a specific project context) and limited to the four main groups of elements in our information model (tasks, system functions, application kernel, user interface) we identified generic heuristics for the selection of documentation content. They are listed in Table 11-2. Risk Event Missing documentation of tasks Rick Factor That Enlarges The Probability Rick Effect That Enlarges the Damage Table 11-2: Heuristics for the risk effect Business chain. Goals: Tasks to be supported by the software are critical to the Lifecycle and History: Big changes from "as-is" to "to-be" tasks. business' success. Type of Product: Consumer product with a large variety of different users. Complex user tasks to be supported by the software. Missing documentation of functions Missing documentation of application kernel Missing documentation of user interface Suppliers: Parts of the system have to be built by COTS products. Evaluation of COTS products is based upon system functions. Experience: Developers are not experienced in the algorithms. Lifecycle and History: No experience of how users will react since this is a new development Business Goal: Time-to-market is important and forces us to buy COTS products to hit a window of opportunity. Product Quality Goal: The accuracy of the product has to be improved to increase market share. Product Quality Goal: Usability of the product is required due to mass production and associated high support costs otherwise. Business Goals: Usability is important to reduce costs for training and support. The left hand column lists the risk event. We listed one risk event for each decision type: tasks, function, application kernel, user interface. The second column contains context attributes (risk factors) that enlarge the probability of the risk event. For example, a big change from "as-is" to Page 6 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition "to-be" tasks (risk factor) will increase the probability that a missing documentation of tasks causes damage is high. The right column contains risk effects and their related product and business goals (given by the project context). They define the size of the damage caused by the risk. For example, if time is critical for the business success of the company (risk effect) damage caused by the risk event "missing documentation of tasks" is high. If, for a given project, more than one attribute in a row matches, the risk of omitting this type of requirements in the documentation is high. If either the risk factor or the risk effect is high, the situation has to be judged individually. In that case, Table 11-2 gives a hint for a potential risk. Our tables help in executing the risk analysis; however, this risk analysis still requires some extra effort. The identification of essential requirements is necessary for [13]Kovitz, project managers to focus development efforts. We strongly believe that anand explicit riskGreenwich: analysis isManning the best compromise "all or nothing." B.L. Practical Software Requirements. A Manual of Content Style. Publications between Co., 1998. [11]Kohler, K. and Paech, B. "Task-driven Requirements in object-oriented Development." Perspectives on Requirements Engineering. Eds. J. Leite and J. Doorn. Kluwer Academic Publishers, 2003. [3]Bach, J., "Heuristic Risk-Based Testing." SoftwareTesting and Quality Engineering Magazine. 11,1999. [10]Dorofee, A. J., Walker, J., et al. Continuous Risk Management Guidebook. Pittsburgh, PA: Software Engineering Institute, 1996. [12]Kontio, J. "The Riskit Method for Software Risk Management, version 1.00, CS-TR-3782." Computer Science Technical Reports. College Park, MD: University of Maryland, 1997. [24]Note that for now we do not propose to denote probabilities by number. [4]Basili, V., Caldiera, G., and Rombach, H. "Experience Factory." Encyclopaedia of Software Engineering. Vol. 1. John Wiley & Sons, 1994. [6]Birk, A. "A Knowledge Management Infrastructure for Systematic Improvements in Software Engineering." PhD Theses in Experimental Software Engineering. Vol. 3. Fraunhofer IRB Verlag, 2001. Choose the Appropriate Modeling Technique After having decided what to document, it is now a question of how to document. There is a large variety of modeling techniques available, ranging from natural language to formal languages like Z. [18] One has to choose the modeling technique that fits best for representing the requirements. It has to fit the content that is documented, as well as to the people who will read the document. n ACRE [15] is a framework containing 12 methods for requirements acquisition that are judged by the authors according to their suitability During the last few years, a variety of methodologies have emerged that aim to guide the selection of technologies or methods: in different projects. The framework is limited to the 12 methods, and does not cover modeling techniques for documentation. Furthermore, there is a limited number of project characteristics covered by the framework; for example, the characteristics do not consider the needs of specific applications like interactive or embedded As part of the PROFES project [6] the concept of PPDs (Product-Process-Dependency-Models) was developed. PPDs describe the impact of a specific n systems. technology (like inspections) on a specific product quality goal (like reliability) when applied to a certain process. PPDs also contain a description of the context. Although this approach seems to be very promising, it is very generic because it is suitable for all kinds of software engineering techniques and not especially tailored for our purpose of requirements [8] documentation. He proposes to choose the appropriate development approach n In Agile Software Development, Cockburn brought up the concept of the Crystal Family. dependent on the three characteristics: number of people, criticality of the software, and project priority. We believe that this approach does not consider enough project characteristics. We propose a two-fold approach for the selection of the appropriate modeling language. As illustrated in Figure 11-5, we assume the existence of a repository containing a characterization and description of all available requirements engineering modeling techniques. By specifying the essential content in terms of its design decision types, and by specifying the project context, the appropriate modeling technique can be determined. We will elaborate on this by referring to the underlying concepts: the decision types, and the project context description: n By defining the essential content, one already has selected a subset of decision types, as defined in the conceptual information model. The type of decisions determines a subset of suitable modeling techniques because not every modeling technique is suitable to describe all types of design decisions. Kohler and Paech [11] provide a tabular overview of models used in common processes, like RUP [2] or Usage Centered Design, [9] to document design decision types. Typically, after this selection process, there is still more than one modeling technique left to choose from. Figure 11-6 illustrates this with an example. Based on the decision type "user interface," three techniques (use-cases, storyboards, and abstract prototypes) are selected by function S1, which represents the selection based on the decision type. Page 7 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions n To further narrow down the appropriate modeling technique, the project context should then be Publications considered.Inc., TheKevin output of function S1, MultiMedia Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition together with the project context, are inputs for a second selection function, S2. In S2, for each of the specified techniques, the project context attributes are compared to the attributes of the technique description. The technique with the best match is the result of this final selection mechanism. In the example of Figure 11-6, the project is characterized by a distributed team consisting of software engineers. Therefore, use cases are selected as an appropriate modeling technique. Storyboards require special drawing skills and are more difficult to exchange and discuss between different development sites. Figure 11-5: A repository of requirements engineering techniques for the selection of the appropriate modeling technique. Figure 11-6: Selection of the modeling technique based on decision type and context. The context attributes describing the stakeholders and the process and technology (compare with Table 11-1) support this part of the selection process. Most important of these context attributes are the stakeholders. Their experience with special modeling techniques and their individual roles (testers, graphic designers, etc.) have a very high impact on the acceptance of the modeling technique. This is supported by empirical findings from McPhee and Eberlein [14] who showed that the usefulness of requirements engineering techniques is correlated with the familiarity of stakeholders with that technique. In addition other "non-requirements engineering" tools and techniques that are already established in the process may influence the selection process. For example, if UML class diagrams are in use to document the systems design, one should also use them to document the input/output data of the user interface. So far, our approach of choosing the appropriate modeling technique consists of initial concepts. This is especially true when considering the relationship between context [18] Potter, B., and Sinclair, J. Formal Specification and Z. London: Prentice Hall, 1996. attributes and the selection of the modeling technique. This challenge needs further investigation. [15]Maiden, N., and Rugg, G. "ACRE: Selecting Methods For Requirements Acquisition." Software Engineering Journal. May, 1996. [8]Cockburn, A. Agile Software Development. Boston: Addison Wesley, 2002. [2]Armour, F., Miller, G. Advanced Use Case Modelling, Boston: Addison Wesley, 2000. [14]McPhee, Ch., and Eberlein, A. "Requirements Engineering for Time-to-Market Projects." Proc. 9th Conference and Workshop on the Engineering of Computer-based Systems. ECBS, Sweden, 2002. Summary and Future Work Our approach fits the recommendations for documentation of agile software development given by Cockburn [8] who states "Don't ask for Page 8 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited Managing Agile Projects, First Edition requirements to be perfect" and" Capture just enough." Whereas Cockburn does not give any advice for how to find out what is "enough," we give concrete guidance on the selection process of critical elements. In addition, it substantiates the demand for adaptiveness as postulated by the agile community. [1] In that sense, we make the "agile requirements process" more concrete. Therefore, we built our approach on two practices: the systematic consideration of risk, and the consideration of the project context to drive the documentation in time-constraint projects. So far, we have provided the skeleton that is now ready to be fleshed out with more details [21] to guide practitioners in their requirements engineering processes. Our We want to validate the context attributes through expert similarly toon Vegas who validated n future interviews, work will concentrate the following topics: a characterization schema for testing techniques. By doing this, we will further adapt our characterization scheme for the needs of requirements engineering. n n n We want to provide more heuristics similar to those listed in Table 11-2. They should not only support the risk analysis for the selection of decision types, but also for the selection of a subset of task trees as illustrated in Figure 11-3 to determine which tasks must be documented and which can be omitted. During future projects, by collecting empirical data to investigate the dependency between project context characterization, the selection of the content, and the selection of a modeling language. We want to better understand the relationship between context attributes and the choices that have to be made based on these attributes. Knowing these dependencies would be a first step to automatically support the selection process. [1]And of course we want to evaluate the complete approach to empirically prove, that our approach is beneficial for the requirements phase of time-constrained projects. <http://www.agilealliance.org>. [21]Vegas, S., "Characterization Schema for Selecting Software Testing Techniques." Thesis. Madrid: Universidad Prolitecnica de , February 2002. Page 9 / 9 Reprinted for CTS/316124, Cognizant Technology Solutions MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited