Focusing on product advancement instead of the development team performance

Even though cycle time is a good metric about team’s peformance, as I described in my previous post, all stories and features that a team is delivering should be validated by the Product Owner (or Product Owner team) once they are in production. This validation should check if the stories and features just delivered made the product advance in the way it was expected.

But what is this product advancement thing? Well, it depends on your product’s context. Better yet: it depends on your key performance indicators (a.k.a. KPIs). A product is advancing if it is improving its KPIs. As an example, if your KPIs are pageviews and number of subscribers, then your product advanced only if the delivered stories and features increased your pageviews and number of subscribers. This post describes a very good way to define your KPIs. This book is also a very good reading about how to define your product’s advancement metrics.

My point is that many companies are more concerned with their teams’ capacity: how many story points a team can deliver or how long is a team’s cycle time. But they should be more concerned with their products’ advancement! A team’s capacity is only a mean for achieving something greater: product advancement. And product advancement is achieved only if the right stories and features are being prioritized.

What do you think? Makes sense?

The “Agile Inquirer” origin

Today I’ve decided to finally start a blog. The idea of this blog is to be a collection of short, direct and objective posts about agile software development. I’ve chosen this title according to this definition of the Cambridge dictionary:

inquiring
always wanting to learn new things, or (of someone’s expression) wanting to know something:
You have a very inquiring mind, don’t you.
He gave her an inquiring look.

And following the short, direct and objective directive, this post ends here.