Being Agile on a Fixed Cost and Timeline: A Case Study

Have you ever been asked to deliver a project using Agile principles (Scrum or Kanban) for a fixed cost? If not, I’m sure it is going to be a frequent ask in the future. Product managers all over the world are striving to finish projects on a fixed budget and timeline so they can launch their products early in the market. At the same time, they are looking for Agile delivery as it makes the project more transparent. When we go for Agile Development Methodology, we have to embrace change at all times. When the requirement is to execute projects for a fixed cost, with a fixed scope, and without compromising the quality, “embracing change” can be a real challenge. It’s like being caught in the “iron triangle.” But it is highly doable as the case study that I’m about to discuss here demonstrates.

Managing the iron triangle is a challenge for a fixed cost agile project.

More on the Case Study

This was a high-risk project that we undertook for a large US-based company. Needless to say, it was quite complex due to the magnitude of the work required, the constraints on the timeline and budget, and the strict quality requirements. Let me break it down for you here with some high-level details.  

Project Scope

As I mentioned earlier, the focus was to build the product on a fixed cost contract following the Agile development methodology. We had to deliver milestones within a fixed time frame with unwavering attention to quality. This meant embracing changes within fixed boundaries. We started off by documenting the high-level requirements from the client. Later, we translated them into detailed user stories for each phase based on priority.

Estimation

The epic or high-level user stories documented by the team was taken as an input for detailed estimation. Since the team velocity was unknown at the outset, estimation was primarily accomplished by breaking down epics into tasks and adding detailed estimates for the tasks according to their complexity. A percentage of the development effort was allocated for testing and user interface development as well.

Delivery Schedule

Delivery planning was the most critical step as it involved cracking the “iron triangle” of fixed scope, timeline, and quality. We identified the risks and conveyed those to the client along with our corresponding action plan for risk mitigation. Similarly, we took the overall estimate as an input to achieve optimal sprints and staffing, factoring in the initial velocity. The plan was to deliver the complete product in four phases within a year. Each phase consisted of four modules and each module was executed by an independent Scrum team.  

Execution

We on-boarded a “tiger team” consisting of the best resources to reduce the delivery risk. The team was a combination of back-end and front-end developers, UX designers, hands-on architects, business analysts, testers, and a project manager who also acted as the Scrum Master. We had multiple Scrum teams working on different modules in parallel and we had a Scrum of Scrums to coordinate dependencies between teams.  

We on-boarded the best resources to ensure high-quality delivery

  A total of 33 sprints were executed in 4 phases and 12 months. For easy collaboration with multiple global stakeholders from different time zones, we used JIRA extensively for user story documentation, communication, bug tracking, and sprint execution. Custom JIRA dashboards were utilized to measure key metrics on the current status of sprints, quality of deliverables, etc.    

The execution plan

 

Communication

We set up daily sync up calls with the client team to clear dependencies and communication bottlenecks. To appraise the client delivery head of the project status, we held weekly review meetings. Monthly calls were scheduled with the executive management team to discuss and close any escalation topics.

Key Metrics

Keeping the project on track also meant collecting the right metrics and monitoring them periodically. We borrowed a few best practices from CMMI Level 5 processes to refine our processes and ensure quality.   

Some of the key metrics we tracked were sprint burndown, velocity, and defect leakage.

 

• Sprint Burndown

During sprint planning, the team predicted the amount of work they can complete during a sprint. We utilized the sprint burndown report to track the completion of work throughout the sprint. This was a very important metric considering the fixed timeline defined for the project.

• Velocity

The average amount of work that we completed during a sprint was considered as the sprint velocity. Velocity was taken as an input to predict and monitor schedule adherence. We consistently measured the velocity and constantly monitored the productivity factor to make sure that the velocity improved along with the experience level of the team. 

• Defect Leakage

We tracked defect leakage and minimized the number of defects that are carried forward to User Acceptance Testing (UAT) at the end of each sprint. We conducted defect analysis and prevention meetings to formulate strategies for continuous improvement in quality. At the end of the project, we found that defect leakage had reduced as a result of various defect mitigation plans implemented.

The Result

We made it! With 33 sprints and a peak team size of 40 members, we successfully delivered the project in a little more than a year. A large part of the success was due to our team’s ability to continuously evolve and formulate optimal strategies that reduced delivery risks. As a result, all sprint releases were completed as per the plan with 100% schedule adherence and, of course, with valuable learnings throughout the journey. In the next part of this blog post, I will be discussing some of the key learnings from this project. Stay tuned!