I’ve been working with Val Fletcher on an initiative as part of the Intelliware Project Manager’s Group to standardize how we estimate, cost and plan projects. The first thing we’ve done is attempt to define all of the ?buckets? where time is spent on a typical project at Intelliware. Time, of course, translates directly into cost.
Here’s a summary of all of the buckets that we’ve identified and what they mean. I’ve included a high-level diagram at the end.
- Story Development Time ? This is the biggest chunk of time on any project, as it should be because completed stories represent the value that we deliver to our customers. We determine time and cost for a project based on the estimates provided by the technical team and an assumed velocity in points/pair/week. The estimates are based on ideal time, that is the amount of time required to complete coding the story and writing unit tests assuming no distractions.
- Story Overhead Time ? This bucket includes activities that are needed to complete stories but are not included in the ideal time estimates. This includes such things as build maintenance, tasking meetings, design discussions, standup meetings, etc. We don’t calculate this time, it is built into the Story Development time by the fact that we typically use a velocity of less than 1 point per pair per week when we calculate the time required to complete a project. The lower the assumed velocity, the more this component is assumed to contribute to overall project time. We typically use velocities of 0.66 to 0.80 points/pair/week, depending on project complexity and other factors that I’ll touch on later.
In Extreme Programming Explained: Embrace Change ? Second Edition Kent Beck admits that he prefers to use real time estimates instead of points now because this makes ?all communication as clear, direct and transparent as possible?. However, we still like to use points because they’re a good high level abstraction for making estimates and we have gained a lot experience with doing estimates this way over the last six years we’ve been doing XP.
Story Development and Story Overhead time comprise what we think we know about what the customer wants.
- Billable Non-Story Time ? This is time that is also needed to complete stories, but is sometimes estimated and billed separately. This includes code drops, launch/deployment support, startup preparation, etc. How we treat this time affects the assumed velocity; generally on projects where we cost these tasks separately we can get away with using a higher velocity for calculating Story Development time.
- Overhead Time ? This time includes a project manager and other roles, depending on the project and the client. This time is calculated separately based on a fraction of the total Story Development time. For example, assuming 0.25 FTE (full time equivalent) for a Project Manager is typical for a smaller project.
Billable Non-Story and Overhead time represent additional costs that are needed to complete Stories. Story Development, Story Overhead, Non-Story and Overhead time represent the Planned Billable time for a project.
- Project Contingency ? This represents a variable amount that is ideally based on the project risk, typically 10-20% of the Planned Billable time. This is an additional amount to cover possibilities that we’re worried about but can’t ascertain, and we don’t use it without first obtaining approval from the client. We don’t consistently include contingencies with project estimates, but this is something that we would like to do more of in the future. However, first of all we need to get better at defining project risk and equating that to costs; more on this later.
- Project Overruns ? Overruns are usually the result of scope changes, technical glitches and other things that we didn’t anticipate when we developed the project plan. Of course, we try very hard to keep these costs to a minimum. Overruns may be billable or not, depending on a number of factors.
- Non-Billable Work ? This includes warranty fixes, proposals, technical spiking efforts and numerous other things that we can’t bill for. Again, we try to keep the time spent here to a minimum.
We still have much work to do to further define these buckets and develop a standard method for determining project time and costs. In future entries I’ll elaborate more on specifics for each of the buckets.