Yup, you know it – clients want agile development.. Why? Umm.. cos that’s the only thing that makes sense.. BUT they also want fixed cost projects. Can you really blame them? Do you not ask your contractor how much it’s going to cost to fix that roof? Yeah, I know – whatever the contractor says.. it ain’t gonna be more than that 🙂 We constantly have to fight this battle ourselves – I am sure you do as well.. Share your experiences with us!

How to do agile development in fixed bid projects?

We all know that agile development methodologies have become an alternative.. wait no.. THE alternative to traditional project management. This methodology focuses on developing software in an incremental and iterative fashion where design, implementation, requirements and testing continue throughout the project life cycle. Quite apt for our clients and very well fitted for new product development.

Meanwhile, fixed bid projects are a part of the culture of many companies. Many hold the opinion that agile development cannot be employed in fixed bid projects. Yup, we had scratched our heads with this one as well..But the reality is that you can implement agile development in fixed bid projects provided there is a variable scope. (Fixed Cost, Variable Scope). Here’s how we do agile development in fixed bid projects.

Defining Product backlog size before starting the project

It is necessary to analyze enough user story (some call them features) details before estimating the project. It is necessary the programming teams collaborate with the customer to get better understanding of the user stories. Both parties should reach a mutual agreement on “Definition of Done” for individual user stories, sprints and releases. We typically nominate one person as the product owner from NisosTech – that interacts with the product owner from our client’s side.. The entire development team considers the NisosTech product owner (most times, that’s me) as the “client”.

Some of our clients hate them – but we kinda force them to jot down the user stories with us AND agree on success criteria before we even begin with the project. We strongly believe that chasing a moving target ain’t good for our customers nor is it good for us. So, while a sprint is going on, we hold steady on the stories.

Use MoSCoW principle to prioritize

The team uses/should use MoSCoW principle to prioritize features that need to be included. In general the “must have” features should not exceed 60%. It is a good idea to include healthy number of “Should Have” and “Could Have” features to ensure scope can be varied. It is necessary to have clarity on the minimum scope for the product to be useful.

Move from Fixed Scope to Variable Scope

Agile development, of course, calls for variable scope in fixed bid projects. For example, if the project has 2000 story points, the variable scope will allow the team to replace existing user stories with new user stories that are somewhat similar. While doing so, the accepted change will always be within predefined boundaries that is 2000 story points.

Use Exchange model to accommodate changes

Agile development is feedback driven. The customer comes up with new requirements due to changing business concepts which leads to change. The new requirements are translated into user stories. In agile development, you can adopt an exchange model for user stories in the product backlog. In this methodology, the customer can introduce new user stories of high business value and remove user stories of less business value provided the team has not started working on the user story. Adopting the exchange model ensures the product backlog remains constant despite introducing new features at any stage of the development cycle.

Setting right expectations at the beginning

In agile development for fixed bid projects, you need to set expectations around customer satisfaction right from the beginning. The Agile Product Owner should understand his responsibility towards prioritizing the backlog. As an owner, he/she needs to have a vision for the product. The Agile PO should be available to answer any questions from the team and also actively participate in sprint review. The product owner needs to be business savvy as he/she is the person who is taking decisions on what features the product will have.

In a fixed bid project, the schedule and the cost can be regulated but the scope greatly depends on the customer influence and hence it need not be fixed. The best practices mentioned above sheds some light on how to do agile development in fixed bid projects. Agile fixed bid projects can be successful and feasible if the development team defines product backlog, leverages MoSCoW technique and implements user story exchange model.


Your thoughts?