Metrics and Managers

Dan Greening gave an excellent talk about some aspects of metrics at the Scrum Gathering in New Orleans in early May 2014.  Go here to download his presentation: http://www.scrumalliance.org/courses-events/events/global-gatherings/2014/new-orleans-2014/presentations  (You must at least be a member of ScrumAlliance to have access to that page…sorry.)

Dan inspired me to discuss metrics.

First point: Managers like metrics.

This is a reality of life.  It is good and it is bad.  In any case, in large organizations initially, we must face that reality. And in almost every small organization as well.

If managers are properly trained, I think metrics can be helpful.  They must of course know that metrics are imprecise and can be ‘wrong’  (usually the metrics are directionally correct).  They must understand metrics are about the past do NOT predict the future very well.  But, they may give insight into the future, and can be useful if used with good judgment.

Motivation.  This is a key issue. There are many ideas and theories.  Whether good or bad, metrics usually have some impact on motivation. Obviously, we want it to be good (and to minimize any bad impact).  Because of this effect (and because the intended effect(s) is not always the real effect(s)), I strongly urge a significant discussion about the effects.  Let me, for now, put off a fuller discussion of this motivation issue.

Which metrics does Scrum give managers right out of the box?

1. Velocity

This is the average number of story points of work completed per sprint.

I won’t go back to explain story points from scratch, but assume they represent ‘units of work.’  And we average some reasonable number of sprints (3?), to smooth out the variability from sprint to sprint. (As managers, we should expect some variability.)

The velocity gives us an index of the productivity of each team.

This is useful in measuring improvements (ideas for fixing impediments).  We can say, “Oh, after we fixed that impediment, the velocity went up 2 story points….”  Or we can say “We have spent $100,000 on fixing impediments, the velocity has gone up 50%.  It has been well worth it.”

Velocity is useful for estimating release dates.  We can say: “Those features (stories) add to 36 story points of work, so it will probably take about 2 sprints to complete that release.”  (In my example, we have an average velocity of 20.)

Velocity.  Don’t leave home without it.

Equally, do not make velocity into something it is not.  It is more important to win the game than to score 100 points per se.  Use the stats, but only as a means to some real ends.

2. Sprint Burndown Chart

This is not so much a metric as a chart.  A chart built on numbers.

First, it represents a view of work remaining on each day.

There is debate in the community on how to do it, but let’s do it the old fashioned way (and the way I still recommend for beginning teams): based on hours remaining on the tasks.  (I have the new teams estimate ‘ideal hours’ for each task.  And they can re-estimate at any time.  As of 9am (or some hour they choose), we add up the hours remaining and chart that on the Sprint BD chart each day.

It forms a jagged line, as we connect the dots, day to day.

How does this help?

Well, it gives the WHOLE team some essential information… and that information enables them, as a team, to self-organize, self-manage, and self-direct.

For example, if they see they are in trouble, they might focus and fix impediments (more).  If they see they are ahead, they might take on another story (toward the end of the Sprint) or discuss how they might do another story.

How does this help a manager?  (By definition, a manager is outside the Scrum team.)  First, it SHOWS the manager the Team is using the information it has to build the Sprint BD chart.  Then, if the manager listens, he should hear them self-managing.  This is good, and it means he does not have to manage them at that level.  Over time, as he (or she) sees trends in the Sprint BD, he may notice some unusual situations.  Especially when the Team appears to be ‘in trouble,’ the manager can offer to assist with an impediment or two.

Note: Every company is different, and every manager is different. We are already discussing fairly specific situations.  Some managers, for a variety of reasons, might or might not get involved in these situations.

3. Release Burn Down Chart

Again, this is not so much a metric as a chart.  But a chart built on numbers.

Here, it represents a view of work remaining at the end of each Sprint.  This is work remaining to get the Release completed. Anything can change each sprint, so this is a new view at the end of each sprint, after all the changes, of the work remaining.

In this case, there is no debate about how to estimate this: use story points.  Well, not everyone agrees about story points, but the good agile people I know, prefer story points.

Note: there is some debate whether this should be a Burn Down or a Burn Up, with other details.  The Scrum Guide is vague about the format. It does say the Team should measure the work remaining, but it does not say how to show that measurement.  Jeff Sutherland tends to say ‘well, how about a Burn Down?’… so, I tend to agree.

OK.  So, in a ‘burn down’ chart, the connected points form a jagged line, as we connect the dots, sprint to sprint.

How does this help?

Again, it gives the WHOLE team some essential information… that then enables them, as a whole team, to self-organize, self-manage, and self-direct.  In this case, they are not managing success ‘in the sprint,’ but rather success over the release period (x number of sprints).

The expectation is that the simplicity and visual nature of the Release BD helps the team focus on the top impediments, rather than get lost in trying to fix a plethora of small problems. (The Release BD could lead the Team to address also other things than the impediments.)

How does this help a manager?

First, let’s assume the manager wants the Team to be successful.  Then, let’s assume the manager is reasonably balanced about how he or she defines success.  Mainly success means (IMO): the customer is really happy.  There is also some balancing of scope, date, and budget.  So, for example, not only is the customer happy, but firm profitability is also better.

Again, it is similar to the Sprint BD. If things are going fairly well, the manager does not have to do anything (maybe she can focus on a different team, one that is having some troubles).  Or, if things are unusual (either good or bad), then the manager can facilitate some learning about that.  For example, maybe the manager helps with impediments or gets others involved helping with impediments.  Maybe the manager asks this team (when ahead) to take on some extra work to help a related team that is ‘behind’ (according to the Release BD charts).

Over time, a manager will notice some common patterns to Release BD charts.  And will react appropriately when an initial ‘burn up’ happens (eg, not get over-excited).  And will similarly not get overly optimistic if the Release BD in the middle of the period suggests we are ‘ahead’.

With the Release BD, I hope each Team and  Manager will learn respect.  Respect for each other.  The manager respects that each team will be pretty good at self-managing.  And each Team will realize that a Manager can also be helpful, and will often have a wider of view of things (eg, the firm or the customers) than the Team has.

***

Obviously, there are many more metrics. No doubt some of you ‘always’ use other metrics when first using Scrum. But I consider the ones above to be the main three initially.  And I will discuss other metrics soon.

Comments please.

 

« « The Scaling Dilemma || What is a Real Team? » »