Benefits Realisation within Scrum Projects

This short article will take a look at Benefits Realisation. The alternative methods to Measure Benefits within a Scrum Project will also be discussed. First we would like to briefly go over the Benefits Management Process.

Benefits Realisation – When should the Expected Benefits be Defined?

The discipline of Benefits Realisation Management (BRM) is relatively new. It is however still not practised as commonly as it ought to be. The reality that a Project has been brought in on time and within budget used to be identified as a Measure of Project success. The real markers of success are typically understood months to years after a Project is finished. For instance, if one of the Criteria for success was a boost in the Customer base of 20%, this is unlikely to happen on Day 1 (unless you are J.K. Rowling). To assess medium to long-lasting success, we require to Measure results in a Programme. The Programme encompasses a number of Projects, and continues Measuring for success after the Projects have been Closed Out. The definition of the Value of the Product and the Project, or Projects, should happen before the Project starts.

With BRM in place, Stakeholders will have determined a list of expected Benefits. Additionally there will be a timeline for each Benefit throughout the Development of the Concept and Business Case. These are measurable Benefits that can be Measured using typical Concepts like percentage growth or reduction, Changes in amount or financial Changes. These Values will be assessed at routine pre-defined intervals based on the milestones on the timeline. This does not suggests that Project Value is ignored during the Project. There are a number of Techniques that can Measure and report on Project Value at any point in time. This is not a “how-to” on the methods, but an illustration of how Project Value can be evaluated.

Evaluating the Value Accruing in a Scrum Project

As a Scrum Project uses Value-Based Delivery rather of the Conventional Plan-Driven Delivery. There is often the mistaken belief that Project progress can not be Measured using Conventional Methods. Even Plan-Based Projects need 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 on 3 main parameters. The nomenclature has actually altered – we show the old terms in brackets:-.

-‘ PV or Planned Value’ (formerly BCWS-Budgeted Cost of Work Scheduled).
-‘ A.C. or Actual Cost’ (previously ACWP-Actual Cost of Work Performed), and.
-‘ EV or Earned Value’ (formerly 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 carried out. In Conventional Projects this would be the Work Breakdown Structure (WBS); in Scrum 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. It is typically called a “Burn-up Chart” due to the fact that it mirrors and complements the Burndown Chart.

Learning from Lean – the Cumulative Flow Diagrams.

The essential word in the phrase Cumulative Flow Diagram is “Cumulative”. This is a rising graph, that has a lot in common with EVA and measures:-.

  • Tasks That Have Been Completed (or “done”).
  • Work That Has To Be Done (i.e. the material of the Product Backlog).
  • 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 system that helps align Customer Expectations and the Scrum Team (Scrum Master, Product Owner and Development Team) is the Development of a pilot or prototype. Charts and figures might illustrate development on paper, but there is nothing that can beat a Demonstrable Product, or a set of Features that comprise part of the end product.

Practical Approaches to Benefits Realisation – Prototyping, Piloting and presentations.

While EVA Analysis, CFDs and comparable reporting illustrates whether a Project is on Track, nothing engages the Stakeholders and Customers for the Product like a Demonstration of a Prototype or Pilot. It can be expected that any pilot or mock-up of part or all of the completed Product will Give Rise to Changes, as the Stakeholders discover defects in their original Concept, or discover Features that require improvement through actually using the Product.

Which Option should One Use?

If resource time allows, and it fits the Project, why not adopt all Three Approaches? The additional time invested in producing the Metrics might appear excessive if they have not been utilized before, however they add greatly to the Body of Knowledge within the Company on how Projects are Managed. In addition they provide invaluable details for any Agile Project Retrospective. Promoting a discipline where these Techniques are used will likewise improve the skill sets of the Team members entrusted with Demonstrating Value to Stakeholders. In addition they offer early warning of Value Delivered slipping listed below Planned Value.