Using Story points for billing and the team size

Question

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?

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