Process Flow and Narrative for Agile+PPM

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
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
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
§ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Glen B. Alleman
Niwot Ridge, LLC
4347 Pebble Beach Drive
Niwot, Colorado 80503
303.241.9633
glen.alleman@niwotridge.com
Performance Based Management
®
Integrated Master Plan
Integrated Master Schedule
Earned Value Management Systems
Risk Management
Proposal Support Services

Process Flow and Narrative for Agile+PPM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Process Flow and Narrative for Agile+PPM

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

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Process Flow and Narrative for Agile+PPM