July 30, 2021

Reporting in a “Wagile” Environment

By:

Ted Tomoyasu

So, your company has decided to go “agile”?  What does that mean for you as a department manager or project manager?  How do you know if your teams are making progress?  How do you manage “agile” teams when the rest of the company is still “waterfall”?

Waterfall + Agile = “Wagile”

As companies respond to distributed teams and remote workers in a rapidly changing world, the trend to adopt agile ways of working has gained more momentum.   But what is “agile” and how does it differ from traditional “waterfall” methods?

Traditional“Waterfall” vs. “Agile” PDLC

In many cases, a hybrid model where software development teams adopt agile while the rest of the company still operates in a waterfall is common. In this “wagile” environment, the upfront planning and budgeting is done in a traditional manner, while the product development lifecycle (PDLC) is executed in an agile manner.  In this white paper we will look at this scenario.

Managing agile teams

So, what’s my role as a manager in“wagile”?   Well, if you have “agile”teams and the rest of your company is still waterfall; you need to create the environment for your team to succeed by managing scope; and communicate to the rest of your organization the learning and progress that your team is making by reporting using Earned Value Management (EVM) with an Agile twist. 

To create the environment for your team to succeed, you need to work with your Product Owner and stakeholders to prioritize the deliverables in the project scope, creating your team backlog, so that the most useful and valuable functionality is developed and delivered first.  You also need to protect your team from outside distractions by working with your stakeholders so that the prioritized team backlog is the only scope of work for your team.

The progress your team is making can be reported by using Agile EVM metrics, which we will discuss in the subsequent section.   It is very important that you communicate to your stakeholders that in “agile”, scope can and will flex.  Meaning that the scope may be impacted by team “learnings” or the realization of external“risks”.   How this differs from“de-scoping” in classical project management is that you have worked with management to prioritize the backlog, so the most important and valuable functionality is delivered first; not just the “easiest” items.  

Reporting progress

The traditional metrics for monitoring progress on a project involve, scope, schedule, and budget.  These same metrics can be generated for agile teams with some caveats. 

Managing scope, is all about managing the deliverables.  In traditional methods, we might use a work breakdown structure (WBS) to define the scope of work for a project.  Each work package represents a deliverable item in the project and has requirements, schedule, and budgets which are managed and tracked. Any change in scope is rigidly controlled by a change management process  

In agile, deliverables are defined using backlogs.  Typical backlogs consist of high level product backlog and more focused team level backlog(s).  These hierarchical backlogs are made up of items (epics, features, or stories) which are prioritized by the Product Owner, and progressively elaborated by the agile team.  Backlog items are typically sized first in relative “T-shirt sizes” and then relative “story points” as they are refined by the Product Owner and agile team. The backlogs are created and maintained byproduct management and may change during the course of development and delivery, with items being traded in and out, based upon customer feedback or market changes.

In a “wagile” environment, the scope of a “project” may be made up of one or more epics which consist of several features and stories.  These features and stories are “T-shirt” sized, typically as Small, Medium, Large, & ExtraLarge and make up the Product backlog. To convert to story points, we analyze one feature/story of each“T-shirt size” and assign “story points” to it. Then we simply convert all the features/stories of that same “t-shirt size” to the same number of “story points”. The summation of all these backlog items then provides our total project scope expressed in “story points”.  

Example 1:

Project A = Epic B + Epic C

  • Epic B = Feature E + Story F + Feature G + Feature H
  • Epic C = Feature J + Feature K + Story M + Feature N

We “T-Shirt” size the features as follows:

  • Feature E = Extra Large
  • Story F= Small
  • Feature G = Large
  • Feature H = Medium
  • Feature J = Medium
  • Feature K = Extra Large
  • Story M = Small
  • Feature N = Large

 

Next, we analyze one “Small”, one “Medium”, one “Large” and one “Extra Large” backlog item and assign “story points”, thus:

  • Small = 1 points
  • Medium = 3 points
  • Large = 5 points
  • Extra Large = 8 points

Then it's simple math to sum all the “story points”, so:

  • Project A = Feature E + Story F + Feature G + Feature H + FeatureJ + Feature K + Story M + Feature N
  • Project A = 8+1+5+3+3+8+1+5

 Therefore, our product backlog for Project A = 34 story points

Schedules exist to help plan the development and delivery process. Using waterfall methodology, we typically define the schedules at the beginning of a project based upon our final delivery date with milestones/checkpoints established to comply with contractual requirements and/or financial reporting requirements. To demonstrate if we are progressing on schedule, we typically use earned value management (EVM) and report on the schedule performance index(SPI). 

SPI = EV/PV 

Where:

  • SPI = Schedule Performance Index
  • EV = Earned Value (what we delivered)
  • PV = Planned Value (what we planned to deliver)
  • SPI > 1 means you are ahead of schedule
  • SPI < 1 means you are behind schedule

For an Agile project, we can use a similar method to track and forecast performance to a schedule. Using a visual tool called a “Burn Up Chart” we can see the total project backlog in terms of“story points” vs. time. If we are using an Agile method called “Scrum” the time increments are called “Sprints”: which are 1 to 4 weeks in duration, with2 weeks being the most typical.

The number of “story points”delivered per “sprint” is the “velocity” of the team working on the project.   Most teams will have a stable“velocity” after 2-3 “sprints”, we can use this to forecast when the total scope can be delivered and create our baseline plan.

Example 2:

From Example 1, our total backlog for Project A is 34 story points. If, the team has an average “velocity” of 8 story points per“sprint”, Then, we can forecast the team to deliver the entire backlog in either 4 or 5 “sprints”.

We can also report the SPI on anAgile project based upon the cumulative story points delivered vs. the cumulative story points forecast.

SPI = EV/PV

Where:

  • SPI = Schedule Performance Index (Predictability)
  • EV = Earned Value (story points delivered)
  • PV = Planned Value (story points forecast)
  • SPI > 1 means you are ahead of schedule
  • SPI < 1 means you are behind schedule

Example 3:

After 4 “sprints”, the team on Project A has delivered 34 story points. So, our EV = 34 story points. Our PV = velocity x # of sprints = 8 story points/sprint x 4sprints = 32 story points. Therefore, our SPI = 34/32 = 1.063

As the SPI > 1, we are ahead of schedule. 

Budget or more precisely cost management is another important metric that is used to manage project spend.Using the traditional methodology to demonstrate if we are progressing on budget, we typically use earned value management (EVM) and report on the cost performance index (CPI).

CPI = EV/AC

Where:

  • CPI = Cost Performance Index
  • EV = Earned Value (of deliverables)
  • AC = Actual Cost (of deliverables)
  • CPI > 1 means you are under budget
  • CPI < 1 means you are over budget

For an Agile “project”, the team cost per unit time (week, sprint, month. etc.) is generally the same for the duration of the project except for minor variations due to holidays, vacations, and sick leave.

AgileCPI = EV/AC

Where:

  • EV = Story points delivered x the team cost
  • AC = Story point capacity x team cost
  • CPI > 1 means you are under budget
  • CPI < 1 means you are over budget

AgileCPI = story points delivered/story point capacity

Example 4:

After 4 “sprints”, the team on Project A has delivered 34story points. So, our EV = the story points delivered = 34 story points. Our AC = the story point capacity = average velocity x # of sprints = 8 story points/sprint x 4 sprints = 32 story points. Therefore, our CPI= 34/32 = 1.063.

As the CPI > 1, we are under budget

You will note that the CPI and SPI formulas have become the same.  So, in general, if you are ahead of schedule, you are running under budget; if you are on schedule, you are running on budget; and if you are behind schedule, you are running over budget. 

Closing:

In closing, if we are working in a “wagile” environment, we can use Agile EVM to effectively communicate the progress of our “agile” teams to our “waterfall” management.   Scope, schedule, and cost performance can be translated from the “agile” vernacular to the traditional project management vocabulary that may be more familiar to your company’s senior leadership.

The Latest from Nexient

We're hiring

Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.

Join Our Team