Viewing entries tagged
metrics

QPPE Metrics Model – A Measured Reaction

Comment

QPPE Metrics Model – A Measured Reaction

First of all, it’s been far too long for me writing something about metrics. It’s one of those topics in the agile community that keeps on giving ;-) 

But I’ve been inspired (yet again) by an article that Anthony Crain wrote a while back on the topic. He introduced it as his QPPE Metrics Model, where:

Q – represents Quality,

P – represents Predictability,

P – represents Productivity, and

E – represents Engagement.

You can find the article here –

https://techbeacon.com/how-software-teams-can-measure-anything-qppe-metrics-model

I shared this article with my friend and colleague, Shaun Bradshaw. I’ve known Shaun for the better part of two decades and he’s my go-to guy when it comes to all thing’s metrics related. Here’s his initial reaction to the QPPE post:

Comment

3 Key Agile-centric Metrics

Comment

3 Key Agile-centric Metrics

My friend and colleague Shaun Bradshaw and I were coaching at a client recently. We started to have a conversation about velocity, not directly driven by the clients’ context, but simply in general.

Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management. And I was struggling to “get there”.

Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:

  • Velocity gaining stability over time (predictability, low variance)
  • And increasing over time (short-term burst)

As part of newly formed and/or newly coached agile teams.

Now I really get what he was saying. And I agree that teams in these contexts should be displaying activity and behavior towards those two results.

Comment

The Agile Project Manager—The ‘Essence’ of Agile Metrics

I’ve been struggling for quite some time figuring out the “essence of” agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

One thing I have discovered is that metrics need to be “different” in an agile organization or culture. Traditional measures don’t seem to work within agile teams—as I’ve often seen them to cause dysfunction (more on that later).

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning should we measure the processes (at the beginning or leading edge) or should we more so focus on the results & learning (at the end or from the trailing edge)? I’ll explore this more next.

Leading vs. Trailing Indicators

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?