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?


4 Answers 4


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.

  • 1
    Out of curiosity, in your experience, who pays for the 3-6 weeks while velocity is assessed? Oct 19, 2015 at 19:59
  • 1
    @JeffLindsey As I said above, you can keep stable teams and use historical data. You don't have to assess this for each project. Oct 19, 2015 at 20:02
  • What if you don't have this information? Also, what actual cost model layers onto this approach (the original poster's question) - how are costs done internally vs. relayed to the client, how are the payments structured, is it TnM + margins, etc.? Oct 19, 2015 at 20:10
  • 1
    Fixed price contracts are risky by nature. You should venture into it only if you have a reliable team with a track record. Oct 19, 2015 at 20:50
  • @AshokRamachandran You don't always have that luxury (to choose whether to venture into a fixed term contract or not). I agree that points to hours is going to be doing more harm than good to the Agile process. In this case you sometimes have to fall back on old-school estimation techniques and be willing to wear the risk. All estimation is imperfect, it just depends how much risk you're willing to wear.
    – mwan
    Oct 20, 2015 at 1:18

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.

  • You have asked to guess the velocity.Can you guide, how?We do not have velocity at the contract stage and the team members are associated after contract is won so what is the best way to propose this? Should we say that we need to have two separate contracts - one for establishing velocity and one after that ? Not sure if it will be agreed?
    – Roop
    Oct 20, 2015 at 10:07
  • 1
    If that's the situation I think that you at least need to have an idea of the profiles/skills to be involved and then ask some of your people fitting those profiles to do the exercise of estimating a possible velocity per sprint (if you also happen to have some people in mind is better to involve them soon enough). Those people are by the way the same who should be responsible of estimating the whole backlog in the first place... otherwise the whole exercise is quite doomed...
    – mamoo
    Oct 20, 2015 at 12:54

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).

  • We do not have velocity at the contract stage and the team members are associated after contract is won so what is the best way to propose this? Should we say that we need to have two separate contracts - one for establishing velocity-although you said it is not of client concern and one after that with complete plan? Not sure if it will be agreed?
    – Roop
    Oct 20, 2015 at 10:06
  • It is a bit risky, but you can check the previous velocities all over the company and find the most likely one, and use that one. Or, find a project that has similarities and use the velocity of said project.
    – Zsolt
    Oct 20, 2015 at 10:42
  • After you decided on how many weeks the project will take, how do you calculate the cost? Hourly rate for the whole team? Feb 22, 2016 at 16:48

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.