How to Write a Fixed Price Agile Contract
If the whole idea of Agile is that you cannot predict the future, then how can you use it in a fixed-price contracting environment where it is vital to tie down your costs, your time and your scope? Maybe the answer is to look beyond tying Agile down to ill-fitting contract templates and introducing a new structure.
OK, so the fundamental thing that we can ascertain from everything we read about Agile is the fact that the requirements do tend to be very wooly. In contrast, the fixed-contract model demands a detailed, stable, and accurate set of requirements, clearly defining boundaries and penalties if anyone steps foot outside.
How on earth can two so contrasting animals exist in the same environment? There is so much debate as to how it can be done that to cover every idea, thought or feeling would take dozens of articles. I think my best approach is to put down my experience and how I go about setting up an Agile contract.
At the very start of tackling the issue of Agile and fixed-price, it was imperative to set out a logical and professional structure to the process. I have so often seen presentations where the agency has offered an obviously fudged approach and there was absolutely no way that the project could commence, yet alone complete. My advice to any agency contemplating working in the Agile fixed contract market is to spend time setting out your pricing, timing and scoping approach. A rushed job stands out a mile.
So how do we approach a fixed-contract proposal? The first thing that we did was to look at the Agile process that we undertook and break it down into three distinct areas. Each of these areas we then spent a lot of time defining and writing down clearly and precisely the what’s and how’s. For us it opened up a completely different structure to our organization and potentially added new revenue streams.
Time and cost within a fixed-price contract are reasonably easy to define and for Agile’s time constrained iterative approach it is very easy to define; it therefore only leaves us with the issue of scope. How could we tie down what we were delivering without choking the Agile methodology that we so proudly follow? The issue was to change the concept of scope into one of budget.
The very first step was to capture the user requirements in the form of a product backlog by using user stories to trawl through the customer expectations. We then use the product backlog to prioritize and then estimate the features list using group techniques such as planning-poker and enumerate values in the form of story points.
Moving this process forward we spend 1-2 days defining:
“The user story is a way of expressing requirements that are understandable for both clients and ourselves. User stories are quick to write and will get all levels of the organization structure involved. They are, most importantly, feature oriented, so they can provide a good view on the real scope of a project and we can compare them with each other in terms of size, effort”, etc.[1]
For estimating, we tend to use story points as opposed to ideal days (I discuss these in my article on burndown charts). It is very important to ensure that you make clear the definition of “done” and that you have an explicit and concrete statement that forms a critical checkpoint of an agile project. Without a consistent meaning of done it will be impossible to estimate velocity accurately. “It is also a way to build trust with the client by having a common consensus as to the project process and a high-level acceptance criterion.”[1]
At this point we can now come up with a value defining our scope budget in points. It is this value, not the stories, which are fixed in the contract.
With our scope defined we can now concentrate on setting the price and time and to do this we need to look at Team Velocity, how many points can a team achieve during an iteration.
Team velocity is based on many factors, not just how much work they can do. Our working practices already define our communication strategy and we therefore know how much time is spent in planned meetings with the team and the client. There are other factors to consider such as holidays, volume of tasks, etc. At the end of the day velocity will be a figure that is partly based on experience but contains a lot of guesswork—if it is winter there, you can be sure that someone will have flu.
Let say for example we have calculated that the team can deliver 30 story points within a 2 week iteration and there are 240 story points to deliver (now defined in the contract). We now have a delivery date of 8 iterations making 16 weeks in total. With 70 hours allocated to each iteration, a team of 5 and an hourly rate of $100 for each team member we can easily calculate the price at $280,000.
So now we have our fixed contract values:
These values are just part of the contract pricing procedure but they do tend to be the most difficult numbers to arrive at with any confidence.
What we were trying to show here is that the way we work in Agile projects can be transferred also to the contract negotiations environment.
… the product owner (client) wants to add another feature? This is a simply addressed by the fact that we have already worked closely with the client, defining the product backlog, estimating story points and therefore he knows the current situation. When adding additional work we estimate the addition, let’s say 10 story points in this case, and we negotiate to either remove 10 story points worth of features or add another iteration. Now that we have the scope points fixed we can now allow for changes to occur, in terms of points. This allows us to exchange requirements along the way within the defined scope limit. If we can stay within that limit, we can also stay within the fixed price and time.
… the customer complains about the price? We make it very clear to our sales teams that the only negotiation in this situation is the hourly rate. We do not compromise the project by increasing the velocity. You cannot change your team into super-heroes by changing values on a piece of paper.
Once you have the contract signed and the work is under way it is imperative that you manage your costs. In my article on burndown charts I discuss how these can be used to monitor team velocity, they can also be used to monitor change to scope and costs.
One of my specialist areas is Agile Fixed Contracts, writing and presenting on the subject on a regular basis. Please keep this article bookmarked as I will constantly be adding new material and references.
For additional reading, please check out my Guide to Agile Project Management.
How to Write a Fixed Price Agile Contract
Research & References of How to Write a Fixed Price Agile Contract|A&C Accounting And Tax Services
Source