As Mark Kilby and I work on the geographically distributed teams book, I realized this morning that we need to define cost per feature.
I already wrote Wage Cost and Project Labor Cost and the management myth that it’s cheaper to hire people where the wages are less expensive. (It might be, but it might not be.) That’s because of the cost to create a fully developed and tested feature.
If your managers still think in resource efficiency instead of flow efficiency, they might not realize why they need to think about the cost of a feature instead of salary cost for specific people.
Customers buy and use features. What matters is the speed and cost of producing those features. The more WIP (Work in Progress) a team has, the higher their cost to finish a feature and the higher their cycle time.
WIP isn’t useful. Finished features, your true throughput, is useful. Here’s how you measure cost per feature:
- For each team member, add all the weekly wages per person. Now you have the team cost for a week.
- Measure the number of features your team can release in a week.
- Divide the wages by the number of features, and now you have cost/feature.
Here’s an example of a distributed team. There are five people on a team with these hourly wages of $75/hr, $60/hr, $50/hr, $30/hr, and $25/hr. Add all these together: $240/hr. Multiply by 40 and you have $9600/week.
Measure the number of features your team can release in a week. This team can release two features/week because they have too few hours of overlap.
Divide $9600/2 features, and you get $4800/feature.
What about another team? Here’s an example of a collocated team (all in the US): $75/hr, $75/hr, $60/hr, $60/hr, and $50/hr. That team has an hourly cost of $320 and a weekly cost of $12,800.
This team releases 4 features a week. Their cost to release a feature is $3200/feature because they have the entire week as hours of overlap.
(An aside: yes, you can game this measurement if you divide each “feature” into two features. I’m not talking about that. I’m talking about something the customer can use, not gaming the system.)
Collocated teams should have a lower cost per feature than teams who are separated by many hours of time zone. That’s because the separation increases wait time for the feature.
Does this mean I am against distributed and dispersed teams? No. I am against distributed and dispersed teams when managers assume they will save money. There are good reasons to use distributed and dispersed teams but saving money isn’t necessarily one.
Distributed and dispersed teams with many hours of overlap can create a collaborative environment in which they can be as effective as a collocated team. Cost per feature is often a function of too few hours of overlap.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Measure Your Cost per Feature Opinions expressed by Java Code Geeks contributors are their own. |
