What is Benefits Management and how does it apply to Scrum Projects? This article will examine the different methods available to Measure Benefits within a Scrum Project. To begin with we want to briefly talk about the Benefits Management Process.

Benefits Management: When Should the Expected Benefits be Defined?

The discipline of Benefits Realisation Management (BRM) is fairly new. It is still not practised as widely as it should to be. The fact that a Project has been brought in on time and within budget plan used to be recognised as a Measure of Project success. The real markers of success are normally realised months to years after a Project is completed. If the Criteria for success was an increase in Customer base of 20%, this is unlikely to occur on Day 1.

To determine medium to long-term success, we need to Measure results in a Programme. The Programme incorporates a number of Projects. Programmes continue Measuring for success after the Projects have actually been Closed Out. The definition of the Value of the Product and the Project, should happen well before the Project starts.

With BRM in place, Stakeholders will have identified a list of expected Benefits. They will also identify a timeline for each Benefit during the Development of the Concept and Business Case. These are quantifiable  Benefits that can be Measured using common Concepts. Concepts like percentage growth or reduction, and Changes in quantity or financial Changes are used. Value will be assessed at regular pre-defined intervals based on the milestones on the timeline. This does not suggests that Project Value is disregarded throughout the Project. There are several Techniques that can Measure and report on Project Value at any point in time. This is not a “how-to” on the approaches, but an illustration of how Project Value can be assessed.

Benefits Management: Evaluating the Value

Scrum Projects use Value-Based Delivery rather that the Conventional Plan-Driven Delivery. Due to this, there is often the misconception that Project development can not be Measured using Conventional Methods. Even Plan-Based Projects require much deeper analysis than the “Project Triangle” of Time, Costs and Scope.

Earned Value Analysis (EVA) – Measuring Value to Date

EVA is not as complex as the ANSI Standard would lead you to think. It is based upon 3 primary specifications. The nomenclature has changed but we reveal the old terms in brackets:-.

-‘ PV or Planned Value’ (previously BCWS-Budgeted Cost of Work Scheduled).
-‘ A.C. or Actual Cost’ (previously ACWP-Actual Cost of Work Performed), and.
-‘ EV or Earned Value’ (previously BCWP-Budget Cost of Work Performed).
These are Measured against the Budget at Completion (BAC), which is the Project Baseline Cost.

The input to PV is all the Tasks that need to be performed. In a Scrum Project, these are the tasks that were outlined within the Sprint Planning Meeting. The EV is reviewed during the Sprint Review Meeting at the end of the Sprint. In Conventional Projects the PV would be the Work Breakdown Structure (WBS). In Scrum projects this would be the User Stories in either the Product or Sprint Backlogs.

An alternative to EVA is the Cumulative Flow Diagram (CFD), one of the Kanban Tools of Lean Manufacturing. It is a visual representation of the current state of a Project. The CFD is often called a “Burn-up Chart” since it mirrors and complements the Burndown Chart.

Benefits Management: the Cumulative Flow Diagrams.

The crucial word in the phrase Cumulative Flow Diagram is “Cumulative”. This is an ascending chart, that has a lot in common with EVA and procedures:-.

• ‘Work That Has To Be Done’ (i.e. the content of the Product Backlog).

• ‘The Tasks That Have Been Completed’ (or “done”).

• These are the Tasks That Have Been Completed But Awaiting Testing or Inspection.

• Tasks That Have Been Booked Out From The Product Backlog and Are In Progress.

Another mechanism that helps align Customer Expectations and the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) is the Development of a pilot or prototype. Charts and figures may illustrate development on paper, but there is nothing that can beat a Demonstrable Product, or a set of Features that comprise part of the last Product.

We found these books great for finding out more information on Agile Scrum:

Benefits Management – Prototyping, Piloting and demonstrations.

While EVA Analysis, CFDs and similar reporting highlights whether a Project is on Track, nothing engages the Stakeholders and Customers for the Product like a Demonstration of a Prototype or Pilot. Engagement is increased where they have a “hands-on” capability via a Test System. It can be anticipated that any pilot or mock-up of part or all of the finished Product will Give Rise to Changes, as the Stakeholders find flaws in their original Concept, or find Features that need enhancement through really using the Product.

Which Option should You Use?

If resource time allows, and it matches the Project, why not adopt all Three Approaches? The additional time invested on producing the Metrics may seem extreme if they have actually not been utilized before, however they add greatly to the Body of Knowledge within the Company on how Projects are Managed, as well as supplying vital details for any Project Retrospective. Promoting a discipline where these Techniques are used will also improve the ability of the Team members entrusted with Demonstrating Value to Stakeholders, in addition to providing early warning of Value Delivered slipping below Planned Value.