Tommy Norman is an agile coach in Nashville and he recently posted the following on LinkedIn:

As a Product Owner, do you know how much it costs to run your team per week/sprint?

Having this information can re-frame many of your discussions. When talking to stakeholders you can ask questions like "That would take about 1 sprint, is it worth X dollars to you?". With your teams it can help them understand the impacts of process inefficiencies by showing them how much they cost the company/client.

It does not even have to be super accurate, just a decent representation of the cost. If you have a dedicated team, it's pretty easy. Get a blended salary across team members, add 35% for overhead costs, then figure out how much that comes to per day. Even without a dedicated team you can use rough percentages.

Knowing the cost of delivery is a good first step towards moving discussions next to value delivered and return on investment!

Ever since I read it, I’ve been thinking about the notion. Believe it or not, it’s not something that I’ve thought about much in my agile journey. And I’m stewing over the implications.

While I think it’s a good idea, it might have a Yin and Yang nature to it. Let’s noodle on each side:

Yin – It’s a good idea, great thinking tool

Wow, I can see where this idea helps to focus the decision-making around the team by stakeholders. What a great discussion point when ordering backlogs. Or making crucial investment decisions based on the team’s capacity.

I like the “sprintly” nature of these discussions. That is, talking about how much the team costs and breaking the work into sprints.

In one of the comments, Joe Little did the following back-of-the-envelope math:

If the total team cost is $1 million per year (for 7 people)... then the number is about $40,000 per sprint. (2 weeks) As you say, worth knowing.

Which is sort of the level I’m thinking that would be healthy to stay at. In other words, let’s not try to cost out individuals, or days/hours/minutes, or bathroom breaks ;-)

Yang – but it can be a dangerous exercise as well…

To be honest, I’m still a bit uneasy about the idea.

It’s not me personally. As a leader and coach, I think the value of knowing this and using it in decision-making is powerful. However, not everyone is like me ;-) And I’m thinking that it could possibly be accidentally misused or even intentionally abused.

For example, if folks take it too far in granularity, then the behavior might not be as positive. Examples of this would be the cost per person day, or cost per point, or cost per team hour. I’m concerned that measuring at this level could drive negative behavior on the part of leaders that creates the wrong behaviors within the team. Gaming behaviors, artificial compliance, and a lack of transparency come to mind.

Wrapping Up

I’m incredibly glad I saw Tommy’s post. It’s added a dimension to my thinking regarding Scrum teams, Product Owners, and value delivery that was missing.

Even with my reservations, I think this idea is worth a try in most organizations and teams. Here’s a comment from Chad Mullinax that captures my thought:

We did this during my time at CareerBuilder and found it to really reshape the conversations we had with stakeholders. We used job family median salaries along with a generalized cost of benefits per person to create a metric that applied to each team.

The KEY to me is the point about reshaping stakeholder conversations. Anyway, what do you think about the idea? And do you think it might fit into your sprintly views?

Stay agile my friends,

Bob.

Comment