Successfully reported this slideshow.
Your SlideShare is downloading. ×

Process Flow and Narrative for Agile+PPM

Loading in …3

Check these out next

1 of 36 Ad

More Related Content

Slideshows for you (20)

Similar to Process Flow and Narrative for Agile+PPM (20)


More from Glen Alleman (20)

Recently uploaded (20)


Process Flow and Narrative for Agile+PPM

  1. 1. PROGRAM MANAGEMENT PROCESS FLOW Providing Actionable Information to the Decision Maker using Earned Value Management Integrated with Agile Software Development performed in Rally For developing ROM, planning the Product and Sprint Backlogs, executing and statusing the Sprint, and informing the Earned Value Management Systems, using Physical Percent Complete of progress to plan.
  2. 2. 2 Top Level Agile Project Management Process Flow .............................................................4 Building ROM and Placing Features on Product Backlog......................................................6 Develop Product Roadmap for Features ..............................................................................8 Develop Engineering Estimate............................................................................................10 Perform Sprint Planning ready for Sprint Execution...........................................................12 Data needed in Rally for Status Reporting..........................................................................14 Sprint Execution..................................................................................................................16 Status Completion of Scrum Sprint and Completion of Feature(s).....................................18 Measuring Performance of Kanban Project Work..............................................................20 Exporting Feature Data from Rally to Cobra.......................................................................22 Calculating Physical Percent Complete for Feature............................................................23 Measuring Performance on Kanban Development ............................................................26 Integration of Agile with Earned Value Management System............................................28 Glossary ..............................................................................................................................32
  3. 3. 3 Prerequisites and Assumptions for Agile on Performance Measured Programs § Adding Agile to a Program Performance Management (PPMS) is our starting point. Not the other way around. If an Agile program has no need for Earned Value Management, then the methods of measuring progress to plan for the Agile Program are already contained in the Agile Software Development Method ‒ Scrum, XP, DSDM, Crystal ‒ all have methods of measuring progress to plan. § Work planning on an Agile Program starts with a prioritization of the Business Value defined by the customer in the form of Capabilities. This planning focuses on the value in units of Effectiveness, Performance, Key Performance Parameters, and Technical Performance Measures in compliance with the Concept of Operations (ConOps), Statement of Work (SOW), Statement of Objectives (SOO), or other mission or business definition documents. § The Product Roadmap is the top level planning activity that can precede or inform development activities for the IMP, IMS, and PMB. During Product Planning, the Product Owner (PO) and customer representative refer to contractual and product performance requirements to specify and prioritize the set of system capabilities, or Epics/Capabilities, needed to deliver the contractually required system. Capabilities are then assigned to one or more Cadence Releases, thus forming the Product Roadmap. § Product Planning, starting with Contract Award, establishes the Cadence Release cycle, Product Roadmap, and Product Backlog. Product planning is performed throughout the life of the program to refine and update the Product Backlog. Typically, the PO, with Customer representatives, is responsible for managing the product planning activities. Program leadership assigns the PO who may also fill the role of a Control Account Manager (CAM). The Product Backlog is the master list of all functionality at the Release and Feature level that is desired in the product and any other elements needed to produce the product, even if not in the final product. § Product Backlog is prioritized from most to least important by the PO and Stakeholders. All items which are added to the Product Backlog should also include a cost estimate and a mapping to the SOW. Cost estimates may be developed by the PO/CAM using Feature size and productivity estimates. The Product Roadmap may precede, inform, or supplant the development of an IMP, and informs the top level plan of the IMS. § The Critical Success Factor for applying Agile to PPMS programs is Release Planning where the Product Backlog is mapped to the Capabilities and their Release Plans.
  4. 4. 4 § These steps are taken before any Detailed Engineering Estimates, Feature decompositions are defined that implement the needed Capabilities produced by the Sprints or Kanban cycles of the development team. Top Level Agile Project Management Process Flow ❶ Develop Rough Order of Magnitude Estimate for needed capabilities § Using data capture form collect needed features from customer § Develop top down estimates for work in hours of effort § Verify those estimates, with Bottom Up assessment of relative effort ❷ Build Product Roadmap and Release Plan § Sequence each Feature in order of need in the Product Roadmap ❸ Build Product Backlog § For each Feature reconfirm effort estimate with team § Place Feature in Product Backlog § Reconfirm priority with Product Owner § Reconfirm effort estimates with Team § No item can be on the Product Backlog without an estimate of the effort to deliver the Item. This estimate comes from the ROM in Step ❶ and is refined with Backlog Grooming ❹ Build Sprint Backlog § Select from Product Backlog, candidate Features in priority order for next Sprint § Decompose Feature into Stories § Estimate effort for Stories § Assess capacity of Sprint team to develop software for each Sprint within the Sprint § Place Stories in Sprint Backlog ❺ Execute Sprint, Status Physical Percent Complete, and Create Earned Value Management Data § Decompose Stories into Tasks for development § Each Task should be no more than 8 to 16 hours of effort ‒ record Task Est in Rally of this planned effort § Start development § Update TO DO column in with remaining effort in hours ❻ Release software and capture customer feedback § With Tasks and Stories meeting the Definition of Done
  5. 5. 5 Figure 1 – the top level process flow of Agile Software Development using Earned Value Management, starts with the development of the ROM. These estimates for the Features are place on the Product Backlog to be selected for the Sprint. Physical Percent Complete is used to calculate Earned Value for each Feature in the Work Package, which is then rolled to the performance of the project and calculation of ETC and EAC, traceable to the Tasks in Sprints.
  6. 6. 6 Build ROM, Place Features in Product Backlog, Map to Product Roadmap and Release Plan ① Elicit the features needed to provide the business capabilities for customer’s needed software. This is done with Scenarios, Use Cases, Process Descriptions, or similar methods. Each Feature: § Provides some defined business value ‒ the reason the feature is needed. § Can be estimated. Starting with relative complexity or effort. § Is small enough to fit inside a Release. § Must be testable in some way ‒ definition of done should state how the customer will recognize that the Feature provides the needed business capabilities. ② Estimates are based on the expected cost, duration, needed skills to produce the Feature and its outcome. Estimating starts with understanding the complexity of the work and the risk associated with the success of that work. The estimate is be built in one of several ways: § Consensus of those with experience in the technical domain. § Applying a Wide Band Delphi method such as planning poker. § Historical data from previous development efforts. The estimates for the ROM will be in hours of effort with the following steps: 1. Develop preliminary size estimate for Feature, comparted to the other Features. This is done together with Product Owner and the Development Team. 2. Refine this size estimate from past performance of similar Features. Using the relative size estimate, assess the potential cost and effort. This is still an approximation of the effort to produce the Feature. 3. Using a bottom-up team based method with the information gathered in Steps ① and ②, reconfirm each Feature’s estimate. This last step increases the fidelity of the estimate by having the team members and the Product Owner confirm the credibility of the initial top-down estimates. Once the Features have been estimated in hours, a cost estimate can be derived with a resource rated cost model. ③ The Features are prioritized by the Product Owner and the Customer in order of Business Value. This Business Value is determined by assessing the Feature against the Business return. The Customer and Product Owner define the priority of the Features, and the re-prioritization of the Features as the project proceeds. The narrative of the Feature is expressed in the customer voice using Use Cases or Scenarios. ④ For the Feature estimates to be credible, the capacity for work must be confirmed. This is done by looking at past performance for the number of Features and Stories produced in past Sprints and across Sprints in other projects and Portfolios. With that number, a credible capacity for work can be used to confirm the projected throughput for the coming Sprints. ⑤ With the Features estimated and prioritized, sequence them in the Release Plan to produce the Product Roadmap. The Roadmap is a series of planned releases, each having a Theme (in Rally) with a prioritized set of Features. It is best to think of the Product Roadmap as an output of Release Planning, rather than an input. ⑥ With the Product Roadmap defined, the new Features with their estimates can be placed in the Product Backlog. ⑦ Sprint planning readiness starts with a review of the Product Backlog. This assures the Sprint Planning meeting is productive. This means coming to the meeting with an understanding of what work needs to be done in the coming Sprint(s). Features are decomposed into Stories, if that hasn’t already been done when the Feature was placed on the Product Backlog. Further detail of the Sprint planning process is provided in ⑨ ⑧ With the planned Features and their Stories, the Sprint can start. To do this, the Feature must be decomposed to Stories that can be completed inside the Sprint with the available resources.
  7. 7. 7 Figure 2 – The Product Backlog contains the Features proposed in the ROM, their order of performance from the Product Roadmap and the production of software in the Release Plan.
  8. 8. 8 Develop Product Roadmap for Features The Product Roadmap is the communication document showing the team and the stakeholders the Product vision and the progression of the Features that implement that Product vision. The Product Roadmap shows the high-level initiatives and the planned steps to get there. The product management team determines the priorities and aligns the Product Roadmap against the business goals. Building the Product Roadmap starts with the business goals of the customer and then assessing which Features best align with the goals of the business: § Define the strategy ‒ in a goal first manner. This is a Product Vision captures what the customer wants to achieve with the software. § Define releases ‒ select which Features are needed for each Release to meet the business goals. § Prioritize Features ‒ reconfirm the sequence of the Features to assure they deliver the capabilities needed by the customer to fulfill the business needs. § Publish the Product Roadmap ‒ as a Big Visible Chart information radiator for the development team. Developing the Product Roadmap § Prepare for the Product Roadmap ‒ describe and validate the product strategy before starting the roadmap process. § Tell a convincing and realistic story ‒ tell a coherent story about the growth path for the product and its Features. § Control the level of detail ‒ controlling the growth of the Roadmap contents is critical to keeping focused on business benefits. § Keep it simple ‒ the roadmap is not a schedule or a detailed plan. It’s a Map to the solution. § Get buy-in from all participants ‒ development, customer, Product Owner all have to be on the same page for the Roadmap to be a success. § Choose the proper timeframe ‒ the planning horizon needs to fit the Business Rhythm of the customer. § Prioritize Goal ‒ the Product Roadmap is not date driven, that’s done in the Release Plan. § Determine proper cadence ‒ confirm business rhythm for customer’s needed capabilities. Show that in the Roadmap. § Goal first, then Features ‒ focus on Capabilities first then, the Features needed to fulfill those Capabilities. § Define useful metrics ‒ physical percent complete from Task, to Story, to Feature is the basis of performance measurement in both Rally and the Earned Value Management System.
  9. 9. 9 Develop Product Roadmap for Features Figure 3 – Product Roadmap shows the Features needed to deliver the Business Capabilities to satisfy the business case or fulfill the mission.
  10. 10. 10 Engineering Estimate Template When the customer requests a ROM for potential work, the Engineering Template is used to capture the Features and the initial estimates that would be needed to support that Capability. The Product Owner collaborates with the Development Team and Scrum Master to define the scope and detail the Features to be included in the Project. The Engineering Estimate template, shown in Figure 4, organizes the work needed to implement each Feature and documents the basis of estimate. Each Feature in the estimate is defined using this form, with the Applications, Team members and their roles, the work to be included with the labor catteries for that work. The hours needed to complete the work are estimate to some level of confidence agreed to by the Product Owner and the Scrum Team members. This agree assures both side of the project ‒ those asking and those providing mutually agree on the precision an accuracy of the estimate. The Summary List shows the total number of hours estimated for each Feature and the Total hours for the project. The hours estimated for each Feature and the Feature description are moved to the Product Backlog in Rally when the project starts. These estimated Feature hours are the basis for developing the Stories. Updates to the Feature estimates are made as the Sprints are started and the Product backlog is groomed at the end of Sprint, in the Sprint Retrospective. As well these estimated are used to allocate labor resources in the Work Packages in the Integrated Master Schedule for the development of the Planned Value in the Earned Value Management Performance Measurement Baseline. After internal review and approval, the Engineering Estimate (containing only hours) is priced by Finance and officially delivered to the customer.
  11. 11. 11 Engineering Estimate Template Figure 4 – The Engineering Estimate Template captures the estimates for the planned work elicited from the Customer. These estimates are built by the Subject Matter Experts – usually Bottom Up – from the descriptions of the needed capabilities and the Features that implement them.
  12. 12. 12 Sprint Planning Ready for Sprint Execution Sprint Planning Meeting Preparation Responsibilities[1] Product Owner Development Team Review the Release Plan to assure Release Goals are still appropriate. Review top priority Features in Product Backlog and is prepared to ask any questions needed to build Stories. Review and reprioritize Product Backlog items, including any prepared Stories already in backlog, ones that were not accepted in a prior Sprint, or are newly generated from defects or other Stories. Consider any technical issues, constraints, and dependencies and is prepared to address these concerns. Understand how the reprioritization can affect other teams who may be dependent on commitments being made during this planning session. Consider the work involved in delivering the functionality developed in the Stories to be prepared for making Story and Task estimates in the meeting. Understand the customer needs and the business value of each Story that will be delivered. Understand the team’s capacity for work and what that capacity should be for the coming Sprint, based on team discussion at the last Sprint retrospective. ⑨ A Good Story: § Describes what Users DO ‒ choose Stories that describe something the user will accomplish § Is the start of a team discussion of what this means in working software? § Takes a slice through the whole system ‒ if the story is too big, break it down on natural system boundaries. Do the less complex ‒ but useful version first § Represents acts that can be completed ‒ write a closed story that ends with the achievement of a meaningful goal. § Capture constraints and limitations ‒ the story should describe what the system should NOT do is as important as what it should do. Constraints and limitations like: technology, dependencies, performance, platforms, tools. § Explicitly states dependencies § Written by the Product Owner or Customer § Can be estimated and validated ⑩ With Stories in the Sprint Backlog and their estimated effort, this is the To Do list for the Sprint. Tasks are created to address the emerging scope of the Stories. Tasks should be no more than 8 to 16 hours of effort. If they are longer, more decomposition is needed for the Story and its Tasks. ⑪ The next step of the Sprint planning session is the reassessment of the Stories and Tasks based on the negotiation between the Product Owner and the Development Team to assure all the needed work can still fit in the Sprint. ⑫ With the committed scope and confirmation of the capacity for work, the planned work is fixed – otherwise the commitment is not meaningful. Hours in the Task Est column in Rally cannot be changed once the Sprint starts If more work is identified once the Sprint starts, the TO DO column should be updated to represent this work. ⑬ Any interdependencies between the development work ‒ Scrum of Scrums with the Release Train Engineer ‒ is assessed and issues resolved across the teams. ⑭ With the planned Stories and Tasks, confirmation of interdependencies, concurrence of Product Owner and Development Team, there is commitment to start the Sprint. 1 Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Dean Leffingwell, Addison‒Wesley
  13. 13. 13 Figure 5 –Sprint planning starts with selecting Features from the Product backlog for the next Sprint. These features are decomposed into Stories and then into Tasks. The Stories can be estimated in Story Points, but the Tasks are estimated in Hours. This information is placed in the appropriate fields in rally as shown in Figure 8
  14. 14. 14 Data Needed in Rally for Status Reporting Rally contains the information needed to calculate Physical Percent Complete that can be used in the IMS and Cobra® to calculate the Earned Value numbers needed for program performance reporting to the customer. These key data items are: § Task Est(imate) ‒ this is the baseline estimated number of hours needed to complete the Task o The Task Est is rolled up to for the estimated number of hours needed to complete the Story § TO DO - hours are updated every time something changes at the Task level o Work is completed - the TO DO hours reflect 0 hours remaining o New work is discovered at the Task level - the TO DO hours are increased o No progress made - the TO DO hours stay the same Important to Note: § The hours in the Task Est column do not change once the Sprint starts § This is the baseline of the estimated effort for the Task § Only the TO DO column can change § Rally does not lock the Task Est column, so capturing the Task Est totals at the end of Sprint Planning is recommended to uphold the integrity of the baseline. With This Information, Physical Percent Complete can be determined § With the TaskEst as the starting estimate for the work at the Task level, the TO DO field is used to calculate Physical Percent Complete (P%C) at any time during the Sprint. § This is done by o P%C = (TaskEst – TO DO)/TaskEst § This means that as the Planned work is performed, using the Planned hours to performance that work, the percent complete increases, toward 100%, as the remaining work ‒ TO DO ‒ approaches Zero § This calculation is shown in Figure 10, starting at the Task level, rolling to the User Story, then to the Feature. § This P%C at the Feature level, is used in the IMS to inform the Earned Value (EV) calculation as o EV = PV × P%C
  15. 15. 15 Figure 6 – Rally User Story and Task screen with estimates of the Tasks in Hours, rolled up to the User Story. The TO DO field is updated, the Physical Percent Complete is updates. As the Task proceeds, the TO DO value is reduced to ZERO when the task is complete.
  16. 16. 16 Sprint Execution ⑮ The execution of the Sprint begins with the Sprint Backlog containing estimates for Stories and the supporting Tasks that were committed during Sprint Planning. Once the Sprint begins, the Task Est column in Rally is locked, as this is the effort the Development Team has committed to. Total Forecasted Effort includes the original Story estimate, generated from Sprint Planning, plus any added Stories and effort that was accepted during the Sprint with proper Change Control. ⑯ If new work (in scope) is discovered within the Sprint, a Story may be added to the Sprint Backlog after going through the appropriate Change Control process. The TO DO column in Rally must be updated to show the work required to deliver the added Story. If an existing Story will take more effort than initially planned to complete, the TO DO column will be updated to show the hours needed to deliver the Story. The Total Forecasted Effort for the Sprint is the Original Planned effort (Task Est) + TO DO effort for all Stories in the Sprint ‒ original or added. Note: if any additional work is brought into the Sprint, the Development Team must again provide consensus that they are able to take on the work and are still able to deliver all other commitments within the period of the Sprint. ⑰ Update status of the Tasks and the TO DO column as work progresses. At any time, the TO DO column should reflect the remaining hours for the Task. When all the Tasks for a Story have been marked COMPLETE, the Story is marked ACCEPTED, according to the Definition of Done (DoD), in Rally. The TO DO column should then be Zero, reflecting no remaining work for the Tasks and the Story. ⑱ For added Stories and Tasks, record new Task Est following Change Control process and update the TO DO column to reflect the new work effort. ⑲ Calculate Physical Percent Complete for the Feature in the Sprint based on: Physical Percent Complete = (Task Est – TO DO) / Task Est The Physical Percent Complete for Tasks and Stories in the Sprint for the Feature is available at any time. This provides Physical Percent Complete measures on demand, any time the TO DO column is updated. This enables the best practice of knowing current progress to plan for calculating Estimate to Complete and Estimate at Completion using Physical Percent Complete at the Task level.
  17. 17. 17 Figure 7 ‒ executing the Sprint by performing the work for each Task, to complete the Story, that completed the Features. As this work progresses the TO DO field for each Task is updated to reflect the remaining work. This is done at the morning standup, so Physical Percent Complete is available every day.
  18. 18. 18 Status the Completion of the Sprint and Completion of the Feature(s) ⑳ Export the data for the Feature from Rally in step ⑲. The export includes all Features for the Project, supporting Stories and Tasks, the Task Est and the TO DO hours. An example of Rally is export is shown in Figure X. ㉑ With the Physical Percent Complete data, the Scrum Teams will assess any impacts on other Scrum teams for potential conflicts, blocked work, or unfavorable outcomes. ㉒ Apply the Physical Percent Complete from step ⑳ to all Features in the IMS. Update any other work in the IMS not captured in Rally. ㉓ Record accumulated Physical Percent Complete for all Features in the IMS, ready to be sent to Cobra® This includes work in the IMS but not in Rally. (Documentation, PM support, Level of Effort work, etc.) ㉔ Apply Physical Percent Complete to Cobra® to calculate PPMS data ‒ ETC, EAC, CPI, SPI, CV, SV, TCPI
  19. 19. 19 Figure 8 ‒ Status the work in the Sprint using the TO DO field in Rally for any remaining work. If the work is complete, the TO DO field will show ZERO. If the work has not started the TO DO field will show the same value as the TASK Est.
  20. 20. 20 Measuring Performance of Kanban Project Work Kanban is about visualizing the work being done on a daily basis. Kanban means Visual Signal. § Every work item on the board is a Kanban Card § Cards provide a brief description of the work item § The team is ONLY Involved in the work that is In Progress. Only when the work item is complete can it be moved to the Done state. Then the team picks a card from the TO DO list § There are no fixed iterations length in Kanban There are Six Core Properties of Kanban 1. Visualize the Process 2. Limit the Work in Progress 3. Manage the Work Flow 4. Make Process Policies Explicit 5. Implement Feedback Loops 6. Improve collaboratively, evolve experimentally The critical success factor for Kanban starts with the Visualization of the Process. The Kanban Board needs to show as a minimum § The work TO DO § The ON GOING work § The work DONE § The WORK IN PROGRESS limit for the TO DO and the ON GOING Work
  21. 21. 21 Measuring Performance of Kanban Project Work There are many choices for the Kanban Board. But each needs to possess the 6 elements above in some form. § Cumulative Flow o CFD visualizes where the Stories are in the workflow as a function of time. o The CFD provides insight into issues, cycle time, forecast completion dates, visibility to identifying bottlenecks. § Cycle Time / Production Lead Time o The cycle time of a task measures how long a task takes to be completed. This is the time the task is in process in a Kanban Swimlane while the work is being performed. § Customer Lead Time o Time that elapses from the time work is submitted to the moment they can use it. o Describes how the whole organization or product team (not only a development team) reacts to customer's needs. § Throughput o A measure of productivity or efficiency which is typically a number of features delivered over time. o Teams can weigh delivered features basing on assumption that a big feature is worth more than a small one but that's tricky at best. § Work in Progress (WIP) o The number of work items that are currently in progress in the end-to-end work process. As a standalone measure it doesn't make that much sense, but it gives a lot of insight when combined with other measures. o WIP is the total amount of work committed but has not been completed. o This is an example is Little's Law which says: Average Cycle Time = WIP / Average Throughput § Tact Time / Takt Time o A measure of the frequency of delivering new work items. o Tact time is Average Cycle Time divided by Average WIP. o Tact Time states the throughput of the team and provides assessment if remaining work can be done before a specific deadline.
  22. 22. 22 Exporting Feature Data from Rally The file shown on page X is exported from Rally and contains the information that will be used by the Planner to update the Integrated Master Schedule. At any time, a report can be exported from Rally to calculate Physical Percent Complete of each of the Features for a Project. On the last day of the Fiscal month, the Scrum Master will be required to provide the Project status to the Planner for PPMS reporting. Within Rally, the Scrum Master will produce a report that contains all of the Features for the Project. The following columns should be included in the report: 1. ID 2. Name 3. Task Est 4. TO DO Once the Features and their User Stories and Tasks are displayed, the report will be exported into Excel using the Import/Export/Print function. When the User selects the export function, the report will contain the data needed to calculate Physical Percent Complete for the Feature (Task Est and TO DO). The steps to calculate Physical Percent Complete of the Feature can be found on Page X.
  23. 23. 23 Figure 9 – an export of the Rally data used to calculate Physical Percent Complete for the entire project. For past Sprints, the TO DO field will be ZERO. For future Sprints (beyond the current Sprint or planned Sprints), the TO DO field will equal the Task Est – no work has been done. For work underway in the current Sprint, the TO DO field shows how much work remains. This information is the basis of the Earned Value calculation using P%C = (TaskEst – TO DO) / TaskEst. Import/Export/Print Button
  24. 24. 24 Calculating Physical Percent Complete for the Feature Work performed in Sprints at the Agile level of the program will be the point where progress is measured in accordance with EIA-748-C guidance Objectively assess accomplishment at the work performance level This means taking credit for the completion of Stories and their Tasks inside the Sprint using the Definition of Done. No credit taken until the Story completes according to the Definition of Done. When 100% of the planned Work Effort are earned at the completion of the Story. With the Stories complete in the Sprint, this information is used to calculate the Physical Percent Complete for the Feature as shown in Figure 10 This information is exported by Rally to an Excel spreadsheet to be used by the IMS to update the Work Package contain the Features as shown below
  25. 25. 25 Figure 10 ‒ starting with the Engineering Estimate (ROM), 60 hours are defined for the Feature with User Stories 1 and 2. Sprint one has planned 40 hours for User Stories 1, 2, and 3. The Physical Percent Complete for Sprint 1 is calculated in Rally as (Task Est – TO DO) / Task Est. Sprint 2 has not started, so it’s Task Est is 0. The Physical Percent Complete for the Feature is calculated in YELLOW. This information is extracted from Rally and sent to the IMS for assessment of Physical Percent Complete for the Project.
  26. 26. 26 Integration of Agile with Earned Value Management The integration of Agile on Earned Value Management programs starts with separating the agile development processes from the Earned Value Management processes with a Bright Line between the two. Above the Line § Capabilities are defined, product roadmaps are built, and Release Plans developed to deliver the Features needed to implement the Capabilities. § The Features from the Rough Order of Magnitude Estimate are sequenced, assessed and placed in Work Packages in the Integrated Master Schedule. § Resources are determined for the FTE’s assigned to the Sprints § The Feature is assigned a number of Sprints in the ROM. This is reflected in the IMS to a resource loaded PV in dollars § Features in Work Packages or Planning Packages put on PMB § Features contained in Work Packages and Planning Packages in the IMS are placed in the Product Backlog in Rally § The Product Roadmap shows the order of the Features and the Release Plan is derived from the Product Roadmap and reflected in the order of work in the Work Packages and Planning Packages Below The Line § With the Features the Product Backlog is built § For each Sprint, Features are selected ‒ using the priority of work defined in the IMS Work Packages § Stories developed, and Task assigned to each Story § Using Rally, Task Est(imate) are entered to show the hours of effort § As work progresses, the TO DO column is updated to show remaining work. o If additional work is discovered for the Task or Story the TO DO will record that work o If new Stories are added, their Tasks will be added and the TO DO column will represent this new work o If Stories or Tasks are removed because they are no longer needed, the work in the TO DO column will be removed as well Status Reports § With the TO DO column and the Task Est(imates) the Physical Percent Complete is available at all times o This data can be moved from Rally to the IMS in an export o With this data Physical Percent Complete can be calculates as (Task Est – TO DO)/Task Est o This is then used to calculate Earned Value (EV) as PV x Physical Percent Complete
  27. 27. 27 Figure 11 –the separation of Earned Value Management processes from Agile Development processes allows each domain to perform it’s needed function to the best advantage. The Earned Value domain consists of the Performance Measurement Baseline of Work Packages and Planning Packages of Features, with their Planning Value derived from the FTE assignments to the Sprints. The Physical Percent Complete from the Sprint is used to calculate the Earned Value as EV = PV x Physical Percent complete starting at the Task level of rolling up to the Feature in the Work Package
  28. 28. 28 Integration of Agile with Earned Value Management System The Integrated Master Schedule contains the Features and the Features are held in Work Packages and Planning Packages These Features are One-for-One with the Features held in Rally. The Features in Rally have Stories and Tasks assigned to specific Sprints. This is shown on Page 31. There are several important aspects to connecting Rally data with the IMS 1. The IMS contains the Product Roadmap and Release Plan periods of performance. The Product Roadmap is represented in Work Packages along with the Release Plan 2. The Duration column will be derived from the total duration of the Sprints needed to complete the Feature 3. The Percent Complete column will be the Physical Percent Complete calculated from Rally as: • P%C = (TaskEst – TO DO)/ TaskEst 4. The Resource column contains the assigned resources at the Sprint rolled up to the Feature 5. Work Packages contain Features that are on the Product Backlog, originally developed in the ROM 6. The Period of Performance for each Work Package is the total Period of Performance for the Features assigned to their Sprints. 7. The Planned Value (PV) for the Work Package is the rolled up Full Time Equivalent (FTE) hours from the Sprint teams for each Sprint needed to implement all the Features in the Work Package. This information come from the Scrum Master and the Scrum Team assignments and their labor utilization. 8. The Baseline Start and Baseline Finish of the Feature is aligned with the Sprint Start and End date where the Stories are developed to implement the Sprint. 9. The Actual Start and Actual End will only be different if the Feature is moved to another set of Sprints or replanned in the Product Backlog.
  29. 29. 29 Figure 12 – the Integrated Master Schedule contains the Work Packages and their time phase Planned Value (PV). The ROM defines the planned cost, that is updated in the estimating processes before thaw Features and their Stories are placed on the Product Backlog. This updated PV is used as the baseline for calculating Earned Value with the Physical Percent Complete from Rally.
  30. 30. 30 Integration of Agile with Earned Value Management System ❶ Starting with the Rough Order of Magnitude from the customers needed Features elicited from the Capabilities, layout out the Features in the logical sequence in the Product Roadmap. This estimate includes the hours needed to implement the Feature and the sequence of the Features to produce the Capabilities for the customer’s business needs. ❷ With the sequence of Feature, the contents of the Product Roadmap update and the Release Plan for those Features built. This shows what Features will be produced in each Release to match the Product Roadmap. ❸ With the Product Roadmap and Release, place the Features on the Product Backlog with estimates from the ROM and Story Points ‒ if they are used to prioritize the Features. This is an option but provides an easy way to assess prioritizes of business value independent of the cost or duration of the effort to produce the Features. ❹ From the Features in Rally, update the IMS with which Features belongs in each Sprint. This has been defined in the ROM, for a time phased Planned Value. ❺ During the Sprint, update the TO DO field in Rally. This results in the calculation of Physical Percent Complete for the Story in the Sprint, and the Feature from the Stories
  31. 31. 31 From customer requirements build a ROM with Time Phase Features Lay out Feature in Product Roadmap with Releases Place Features on Product Backlog and Plan Sprints with Stories and Tasks Update IMS with PV for each Feature in Work Packages from FTE’s in Sprints Produce Physical Percent Complete for Story from TO DO effort at Task level and roll up to Feature and send to IMS Update IMS for EV using Physical Percent Complete x Planned Value for Sprint ❶ ❷ ❸ ❹ ❺
  32. 32. 32 Glossary Agile Teams The Agile Team is a cross-functional group of five to nine individuals who have the ability and authority to define, build, and test solution value—all in a short-iteration timebox. The team includes the individuals necessary to successfully deliver this value, supported by specialists where applicable. Acceptance Criteria The criteria which defines the functionality, behavior, and performance required by the feature for it to be accepted by the product owner or customer. This acceptance criteria can also be applied to Tasks, Stories, and Features. Backlog A collection of prioritized requests for work to be done. The Product Backlog holds the Features that stared in the Rough Order of Magnitude estimate to the customer. Stories that were returned from Sprints can also be in the Product Backlog. The Sprint Backlog holds the Stories for the current Sprint. Backlog Grooming An ongoing process whereby the product owner or customer manages the product backlog based on information gathered in the feedback cycles inherent to agile practices. The activities of backlog grooming can include: adjusting rank; breaking down stories that are going to be worked on in the next few iterations; creating new stories; updating existing stories; deleting obsolete stories; elaborating acceptance criteria.. Customer A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its work items. See also stakeholder. Capacity Amount of work a team can complete in a given time period. Capacity Planning Matches business demand with available supply, so you can optimize your agile teams’ capacity towards the highest business value within their capacity. Daily Standup A brief meeting held between the delivery team, product owner, and scrum master. While everyone stands (to keep the meeting from running long) each team member reports on what work they did yesterday, what they plan to do today, and alerts the scrum master of any issues that may be blocking them.
  33. 33. 33 Definition Of Done A living definition created and managed by the delivery team, defining their current standards for technical excellence. The definition typically includes the requirements the team has to meet in order to declare any work item worked on in an iteration done. These differ from acceptance criteria in that they are typically technical in nature and generalized to be valid for most work items (such as unit tests complete, online help updated), as opposed to value-driven criteria specific to a feature (such as website users should only be able to create one account per email address). Dependency A relationship between two modeling element work items, in which a change to one work item will affect the other work item. Feature A Feature is a service provided by the system that fulfills stakeholder needs. Each is developed by a single Agile Release Train. They are maintained in the program backlog and are sized to fit in a program increment so that each PI delivers conceptual integrity. Each feature includes a statement of benefits and defined acceptance criteria. Features are structured as <Action><Result><Object> The Feature is placed on the Product Backlog with its estimate development in the Engineering Estimating processes when development the ROM for the customer. Product Owner The Product Owner is the team member responsible for defining stories and prioritizing the team backlog. The Product Owner is also a member of the extended Product Manager/Product Owner team, understanding and contributing to the program backlog, vision, and roadmap. Plan Estimate The amount of effort estimated to complete a single user story. Plan estimates are represented by points, t-shirt sizes, or other systems. They do not correspond to task or man hours. Product Backlog A prioritized list of functional and non-functional requirements for a system or product. A product backlog may be created and prioritized on the Backlog page, under the Plan menu in CA Agile Central. Product Backlog Item Can be user stories, technical features, defects or any other item that will require the time of the delivery team to deliver the feature. They are typically estimated at the gross or plan level. Product Owner (PO) A role on an agile delivery team that is responsible for collecting and ranking business requirements on the product backlog. A product owner does not manage a delivery team but communicates what must be built in the next release or iteration. In
  34. 34. 34 exchange for the team's commitment to finish the top-most ranked work in an iteration, the product owner agrees to protect the team from any changes in requirements during the iteration. Product Roadmap A high-level or long-range estimation of work to be completed by an organization. Roadmaps may be created for internal planning or external communication to stakeholders. In agile organizations, roadmaps are subject to change with evolving business priorities or needs. CA Agile Central Portfolio Manager provides capabilities for planning feature roadmaps with development cadences of usually 10-12 weeks. Release The goal of Lean-Agile is frequent delivery of valuable, working, and fully tested solution increments. This is accomplished via a stream of releases, each of which has been validated and approved for final efficacy of use and is accompanied by the documentation necessary to ensure successful application. Release Planning A commitment to a plan for delivering an increment of product value. It is a collaborative effort involving scrum masters, product owners, delivery teams, and stakeholders. Release Train Engineer The Release Train Engineer (RTE) facilitates Agile Release Train processes and execution. The RTE escalate impediments, helps manage risk, helps ensure value delivery, and drives continuous improvement. Roadmap The roadmap communicates planned Agile Release Train and value stream deliverables and milestones over a time line. The roadmap includes committed deliverables and visibility into the forecasted deliverables of the next few PIs. It is developed and updated by solution and product management as the vision and delivery strategy evolve. Rough Order of Magnitide Estimate The ROM is an definition of the Features needed by the customer and the estimate of the hours of work eneded to implement each Feature. The Features are assigne to Sprints to assess the staffing needs to implement the Feature. The period of peformance for each Feature spans Sprints in Rally. The total number of Sprints are refelcted in the Feature Period of Performance in the IMS Work Package contained one or more Features. Scrum Master The SAFe Scrum Master is a servant leader and coach for the Agile team. Primary responsibilities include ensuring that the process is being followed; educating the team in Scrum, XP, and SAFe; eliminating impediments; and fostering the environment for high-performing team dynamics, continuous flow, and relentless improvement.
  35. 35. 35 Stories Stories are the primary artifact used to define system behavior in Agile development. Stories are not requirements; they are short, simple descriptions of a small piece of desired functionality, usually told from the user’s perspective and written in the user’s language. Each story is intended to support implementation of a small, vertical slice of system functionality, supporting highly incremental development. Task A unit of work that, when performed, contributes to the fulfillment and completion of a scheduled user story within the iteration. Tasks allow decomposition of stories into manageable units of work. Team members can take responsibility and ownership for each task, providing estimates and work left to do for completion. Task Estimate The amount of effort estimated to complete a single task. Generally recorded in hours but does not directly correlate to user story estimates. To Do The amount of remaining effort required to complete a task. Generally recorded in hours. This field in Rally is used to update the status of Tasks for each Story. The TO DO value and the Task Est(imate) value are used to calculate Physical Percent Complete of the Tasks. This data is rolled up to the Story and then to the Feature level in an exported worksheet from Rally to the Integrated Master Schedule. From there Physical Percent Complete is used in the calculation of Earned Value Management numbers EV = PV x Physical Percent Complete User Story A listing of acceptance criteria needed to deliver a new feature or piece of work. Generally written from the perspective of a user of the system. A commonly used format is: As a X, I want to Y, so that Z.
  36. 36. 36 Glen B. Alleman Niwot Ridge, LLC 4347 Pebble Beach Drive Niwot, Colorado 80503 303.241.9633 Performance Based Management ® Integrated Master Plan Integrated Master Schedule Earned Value Management Systems Risk Management Proposal Support Services