Adopting Agile from a Cost Perspective
24 July 2017
When we talk about estimating the budget for any project, we know that one of the most important factors in deciding to start the project or kill it is cost. Cost estimation has always been an intriguing point of discussion, as there is no hard-and-fast rule for estimation. It's all about your way of thinking and management of cost estimation for an Agile project. Agile encompasses multiple ways of estimating cost.
Team allocation perspective
First, we'll look at it from a team allocation perspective. Agile teams are dedicated for the duration of the project, which means that everyone (analysts, developers, and testers) are 100% allocated to the project for its duration. So it should be obvious how to estimate the cost of an Agile project. We have static team compositions, and the team is dedicated 100% of the time; therefore, there is a fixed cost for the team per day, which also means that there is a fixed cost per sprint. The cost of an Agile project is then simple: the fixed cost per sprint multiplied by the number of sprints that we think the project will take to complete.
Now let's think from a client's perspective. Will the client agree on a fixed-price estimation, until or unless they have some output from their business perspective? So why not apply the time and materials contract here? The client will pay based on what we deliver. The rest is an internal calculation on what you charge for every story point, as the customer billing will be done according to story points.
Fixed-price work packages
While following Agile, we can't always adopt a fixed-price model for new projects, as the team's velocity changes based on its maturity and complexity of stories. You are not well aware of all the requirements right from the beginning of the project, as you would hope to be in a Waterfall scenario.
After completing a few sprints, you can apply the fixed-price model through fixed-price work packages. The whole project is broken down into logical "mini" releases that contribute to the full product outcome. Each release is a work package that is priced accordingly. As a work package is completed, future work packages are reestimated based on what we learned from the previous one. This avoids unnecessary contingencies and allows for a level of reprioritization and new or revised features to be defined by the customer.
Apart from smart and quick estimation techniques, a short implementation cycle also helps with saving the cost of implementation, even though 100% of the team is involved throughout the project. The team can be released early, as soon as the customer feels there is no further ROI to be achieved by retaining a project team that will continue if only to deliver marginal gains. The benefit for the customer is that the project will finish early, having delivered all the valuable features necessary to make the product viable. In some cases, even though the project cost is higher than in Waterfall, the value stream is also high and technical debt is low. So it's always recommended to adopt Agile. If sponsors are strictly concerned about cost and that is all that guides their decision making, then stick with a traditional model.
Agile provides tremendous value and not necessarily project cost savings. The quicker you are able to stabilize a product, the more you will increase the value stream for the business — a win-win for everyone involved.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 3.8 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.