Viewing entries tagged
agile metrics

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

2 Dozen – Wild & Crazy Agile Metrics Ideas

6 Comments

2 Dozen – Wild & Crazy Agile Metrics Ideas

In our latest Meta-Cast, Josh and I went through a couple of questions from the audience. One of the questions surrounded what to measure for individual developers. To be honest, I was taken aback by the question. 

You see, I’ve been preaching for years that when you move to agile metrics, you want to do four things:

(One) Move from individual team member metrics to a more holistic, whole-team view.

(Two) Move from measuring functional teams, for example test team progress, again towards holistic, executing agile team view.

6 Comments

Waste...Is it Good?

1 Comment

Waste...Is it Good?

The other evening I attended a presentation on agile metrics by Larry Maccherone of Rally Software. It was a great presentation. But he said something along the way that has been bothering me since. Let me try to get you in the right place by setting the stage a bit.

He started off by saying the agile metrics in general are “Context Based”. That is, your business space, problem domain, company maturity, technology stack, size and maturity of your team, etc; ALL come into play when determining your metrics. I guess this implies a one-size-fits-all approach doesn’t work and, in fact, that there is a unique size per agile context.

He had me at hello with this one.

1 Comment