Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Measure Your Cost per Feature

DZone's Guide to

Measure Your Cost per Feature

Learn about the importance of knowing cost per feature as you develop an app, how to calculate it, and how it affects distributed teams in particular.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

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:

  1. For each team member, add all the weekly wages per person. Now you have the team cost for a week.
  2. Measure the number of features your team can release in a week.
  3. 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.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
mobile ,mobile app development

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}