Benefits in Agile Projects

Agile is fast becoming the preferred way to deliver IT projects. This growth is an indicator that needs are changing and the way we deliver projects needs to change too. But how does this affect the role of benefits management?

Traditionally, large projects followed a linear, step-wise approach often referred to as ‘Waterfall’. This approach typically suited large government clients as it focussed on the ‘process’ and worked towards an ultimate deliverable which had a full suite of functionality. Usually, the process started with a Business Case, followed by Project Planning, Initiation and Delivery. This suited Benefits Management as there were clear check points along the way that where benefits could assist. For example, the Business Case would give a detailed explanation of the proposed project with different options costed and benefits analysed. Upon initiation, benefits would work closely with the project to refine the benefits, identify metrics and plan for go-live evaluation.

This meticulous planning did not always lead to project success. Some issues that can arise are:

• Difficulty/reluctance to change scope – even if that is what the product owner asks for

• Performing the bulk of testing towards the end of delivery may require significant re-work

• Difficulty with governance having oversight over how the project was truly progressing

Agile moves away from painstaking forward planning to one which acknowledges that things change, and projects need to react to this change is a productive way. Analysis, design and coding are continuous and iterative activities, and the focus is on first delivering the ‘Minimum Viable Product’ (MVP) which is a product with just enough features to satisfy early customers and provide feedback for future product development.[1][2]

But Agile is not just about analysis, design, coding and delivery of the MVP. Similar to the best practice culture of benefits management, Agile has its own culture and associated rituals to ensure projects successfully deliver in an innovative way. Some of these rituals naturally align with benefits.

Agile Rituals

Sprint Planning - The Benefits Manager can add value to this stage by helping the team identify the user stories prioritised for build. At the beginning of a project the influence of Benefits is minor because the delivery team will most likely have to focus on building the foundational technology. It is usually later in the project life cycle that more tangible benefits are demonstrated in the user stories and functionality delivered by the project. The Benefits Manager can work with the Product Owner to prioritise the user stories. Using a benefits led approach they may focus on delivering the following examples of benefits:

• financial benefits to enhance the case future funding and investment in the project

• quality and safety benefits to enhance the health of a population

• compliance benefits to meet legislative requirements

• staff satisfaction benefits to retain and support their workforce

In reality, the benefits led approach to sprint planning will hit different types of benefits and may also be influenced by other factors such as the requirements of the governance committee and political factors.

Daily stand-ups – The technical team uses these to discuss their progress and blockers, they are usually very technical, and it is unlikely that benefits can assist with this process.

Sprint Review/demo/showcase – By reviewing the work delivered in the sprint the technical delivery comes to life and the Benefits Manager can evaluate see how the technology works in real life. The product owner usually participates in the sprint review and together with the Benefits Manager they can evaluate if benefits are on track to be delivered.

Retrospectives – The technical team evaluates whether there were any ‘lessons learned’. Similar to stand-ups they are quite technical and benefits don’t need to get involved.

Agile Tools and Documents

User story template - This is one of the most useful agile documents for a Benefits Manager as the user stories summarise the product features that add value to the project. The Benefits Manager should review the stories to ensure that they are not focussed solely on the delivery of technology but also reflect how the delivery will enable benefits.

Velocity chart template - The velocity chart should be monitored because it is a measure of how many story points are delivered in a sprint. If velocity is lower than expected it is likely that the delivery of benefits is being constrained.

Burndown chart - The graphical representation of how many stories have been delivered, and how many are outstanding, over the course of several sprints is a further demonstration of how benefits are being enabled or blocked.

Agile Roles

High level approach to Benefits Evaluation in an Agile Delivery Environment

Business Case (BC)

Even though Agile is a way of delivering projects that is dynamic can quickly adapt to change, it is likely that the project would have first gained traction several months or even years earlier as a Business Case. A key element of a BC is an exploration of the options and associated benefits. At this early stage, the proposed delivery method does not affect benefits. Therefore, Benefit Managers should adopt their preferred approach to identifying project benefits and demonstrate the results in the templates used by their organisations.

Project Initiation

Upon acceptance of the BC and project initiation it is usually known HOW the project will be delivered. It is important that the Benefits Manager carries forward the benefits from the BC to project initiation, whatever the delivery method. It is highly likely that as the project progresses the expected benefits will change and transform. Again, this usually occurs whatever the delivery method because at the time of writing the BC some information was unknown.

Upon project initiation the Agile team will be planning how to deliver a minimum viable product (MVP) which demonstrates that the technology they have built works and delivers value. The team will break the entire project down into small pieces of functionality (user stories), prioritise the user stories and then plan to deliver the stories in short time boxed cycles called sprints.

At this stage the Benefits Manager should evaluate the sprint plans against the proposed BC benefits and validate whether they are on track to be delivered. Next, the Benefits Manager can commence mapping user stories to specific benefits within the BC Benefits Framework. The mapping can be enhanced and illustrated via a Benefits Dependency Map which links the stories to benefits.

It is possible that the delivery of user stories leads to new benefits being identified, and on the flip side, it is also possible that some of the BC benefits may not be enabled. It will be important for the Benefits Manager to document and justify how the BC benefits have changed and adapted in line with the planned Agile delivery. This helps to ensure that the governance of the project maintains ‘line of sight’ from the business case to delivery and helps maintain confidence in the delivery of the project.

Project Delivery

The scrum master is the leader of the Agile team and will direct and manage the team to ensure that the delivery is on track. A key advantage of Agile is that it becomes clearer much earlier in the project lifecycle if delivery is lagging behind the plan. In Agile terminology this refers to velocity. Velocity can be demonstrated in the velocity chart and burn down chart.

At the end of each sprint cycle the user stories will be demonstrated in sprint reviews and the product owner will be able to provide feedback to ensure the stories meet requirements and deliver value. The feedback will be evaluated in the planning stage of the next sprint. It may be decided to deliver the feedback straight away, or instead be put on hold and progress to the next user story. If the feedback delivery is put on hold this forms a part of the product backlog. The backlog will continue to be reviewed at future spring planning sessions.

The Benefits Manager should play a key role in the feedback that is provided at the end of the sprint reviews and which recommendations are allocated to the backlog. In particular, the practical demonstration of the user stories should prompt the Benefits Manager to check that the technology demonstrated:

1. Is creating a foundation for the enablement of future benefits, or

2. Providing the first baby steps towards delivering actual benefits

As more and more sprints are delivered and demonstrated, it is expected that the project moves beyond creating a foundation for future benefits towards enabling the delivery of actual benefits.

During this time the Benefits Manager will continue with best practice benefits management methodology. A key task will be updating the Benefits Register to provide detailed information about how the benefits will be measured and communicated upon go-live. The Benefits Manager should also work with the Scrum Master to ensure that the technology has the required in-built audit and reporting capability which may be required for future benefits evaluation.

Project Go-Live

An Agile go-live is different to a standard waterfall project because the user stories have all been demonstrated and tested and may have already been incrementally released. A final working product is thought to be the ultimate measure of Agile success. However, a working product which delivers benefits is a better goal for projects to aim for. Once the Agile team has moved on to the next project, the Benefits Manager executes the Benefits Management Plan, primarily via collecting and analysing the data specified in detail in the Benefits Register and communicating results.

References

1. "What is a Minimum Viable Product (MVP)? - Definition from Techopedia".

2. ^ Jump up to:a b c Ries, Eric (August 3, 2009). "Minimum Viable Product: a guide".