3

I'm learning a lot about Agile, I'm working in a small web development company. The one big issue remains: Billing

For example when working in story points, We can calculate that the team has a velocity of 20 storypoints / week (iteration).

Now to calculate the project cost we could measure the hours per week and multiply by price so we would get

money = <hours/iteration> * <no. of iterations> * <people> * <hourly rate>

But since the general way of working is a website gets designed first by the designers, and then developed, it's not realistic that the whole team will be working on the site at all times.

When I calculate the price using the above method our web projects come out as 5x the price they are now.

Does anyone have experience with this?

  • 1
    It sounds like the team may be upping thier estimates to take account to 'out of sprint' work on other projects. Thus the estimate is correct, but they spend 80% of thier time not working on the sprint. – Ewan Feb 22 '16 at 17:35
  • 1
    @Notflip: No, it is not right to bill your customers for hours that are not spent on project-related work. If you find that the team is not focused full-time on the project, then you should add a "focus factor" (percentage of time that the team is actually doing project-related work) into your money calculation. It sounds like you might end up with a focus-factor of 20%. – Bart van Ingen Schenau Feb 22 '16 at 18:27
  • 1
    My estimate will be acurate in terms of deadlines, but inaccurate in terms of billable hours – Ewan Feb 22 '16 at 19:31
  • 1
    Possible duplicate of How to estimate a project budget using story points? – Todd A. Jacobs Feb 22 '16 at 21:37
  • 2
    You're having problems because you're trying to apply team- or iteration-based cost estimates to a project that's really tracking matrixed resources. You can't do both at the same time. Either the whole team is working on the project, or you have partial allocations. The latter isn't agile. – Todd A. Jacobs Feb 22 '16 at 21:40
1

A common practice in Scrum is to break stories down in to tasks. It is also not unusual for teams to do time-based estimates on these tasks (this is particularly true of teams that are relatively new to Scrum). They do this for the following reasons:

  • Thinking about the time required to do a task helps the team to understand more about what is involved in the work
  • Putting hours against tasks helps the team to not over commit any one discipline (for example, ensure the QA isn't going to be overloaded)
  • A lot of teams like to keep tasks to a small size, say less than 6 hours

Note that the time-based estimates are not being used to work out the capacity of the sprint. The capacity of the sprint is still being calculated using story points and velocity.

Now if you use this approach, you would be able to provide a price in a similar way to the way you were using previously. This price will not be exact, as it is likely some tasks will take more/less time than was estimated. But it will be a lot more accurate than your current approach.

An alternative would be to get the team members to log the time they spend on each client's project. This is going to be the most accurate way to measure the actual time spent and billing will be very accurate. The downside with this approach is that you introduce the overhead of recording time, which reduces the time the team will spend delivering value and may also irritate them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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