Cost Estimates for agile projects

Question

For Fixed Bid projects , the approach in our company is :

• The estimation is done for every user story in story points, and team has to convert those story points into hours.
• Once we find out the hours estimate, then we can arrive at the cost of the project.
• Hence, one approach is to run a sample sprint of one week, selecting a few features from the product backlog.
• If the team completes 50 story points in 250 hours, then each story point costs 250/50 = 5 hours.
• So if we estimate, overall, 1,000 story points, then the estimate of hours will be 5 x 1,000 = 5,000 hours.
• The team has to decide on the DoD (definition of done) before coming to this estimation.
• If we're billing $X for each man-hour, then the cost will be 5,000 x $X.

What do you think about this?

• Apart from this, other cost model is TnM(Resource based cost) which should be generally used but not always accepted by client.

Is there any other cost Model used by your company. Please guide?

Answer 1

What you described is the opposite of agile

If you follow this approach, you will be doing the exact opposite of at least two of the four Agile Manifesto values:

• Customer collaboration over contract negotiation: You and your customer will be bound tightly by the the contract scope. During the project if your customer thinks of a change that can accomplish the project goals much better, you will put them through the painful change control process of waterfall.

• Responding to change over following a plan: You will be forced to follow the plan because of contract terms. Also, your management will be watching the actual hours like a hawk and beating up the development team if they deviate by a few hours on one story from the estimated hours.

Instead I recommend the following approach:

1. Ask your customer to list their business goals.

2. Collaborate with the customer to write up the epics, stories and also the acceptance criteria to accomplish the above business goals.

3. Do your estimation in story points not hours.

4. One week is not enough to assess team velocity. You need at least 3 sprints. Keep stable teams and you can use velocity from previous sprints for this.

5. Calculate how many sprints it will take based on the story point estimation and conservative velocity.

6. Estimate the dollars per sprint based on the team size and draw up the contract to accomplish the business goals in fixed number of sprints.

7. At the end of each sprint, demo the working code to the customer and seek feedback. This will give an opportunity for the customer (and the development team) to make changes, if needed, to better accomplish the business goals.

8. Also, work with the customer to define a minimal product, that makes business sense, and roll it out to end-users (or a subset of end-users) early on. Once deployed, get feedback from end-users and revise stories accordingly.

In this model, you are collaborating with the customer and responding to change in an agile way. You work more as a partner of your customer and helping to accomplish their business goals.

Answer 2

I think you can safely skip the story-points-to-hours step and achieve a more accurate result. You calculate a cost per-sprint given your team (which by the way also gives you a cost per-person) and guess a reasonable velocity per-sprint. Then you divide the number of SP in total for your backlog for the guessed velocity. You don't actually need to have a cost per-hour, for it can be a misleading figure: people are not interchangeable cogs, adding X% more man/hours doesn't increase your throughput by X%, and the total effort for large/complex project is more than the mere sum of each person's particular task.

Answer 3

Converting story points to time is misleading, because the better you are getting with the project, the faster you deliver the same amount of points. For example, user story 'A' may be 5 points in the beginning, which you deliver 2 weeks, but after several sprints you are better and can deliver a similar story in 1 week. Although you delivered it faster, the story is still 5 points.

You can use velocity - which comes from story points - to figure out how many sprints you may use. If you have 80 points in your backlog, and your mean velocity is about 7, a sprint takes 2 weeks, you'll be finished in 12 sprints, which is 24 weeks. Make it 26 and you seems to be ok.

Story points are for figuring out issues and the commitment for a sprint. If you bill your customer, never use story points, because it may change, it is team specific, and your customer won't understand it. Use weeks, which you can get from velocity (again a term that has nothing to do with the customer).

Answer 4

In some companies, fixed bidding is completely separated from agile project management. As you rightly mentioned, at the moment of bidding it might be unknown who will be on the team, thus whatever is going during fixed bidding is far from being called "agile". Once the contract is won, you can manage the project using Scrum, total hours being the guideline (outer restraint), but never introduced inside the process. Once you start introducing hours and other fixed bid restriction into agile at whatever stage- it is doomed I am afraid.