Skip to main content

Transitioning to Story Point estimation when company bills by the hour

Last post 06:48 am December 7, 2018 by Simon Mayer
3 replies
06:35 pm December 6, 2018

I recently moved to a company that provides our clients with estimates (in hours) for how long various work will take. There are no plans to shift this way of thinking and fund teams by sprints instead of specific pieces of work - working to change that though. Estimates in hours are rarely accurate and having worked in other companies where we (very successfully) used Story Points, I know how much more efficient estimation becomes and how much simpler it can be.

Has anyone had success in transitioning teams to estimate in story points even when a lot of our contacts/SOWs are driven by hours? How were you able to satisfy hours driven contracts BEFORE the work has been completed?

Any help/suggestions would be GREATLY appreciated!


09:34 pm December 6, 2018

What does the client get out of having quotes in hours for each piece of work?

I have no experience in this but have an idea.

I would frame the suggestion to move to story points in benefits to the client:

  • Estimates in hours are highly inaccurate.
  • Features can be compared to each other easily so the client can make decisions about prioritisation
  • We can use historic velocity to provide a long-term estimate for the contract/SOW

If they want a dollar value for a specific set of features, you could provide a cost per sprint, then use the estimated velocity and story points to provide a cost for the contract.


10:03 pm December 6, 2018

There are no plans to shift this way of thinking and fund teams by sprints instead of specific pieces of work

A Sprint is a specific piece of work.

Do the team actually provide an increment each Sprint? If so, how close do those pieces of work get to being "done" and of release quality?


06:48 am December 7, 2018

Does the team work exclusively for one client for the duration of a Sprint? If so, as Ian points out, viewing a single Sprint as a billable unit of work may be best.

To work reliably, and ensure the continued purchase of more units of work, it would be essential for a Sprint to result in a "done" increment.

It could be that your company would need to adjust its relationships with clients, in order to support this. Perhaps it should.

In any case, estimates are merely educated guesses. With complex products, there are usually multiple factors that render any estimate inaccurate. There is enough documented evidence of this, that there is no excuse for expecting estimates to be wholly accurate. Your company might consider embracing the uncertainty of estimates. This could be done by managing customer expectations, managing a steady delivery of value that can be inspected by the customer, or accepting that billing based on estimates will often result in making a loss or greater than expected profit on certain units of work.

In order to resolve the problem, make it transparent. Use the vast resources on the internet about why estimates in hours are a terrible idea. Make the empirical argument that estimating in hours is costing the company money, and/or damaging customer trust.

Hopefully this will be the incentive to improve. If in the face of such evidence, the management do not wish to change, perhaps meaningful improvement is unrealistic.


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.