Successfully reported this slideshow.
Your SlideShare is downloading. ×

Process Flow and Narrative for Agile

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 25 Ad

Process Flow and Narrative for Agile

Download to read offline

Starting with the development of a Rough Order of Magnitude (ROM) estimate of work and duration, creating the Product Roadmap and Release Plan, 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.

Starting with the development of a Rough Order of Magnitude (ROM) estimate of work and duration, creating the Product Roadmap and Release Plan, 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.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Process Flow and Narrative for Agile (20)

Advertisement

More from Glen Alleman (20)

Recently uploaded (20)

Advertisement

Process Flow and Narrative for Agile

  1. 1. AGILE PROGRAM MANAGEMENT PROCESS FLOW Starting with the development of a Rough Order of Magnitude (ROM) estimate of work and duration, creating the Product Roadmap and Release Plan, 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 + Earned Value Management 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 Jira 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 Jira 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 Applying Agile to Programs § Success for applying Agile to programs starts with methods of measuring progress to plan are already contained in the Agile Software Development Method ‒ Scrum, XP, DSDM, Crystal, Kanban. Each 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 provides the top-level planning activities that precede or inform development activities. 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 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 Project Manager (PM). The Product Backlog is the master list of all functionalities at the Release and Feature level that is needed 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 ROM cost estimate and a mapping to the SOW. Cost estimates may be developed by the PO/PM using Feature size and productivity estimates. § The Critical Success Factor for applying Agile to programs is Release Planning where the Product Backlog is mapped to the Capabilities and their Release Plans. § These steps are taken before any Detailed Engineering Estimates of the Feature decompositions are defined that implement the needed Capabilities produced by the Sprints or Kanban cycles of the development team.
  4. 4. 4 "These days we do not program software module by module; we program software feature by feature." ‒ Mary Poppendieck, Agile Estimating and Planning, Mike Cohn, Prentice Hall, 2005. Top Level Agile Project Management Process Flow ❶ Develop Rough Order of Magnitude (ROM) 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 Jira 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 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 Jira) 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 Jira.
  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 Jira 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 Jira 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 Jira as shown in Figure 7
  14. 14. 14 Sprint Execution and Measure of Physical Percent Complete ⑮ 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 Jira 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 Jira 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 Jira. 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.
  15. 15. 15 Figure 6 ‒ 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.
  16. 16. 16 Status the Sprint Completion and Feature Physical Percent Complete ⑳ Export the data for the Feature from Jira 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 Jira 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 Jira. ㉓ 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 Jira. (Documentation, PM support, Level of Effort work, etc.) ㉔ Apply Physical Percent Complete to Cobra® to calculate EVM data ‒ ETC, EAC, CPI, SPI, CV, SV, TCPI
  17. 17. 17 Figure 7 ‒ Status the work in the Sprint using the TO DO 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.
  18. 18. 18 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
  19. 19. 19 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.
  20. 20. 20 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 8 This information is exported by Jira to an Excel spreadsheet to be used by the IMS to update the Work Package contain the Features as shown below
  21. 21. 21 Figure 8 ‒ 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 Jira 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 Jira and sent to the IMS for assessment of Physical Percent Complete for the Project.
  22. 22. 22 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.
  23. 23. 23 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
  24. 24. 24 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 Jira. 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.
  25. 25. 25 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, recorded in hours, but does not directly correlate to user story estimates. To Do The amount of remaining effort required to complete a task, recorded in hours. This date is used to update the status of Tasks for each Story. The TO DO value and the Task Est(imate) are used to calculate Physical Percent Complete of the Tasks. This data is rolled up to the Story and then to the Feature level. From there Physical Percent Complete is calculated User Story A listing of acceptance criteria needed to deliver a new feature or piece of work 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.

×