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
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
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
"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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.