Get certified - Transform your world of work today

Close

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.



Article Rating

Current rating: 3.8 (4 ratings)

Comments

Krishna Ajjampur, CSM, 7/25/2017 12:07:07 AM
How did you do the estimation and pricing model? Is it per sprint or story points? You said after 2 or 3 sprints you provided the budget what happened incase you missed delivering the story point? did you have to absorb the cost?
Subhash Pandey, CSPO, 7/25/2017 1:05:24 AM
If you read it carefully, I said agile is a maturity model. Team or the process associated with project gets mature with time. So in initial phases of the project(1st or 2nd sprint)estimations can go wrong and that's why the concept of reprioritization arises at any point of project delivery.
Business has nothing to do with your sprint or release(structure), they are more concerned about the business value(Story point).
Tim Baffa, CSM, 7/28/2017 10:18:07 AM
It is an incorrect practice to utilize story points as a measure of value delivered. Story Points only have relevance from a planning perspective, to allow the team to assess what can be completed within a sprint, and for the Product Owner to asses what may be achievable within a specific time frame. It is an effort-metric only. Completion of story points do not equate to delivery of value, they just equate to "getting stuff done".

The main benefit of an Agile approach is early and frequent delivery of value to the customer, as opposed to a traditional waterfall approach, which operates under the illusion that everything can be identified up front before work begins.
Subhash Pandey, CSPO, 7/31/2017 1:35:01 AM
There are many myths in our mind regarding artifacts of agile or any methodology as still we are not mature enough to identify what's the basic and easiset way to deliver maximum business value. we try to create maximum interfaces to loose the alignment between business requirement and delivered product by creating the process more complex. Why story point is only required for planning why not business value can be directly related to this. Even after adopting agile, we are still in the mindset of traditional approach. Agile was adopted to reduce planning and process and focus on delivery. But still we are creating multiple plaaning steps and interfaces, I think we're better to go with waterfall. With agile we are heading towards waterfall approach as we are again very much definition bounded.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe