Agile performance reporting – part 1: Scope change control

Many people think that you can’t benefit from agile if the rest of the organization hasn’t changed.  That is only true to a small degree, much less than you would think.

In essence, the only organizational change that is a must is to agree that projects carry a level of uncertainty.

I hear you thinking: “That’s just common sense, everybody knows that!”.  Indeed! Everybody knows it, but many refuse to acknowledge it.

It is essential that your company’s leadership agrees on this.  This is the only way to start managing projects in an agile fashion, which is based on:

  • Regular feedback
  • Transparency

Two things that are essential to keep a project on course by making decisions on a regular basis.

If on the other hand, your leadership does not acknowledge the uncertainty of projects, projects don’t need feedback cycles or transparency, because they are cast in stone and will be delivered as planned anyway.

If they do acknowledge this, you don’t need to change much to the current organizational processes for starters.  If you’re a project manager in an organization that manages its projects the way PMBOK prescribes, you’re probably sending performance reports to your stakeholders or hosting monthly project boards.

Because this is a model of management by exception, you’re only supposed to bother them with details when things go wrong.
So typically, your performance reporting consists of:

  • Status reporting
  • Progress reporting
  • Forecasting

PMBOK contains 5 Controlling processes:

  • Scope Change Control
  • Schedule Control
  • Cost Control
  • Quality Control
  • Risk Response Control

The output of these processes is the input of your performance reporting.  Sounds very heavyweight, doesn’t it?

In this blog post I’ll show you how you can easily keep your performance reporting in this format when you’re dealing with an agile project.

1. Scope Change Control

This process tries to structure the way scope changes need to be dealt with.

Typically, the work breakdown structure (WBS) acts as the project’s scope baseline.  A change request needs to be formally approved in order to be included in a new version of the WBS, so that a corrective action can be included into the project plan.

A process like this is critical when you’re working in a fixed price, fixed scope contract.  Each change that was not part of the contract needs to be tracked, approved and funded.  That’s common sense right?  If you’re contractually bound to deliver a scope for a fixed amount of labor, you want to make sure that the scope is well-defined and you only spend time on what’s in that contract.  All additional work might make sense for a user, but will not be paid for and therefore will endanger your project success.

In an agile project, the concept phase of a project is significantly smaller.  For various reasons, it makes more sense to start with a high level scope description and high level project plan, which we will expand later through learning and feedback.

This means that it is much more difficult to decide whether or not something is a change.  Actually, a change is treated differently.  Where in our classical Scope Change Control process, a change is treated as a danger, in an agile project it is treated as an opportunity.  Learning or feedback have emerged the discussion of a potential change, which is then weighed and the change enters the product backlog at a specific place or not at all.

In my opinion, it is still healthy to report about Scope Change.  Because in an agile project you’re also working with constraints.
Maybe you need to realize a certain minimum scope, maybe you have a maximum budget or maybe you need to release before a certain date.  I call this the primary project focus.  The one thing that is most important.  The one thing we hate to tamper with.

Instead of reporting on the list of change requests against the WBS, in an agile project you can report about the evolution of the size of the product backlog.  By definition, content is variable to a certain extent, because we started with a high-level scope description.
So it’s no surprise that the scope is changing.  What is most important is to keep an eye on the total size of the product backlog.
Because you don’t have unlimited resources, the scope can only grow so far.  If your product owner can compensate the growth by removing other pieces of the product backlog, no action needs to be taken.  But in some cases, the product backlog grows too much.  This is a case when management by exception takes place.  The project board needs to take a decision.  Additional funding, yes or no?  Altering scope, yes or no? …

This may sound bureaucratic to most agile enthusiasts, but it matches the idea behind the product owner role.  She gets the mandate to represent all stakeholders and take decisions about the product, until a certain level.  Within the dimension of scope, a product owner may get the mandate to take decisions as long as all 6 epics are covered and the total amount stays lower than 300 story points.

In an agile project you can report about scope change with the use of a burn-up chart.

As you can see, the red line represents the total size of the product backlog.  As it evolves, you can plot a new point after each sprint.  This shows the evolution in the product backlog size to the project board.  So besides the actual total, they can also see the evolution.

This seems very high level, which it is.  But remember, the project board manages by exception and is not interested in the detail evolution of the product backlog.  It has given a mandate to the product owner to manage that.

What data do you need to create this graph in excel?  This is what my data table looks like:

The burn-up chart can also be used for reporting about the other PMBOK Controlling processes, but I’ll leave that for next blog posts.

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.

5 comments

  1. Pingback: Agile performance reporting – part 2: Schedule control « SkyCoach

  2. Great start to your series of posts on this topic. I think it’s all too easy for the agile community to say, turn the entire company agile. Yes I think this is a great option, but not a five minute task in a large international corporate and therefore sometimes you’ll be running agile projects in places that run PMI or Prince2 project governance around you. Being open that this happens and making the interface as painless as possible is a very pragmatic approach and something to be commended.

    Clearly though even in this situations, it is good to strive to continue the end of end adoption of lean and agile approaches.

  3. Alexia Marthoon

    yeah its a very good article.As a project manager, I use Scrum in my projects. The Guide to Scrum Body of Knowledge by SCRUMstudy provided a complete reference for the Scrum project I am working with. It is a very good book and extremely readable. I really liked sections on risk and quality. The tools mentioned in the processes were very helpful. I highly recommend this book if you are planning to implement Scrum in your organization. You can go through the first chapter available on http://www.SCRUMstudy.com

  4. Pingback: What is the role of the PMO in an Agile organization? | SkyCoach

  5. Pingback: The Agile PMO : organizing the project board | SkyCoach

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: