4

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?

Miguel Stevens
  • 191
  • 4
  • What are you saying, the estimate of number of iterations required is too high, or you are putting too big a number into the 'number of people' field for some weeks? – Ewan Feb 22 '16 at 17:32
  • 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
  • Which actualy sounss about right, if you imagine all the delays and meetings that happen in a normal project. – Ewan Feb 22 '16 at 17:40
  • So you think it's okay to bill this much even when some people (like designers) won't be working on the project. – Miguel Stevens Feb 22 '16 at 18:01
  • 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
  • Note that the general company overhead (including general meetings for the team members) should be calculated in into the hourly rate. – Bart van Ingen Schenau Feb 22 '16 at 18:28
  • @noflip xan you clarify your question? Are the story point estimates accurate, ie. Are stories delivered in the expected time? Why are you counting the designers time if they dont work on the project? are you just undercharging for your current projects? – Ewan Feb 22 '16 at 19:24
  • Do the developers work on more than one project at once? do they record the hours they work against projects? – Ewan Feb 22 '16 at 19:25
  • @bart re meetings, i agree, i was thinking more of dead time waiting for stuff. Ie I might est 2wks to write a website, but really it will take 2days of work, 8 days of waiting for spec from customer and 4 days of weekends. – Ewan Feb 22 '16 at 19:30
  • 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 Answers1

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.

Barnaby Golden
  • 19,475
  • 3
  • 17
  • 50