Tag Archives: velocity

Can we PLEASE have some simple measures for our Product Development group?

Estimated Reading Time: 1 minute

A lot of our clients at AgileSparks ask us how to measure their effectiveness. Some of them are already using Agile styles of product development, others are not yet there, and another important variant is the Enterprise with mixed ways of doing things, that wants to get more visibility, and use measures as a way to drive towards improvement. 

As we all know, we need to be very careful what we measure, and on top of that a lot of measurements require a lot of work – and people don't really like to feel they are working for the measurements. They want the measurements to work for them. 

Be very careful of reports for Management that require the team/production floor to go out of their way. 

Having said that, ever since we started to focus more heavily on Kanban and Lean thinking, a couple of simple KPIs have emerged, with the added attribute that if you're already using Kanban to manage your work, you get most of them for free. 

Chris Hefley, one of the guys behind LeankitKanban, was interviewed recently to SPaMCast 100 (which is a very good podcast, worth listening to), and some of the discussion is around this point of Kanban providing great metrics that don't require any effort other than managing the work. 

I've been presenting these kinds of metrics to a couple of clients lately. Here is my presentation. Notice it mainly references Lean/Kanban concepts but doesn't describe them in detail. Go to www.agilesparks.com/kanban or www.limitedwipsociety.org for references to resources about those concepts. 

Estimated Reading Time: 2 minutes

Lately I’ve been trying to understand how best to represent Known Unknowns (KU) stories/tasks in the BDC. I’m talking about things like Support cases from customers – things not related to stories from the backlog essentially, that you know you will need to address.

Its the kind of stuff that “is not supposed to happen” as part of the sprint, but we’re in the real world, and in the real world, it happens.

I’m familiar with two major ways to account for those:

  • One is to remove them from the capacity. This removes it from visibility, OTOH it makes for a pure burndown/capacity/velocity calculation/tracking
  • The other is to create stories for those “buckets”. This way you can track them, have better visibility.

Assuming an organization is interested in tracking and measuring this part of the work, the team needs to integrate this into their burndown chart, velocity, etc.

The issue is that those tasks are sort of a “buffer for rainy day”, so the remaining effort on them as the sprint goes by is not necessarily related to actual invested effort compared to the whole bucket, but rather to time left where the events might happen.

Think support cases from customers – assuming you have a 30 day sprint. you planned on 20 days for the sprint based on yesterday’s weather. after 15 days, assuming you spent 5 days on this already, what should be the remaining effort for the BDC?
Naively, 20-5=15 days. But realistically, the statistics are that after half of the sprint, if your yesterday’s weather is to be counted on, 20/2=10.

Is anyone aware of any tools that manage these kinds of KU effectively without requiring the team/SM to manually update the remaining effort?

Together with some other coaches, we raised the option of drawing the planned work as an internal burndown line BELOW the total burndown. Another alternative was to show a burnup of this kind of work separately, so the team has visibility.

The idea is to make sure the team knows whether they got lucky and had more capacity left for their planned work, so should be more aggressive than their original plans, or the other way around. Without this kind of visibility, a critical aspect of the burndown chart is lost – teams don’t trust it, there is too much fog to see clearly where they SHOULD be so they don’t hold themselves accountable to where they ACTUALLY are.

Bonus question – do you have teams that count this work into velocity? using SP? How?

Note that the rationale for counting this into velocity is the “metric” side of velocity, not the planning aspect.

Its clear that this cannot be used to plan the release. It can, if you find the right way to account for it, reflect productivity of the team around this kind of work.