I work at a big corporation that is transitioning to Agile. I know this may come as a shock to my readers but yes it’s true! Although many small companies and start-ups have embraced Agile and Lean ways of working for many years now, big corporations specially corporation not focused on technology are just testing the water when it comes to making this transition. It is a big change for many people who’ve worked the same way for many years.
Given that my agile team is new and green I was thinking of ways to measure my team and be able to track the progress over each sprint. Here is what I’ve learned:
The main goal of an agile team must be to minimize output while to maximize outcome and impact
but what is the difference between output and outcome and how do you measure each?
Output vs Outcome
I’m reading the excellent User Story Mapping by Jeff Patton (a review soon to come) and here is how he describes the difference between Output and Outcome:
“Everything between the idea and the delivery is called output. It’s what we build, but while it’s necessary the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome. We want to measure what people actually do differently to reach their goals as a consequence of what we’ve built.”
Take a look at the image above for a moment and let it sink in. It’s crystal clear now isn’t it?
Measuring Team’s Output
At this post I’m only concentration on measuring Outputs like features, enhancements, requirements, specification within an Agile team. Measuring Outcomes is really about understanding bigger picture and product/market fit and I like to discuss it completely in a separate topic.
So here are what I learned:
For outputs the most common factor to measure is Velocity. Velocity is commonly referred to number of story points completed within each sprint; (and assuming this metric is not abused) it’s valuable as a predictive metric as it starts to normalize to show how much the team can produce in any given Sprint. The expectation is that over time an increased team velocity means shipping more features faster.
However in my company we are still limited to predefined timelines for enterprise releases (I know this is an almost non-issue for startups) so for my team’s Velocity doesn’t necessarily translate to stories completed and ready to ship. At this point all we can do it to bundle stories completed and mark them as ready to go per release.
Another metric that I found useful is the number of bugs generated during each sprint. Again over time we want to decrease this. My team is new to AngularJS and one thing that happened is that refactoring the code from one sprint to next broke a lot of things.
Another interesting point learned from Quora is qualitative feedback we get during Retrospective meeting and use those improve upon. Pick something to improve and track that for a few iterations to make sure things are getting better. Once things have improved stop tracking, and move on to the next pain point. Again in my team’s case we’re trying to see what are the ways we can get rid of mini-waterfall cycle we seem to get trapped on every time. So far we’re concentrating on two issues: 1) increase expertise in Angular by having Angular hours with other developers. 2) interchange roles and responsibilities of back-end API and gate-way/middle-ware developers.