Can you deliver a fixed price project with Scrum?
The short answer is yes, by embracing an agile approach using Scrum to deliver value early and quickly.
First off, it’s a misconception that any project can fulfil all of the requirements within an agreed upfront timeframe and budget. Waterfall projects are notorious for going way over budget and having delays that stretch into years.
You may have heard of the iron triangle or the project management triangle. The main idea is that a project is constrained by its Cost, Time and Scope of features. Changing one constraint requires changes in the others or Quality will suffer.
For instance, extra Time may be needed to complete the entire Scope which will increase the Cost. If neither of these is available, then Quality drops to rush through the release.
In traditional projects, the assumption is that all requirements are non-negotiable (fixed Scope) and the expectation is for the other variables Time, Cost and Quality to be flexible. Otherwise, it results in change requests to modify the Scope.
With Scrum Quality is fixed within the Definition of Done, so the only variables that can change are the amount of Time, Cost, and Scope.
All fixed-price projects are set to a certain Time limit because the Cost of the Scrum team per Sprint is a constant value. So once you determine a Sprint length you will know exactly how many sprints you have to work with. That leaves Scope then as the only variable.
The Product Owner will prioritise the features in the backlog, so the Scrum Team can decide on the best way to approach the work that will deliver a project’s must-have requirements early and de-prioritise bells and whistles which can be added later.
Agile approaches, including Scrum, evolved to solve the problems of delivering software through Waterfall projects, which enforce a heavyweight set of up-front documentation and processes, followed by months of development and testing phases.
Let’s go back to 2001 when the best minds in the field (including Scrum’s founding fathers Ken Schwaber and Jeff Sutherland) met over three days which culminated into what became the Agile Manifesto.
The values of the Agile Manifesto are
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Agile Manifesto doesn’t say you cannot employ those elements on the right-hand side, but we regard the values on the left more. Fortunately, Scrum is ideally suited to allow you and your team to follow these values and the 12 principles that support them.
Although it has been nearly two decades since the Agile Manifesto when it comes to the notion of a “project” many organisations still hold an older view more aligned to traditional Waterfall methods. A key process of which is a large, upfront specification that leads to a detailed project estimate and plan.
There are a couple of problems though with this approach.
The obvious one being the time it takes to deliver any product to the market is much longer than a more rapid iterative development cycle. In Scrum, the Definition of Done ensures that quality assurance, testing and user acceptance are all baked into completing each product backlog item (PBI). When a PBI gets completed in a sprint that feature is ready for production.
Secondly, I’ve never been involved on a Waterfall project that didn’t have scope creep or emerging requirements later in development. This can happen for a variety of reasons:
- The requirements were not fully understood when specified
- Technical complexity was bigger than anticipated
- Client changes their mind on what they want
- Market conditions change
The longer the project, the more likely this is to occur. This is where working to a Minimal Viable Product and delivering something earlier allows the project’s sponsor and stakeholders to gain feedback to pivot or adapt the scope to better suit the products’ intended customers. Understanding these customers and managing the backlog is a key part of the Product Owners’ role.
This, of course, requires organisational change and commitment to embarking on an agile approach to delivering a project. Customers and stakeholders must understand that they can create a wish list of wants, but that the Product Owner shapes these into the product roadmap.
The requirements, rather than being detailed months in advance, are fully understood and broken down into individual PBIs closer to the time they will be developed. Collaboration occurs between any domain experts, the Product Owner and members of the team. This reduces what would previously have been seen as “scope creep” and makes the cycles shorter between understanding the problem and developing the solution.
Scrum is a practical framework to create products in complex environments. Each sprint in Scrum is a potential release, whether it is shipped or not is up to the Product Owner and the Scrum team.
So what gets delivered at the end of a “project” — or more specifically a fixed cost number of sprints? A working product where the scope was updated & prioritised through ongoing conversations and customer collaboration.
