Can you combine fixed price and agile?

Digital Leaders
Apr 17, 2019 · 5 min read

Written by Roger Gibbon, Head of Delivery, Reed Professional Services

Many clients prefer fixed price outsourced IT projects to other contracting models and understandably so. It allows them to finalise budgets upfront, and transfer the inherent risk of IT delivery to the supplier. But with Agile methods for software delivery now commonplace, it poses the question whether this pricing model still applicable in an Agile world. Is it still possible for a client to fix costs and transfer risks to a supplier, whilst still retaining the flexibility and efficiency that Agile gives them? Roger Gibbon, Head of Delivery at Reed Professional Services gives his insights.

The Problem

Traditionally a fixed price development contract has actually meant fixed price and fixed scope . Requirements are defined up front, and a fixed price is provided to deliver them. Defining requirements up front in an Agile environment to doesn’t make sense. Agile is designed to allow us to ‘create’ software products iteratively and allow them to evolve with close collaboration between technical teams and product owners. When we have tried this traditional approach with our clients it has stifled the creative purpose of Agile, and time has been wasted managing inevitable scope change control. Luckily, this is not the only option.

So what do we need to do?

It is this flexible and collaborative way of working between the product owner and the technical team that is at the heart of Agile, and that needs to be retained when creating a Fixed Price Agile contract.

So how do we do this?

To give us the full picture, there are a number of factors that we need to determine:

We prefer to estimate in Story Points, rather than ideal hours or any other metric, as we find it speeds up the estimating process and also provides a better metric for the fixed price contract (other Agile estimating metrics can work equally well). It’s best to have reference user stories for effort and complexity comparisons so that everyone is estimating from the same baseline.

The ‘definition of also needs to be articulated in a clear statement, to define the criteria by which a story point will be assessed for completion. This forms the basis of a checkpoint at the end of each sprint, and creates a quality baseline for reference with the client, much like the Quality Policy in a waterfall approach.

Team Velocity, is the measure of how many story points a team can deliver within an iteration or sprint cycle. There are many factors that can affect team velocity, and the velocity will vary from team to team. Ultimately the best way to determine it is from past experience and historical metrics of the team. It’s important to get this measure right, so you should adjust it over time and from project to project, as understanding improves.

Let’s assume our Team Velocity is 50 story points per two-week sprint. If we know that the total story point count for the product backlog is 600, then we know it will take us 12 sprints, or 24 weeks to deliver. This then gives us the primary parameters for our fixed price contract. We can commit to deliver 600 story points worth of completed product over 24 weeks. So it is the total story point count (the ) that we use, rather than the user stories themselves (the . From this we can calculate our costs and determine a fixed price.

Crucially, if the client then wishes to add or change any of the user stories in the product backlog during the project, they can do so. Either lower priority stories can be dropped so that the total story point count remains at 600, or additional sprints can be added to increase the story point count. Contract change control is easy, because it’s simply a record of any story point count change and the associated cost change, rather than the constant update of scope items as we would have previously faced. A record of scope is still recorded in the product backlog.

Conclusion

Originally published at https://digileaders.com on April 17, 2019.

Digital Leaders

Thoughts on leadership, strategy and digital transformation…

Digital Leaders

Thoughts on leadership, strategy and digital transformation across all sectors. Articles first published on the Digital Leaders blog at digileaders.com

Digital Leaders

Written by

Informing and inspiring innovative digital transformation digileaders.com

Digital Leaders

Thoughts on leadership, strategy and digital transformation across all sectors. Articles first published on the Digital Leaders blog at digileaders.com