I have had a lot of conversations, with agile people and not, around the topic of measuring success of an agile team. I have heard all sorts of metrics thrown around, from velocity, throughput, number of bugs or lack thereof, and so on.
The fact is that those metrics are completely useless, let me tell you why.
Imagine that your team in a period of 3 months has increased its velocity from 24 to 48. What does that mean? Some people will tell you they are 100% better or even 100% more successful!
I say that they are 100% better at delivering stories (assuming they didn’t game the metrics)
More than likely they work in an organisation that measure success based on the old Budget-Time-Scope paradigm.
Unfortunately in your search for speed you are sub-optimising your system and not achieving the real goal of your company.
What is a successful team?
A team is successful if they help the organisation they serve be successful, regardless of how many story points they deliver.
Let me tell you what a successful team measures.
A successful team measures business outcomes. What are business outcomes? Let me give you some examples:
1) x% increase week to week on downloads of your mobile app
2) y% increase in signups month to month
3) z% reduction of customer support calls month to month
or any similar outcome depending on your context where x,y,z>0
Why?
Because an organisation that obtains those outcomes is normally successful.
Even more importantly, the team will continuously monitor how their actions affect the business outcome metrics they have set to achieve so that they might decide to:
- Stop writing that feature, we have obtained the result and any further bell and whistle wont give us ROI
- Do more of this, the metrics are going in the right direction but not as expected
- Stop doing this and do something else, this feature is not producing the results we were expecting
- Ah, look at what the customer is doing instead of doing what we thought he would do! Let’s help them do it in an easier way…
Now compare this to delivering all the 1 zillion stories in the fixed scope at the velocity of 48 per sprint.
What’s a successful team for you?
mysoftwarequality 
You make two points that I’m big fan of:
First focusing on delivering business value. When we focus on delivering business value, especially if we use smaller stories we find that more than a half of our stories bring little or not value.
Second we need to work with the use to move away from delivering solutions to yesterday’s problem to delivering solutions for tomorrow problems.
Thanks for your feedback tuckerplace.
And yes, both points you make are fundamental in my thinking
Very well summarised tuckerplace
Excellent article Augusto – this is what we see today, agile teams continuously improving(velocity, DoD, burn downs, planning and so on)
But – where’s the focus on improvements for the customers? and for the company? A customer doesn’t care if we work agile, our velocity,… – as long as our work procedures do not provide earlier deliveries in better quality.
I think currently there’s often an internal view of “being agile”, trying to apply Scrum, Kanban correctly, partially almost dogmatic. But an agile company focuses on quick solutions that reliably work – in the perspective and judgement of the customer. An improved customer experience, with agile approaches as a “tool”, that’s the name of the game. That is probably the more difficult thing behind an agile transformation.
That’s why one probably needs more an agile culture – if this is set up with Scrum and its predefined roles, or Kanban or whatever else is 2nd priority, 1st is to have more satisfied customers – since these will come back.
Thanks for your Feedback Marco!