Agile performance reporting – part 2: Schedule control

This blog post is the second one of the Agile Performance Reporting series.  You can read the first one here.

2. Schedule control

The second controlling process of PMBOK is schedule control, which goal is to assess the current status of the schedule and determine the variance from the baseline.  By understanding the cause, appropriate actions can be taken.

There are typically 3 inputs that are used in schedule control:

  • the project schedule
  • performance reports
  • change requests

As outputs we usually see things like:

  • Updates of
    • the schedule baseline
    • activity lists
    • the project management plan
  • Recommended corrective actions

Sounds heavy, right?

Let me try and translate it into the agile terminology.

In an agile project, schedule can be an important constraint too.  In most software development projects, people are your major cost. Which means, the longer they work, the more budget will be spent.  This doesn’t mean we can’t be flexible with our schedule, it means that our investors continuously want to see actuals and forecasts.

In other agile projects, schedule is the constraint, not (primarily) because of the cost associated with it, but because they need to release before a certain date (ex. The Christmas holiday season)

Again you see the same pattern.  There are constraints, but by identifying the primary one we define our reporting behavior.

What would be the input of your ‘agile’ schedule control?

  • the project schedule = your release burn-up with trend lines
  • performance reports = the velocity of previous sprints
  • change requests = the evolution of your product backlog

+ improvement suggestions that are outside of the team’s control

What would be the output?

  • Updates of
    • The schedule baseline = decreasing the product backlog or adding another sprint
    • Activity lists = n/a.  Since an agile team is cross functional and delivers pieces of functionality in the state of production ready in iterations.
    • Project management plan = change the order of the user stories in the product backlog
  • Recommended corrective actions = a mandate of the project board to implement improvements that help the team to perform more efficiently.

Let’s look at an example.

Suppose I use this burn-up chart to report about schedule to the project board:

Then I would show them that as to date, the team has completed 210 story points of the product backlog.  If we look at the trend lines, this would mean that in an average case, we would complete the project in sprint 12. I would also point out that the schedule has slipped with one extra sprint because of an increase of the product backlog in sprint 9.

At this point, my stakeholders may have enough data to take decisions.  If the project is still within its original expectations, they might decide to just carry on.

But if we absolutely needed to finish in sprint 11 (for budgetary or marketing reasons) they need to make a decision.

Your stakeholders will need extra detailed information, depending on the cause:

1. The product backlog has grown

Why has it grown? Did we forget something? Is it essential?

Now you need to be able to zoom into the backlog.  Probably not to a user story level, but at least to a feature level.  As a product owner, you need to tell them why this new feature was added, and why it’s important.  With this information, the stakeholders can weigh their decision and decide to:

  • Move a less important feature to next release.
  • Give the product owner the mandate to reduce the scope of some other features.
  • Agree with the extra time (& cost)

In this case, it’s not wise to add extra capacity to the team, because that only has an effect in the long run.

2. The team’s velocity is dropping

This is where you bring your retrospective data.  What have you discovered?  And most importantly, are there issues that cannot be improved by the team?

This is the time and place to get a mandate for bigger improvements.  Everybody sees the impact of your organizational inefficiency in terms of schedule and cost. And this is a powerful persuader.

So again, it is quite easy to use the project burn-up chart to report about schedule in the same format a PMP is used to.

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: