Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Paying Contractors

Last post 09:35 am June 11, 2014 by Benjamin Korth
11 replies
05:13 am June 3, 2014


What is the best/fairest (to company and contractor) way to pay a contractor for a development project?

1. Pay by the hour
2. Pay per feature
3. Agree on a price for the project?
4. ?


05:23 am June 3, 2014

In my opinion it is pay per iteration. The customer (PO) can negotiate what will be done in each iteration with the contractor.
If the team size is stable, there is only a small difference to pay by the hour: In case of pay by the hour the contractor is motivated to do overtime which can make him less productive and decrease the value cost ratio for the customer.

05:26 am June 3, 2014

Ok thanks, and if the contractor does not deliver what was agreed within the iteration?

06:17 am June 3, 2014

In an ideal world, the contractor will value customer collaboration over contract negotiation.
This means, the most important thing when the sprint goal was not reached is to collaborate on how to improve for the next iteration.
You could think of a situation where the contractor is only payed if he reaches the sprint goal. In this case he would be motivated to set sprint goals which are not too challenging, and it might even be that the reason for not reaching the goal is missing feedback from the customer.
You could even think of a basis payment for each sprint (effort) and a bonus for delivered value (if sprint goal was met).

06:45 am June 3, 2014

It's generally best to fund the current Sprint up front and at the client's risk. This puts the onus on the client to de-risk delivery by collaborating via the PO throughout the Sprint, and to see early demonstrations. This is usually better than allowing a client to turn their noses up at an increment they have not been sufficiently involved in.

03:07 am June 4, 2014

What about dividing the risk, by having the client paying half the price at the beginning of the sprint, and half the price at the sprint review ?

04:08 am June 4, 2014

It's possible, but I'd have reservations about such an arrangement. A sprint should be short enough to be irreducable in terms of mitigating business risk. Or to put it another way, a sprint should be the smallest "chunk" of business risk that can be taken on and paid for.

If a client can only pay for a fraction of a sprint, I'd question whether the sprints are actually short enough to meet their risk appetite.

04:49 am June 4, 2014

I think what Olivier meant was that the client pays some price in advance for the sprint being executed, and another price at the end if the value is delivered. This is what I meant with basis payment and bonus.
In my opinion this can be a compromise between paying each iteration (regardless if value was delivered or not) and paying only for successful iterations where the committed value was delivered.
I have made good experience with time and material. If you are payed depending on the reached sprint goal, this might lead to heavy and time wasting discussions at sprint planning about what can be done in the sprint, and even discussions at the review about if the sprint goal was met.

05:34 am June 4, 2014

Well, the project is long enough for us to change the way we work. So we can start a certain way and if we find that its not working, we can then try a different route.

Setup is this.
DT are the contractors
UAT/PO/SM are the company
Client is,well, the client.

First option will be to pay per sprint as I feel that this will incentivize all parties, contractors, company and client, to perform their tasks/responsibilities at the highest level. DT will ensure quality and efficiency. SM/PO will ensure that that supply the right information and are always available. Same goes with the client, but they will also ensure that they are clear about what they want.

Might even try one or 2 sprints towards the end using NoEstimates.

05:49 am June 4, 2014

I'm not sure if having the PO and the SM on the same side is better than having the SM with the Dev Team.
Of course, having the Scrum Team tears in separate company is not the best case, so each option has some drawbacks.

05:53 am June 4, 2014

Agreed, but unfortunately in this case there is no other option. Luckily the relationship between contractors and company is very good.

09:35 am June 11, 2014

Scenario A Paying per hour:
The worst case is that the contractor makes overhour to optimize his cashflow.

Scenario B Paying per sprint:
The worst case is that the client asks for getting amount of work done and is less prepared for making compromises on reaching the sprint goal.

Both scenarios are resulting in overhours, but normaly the client has more pull. So I tend to recommend pay per hour and limit the work time.
The contractor is then not payed for overtime and has no reason to make it. The client has no (financial) advantage on insisting on the initial sprint Goal instead making compromises.

In my opinion making compromises and focus on the absolute necessary is the key benefit of working with scrum.

Kind regards

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.