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 talk more about 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 it is the reality, I think, in even in almost every small organization also.
And, if managers are properly trained in managing, I think metrics can be helpful. They must of course know that metrics are imprecise and can be 'wrong' (although usually they are directionally correct). And they must understand that metrics about the past do NOT predict the future. But, they may give us insights into the future, if used with judgment.
Motivation. This is a key issue. There are many ideas and theories, but I think we can say this at least. Whether good or bad (or both), metrics usually have some impact on motivation. Obviously, we want it to be a good impact (and to minimize any bad impacts). 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, with the right people. Let me, for now, put off a fuller discussion of this motivation issue.
Which metrics does Scrum give the managers right out of the box?
1. Velocity
This is the average number of story points of work completed per sprint.
I won't here go all the way back to explain story points from scratch, but assume they represent 'units of work'. And we average over some reasonable number of sprints, to smooth out the variability from sprint to sprint. (We, as managers, should expect some variability.)
And the velocity gives us an index of the productivity of each team.
And 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, but from that 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.
2. Sprint Burndown Chart
Well, this is not so much a metric as a chart. But 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. And, as of 9am (or some hour they choose), we add up the hours remaining. And chart that on the Sprint BD chart each day.
And 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... that then enables them, as a whole team, to self-organize, self-manage, and self-direct.
For example, if they see they are in trouble, they will focus and fix impediments (more). If they see they are ahead, they might take on another story (toward the end of the Sprint) or talk about how they might do another story.
How does this help a manager? (By definition to me, a manager is outside the Scrum team.) First, it SHOWS the manager that the Team is using the information is has, to build the Sprint BD chart. Then, if the manager listens a little, he should hear them self-managing. This is good, and means he does not have to manage them at that level. Then, over time, as he (or she) sees trends in the Sprint BD, the manager may notice some unusual situations. Especially in those situations, or especially when the Team appears to be 'in trouble', the manager can know when to offer to help 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. In part, one wants to know: what is this manager trying to manage? In any case, we are not addressing these detailed issues here.
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 in the community about how to estimate this: use story points. Well, as you know, not everyone agrees about story points, but all 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. And maybe some other details. The Scrum Guide is vague about the format. It does say that 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 go that way.
OK. So, in a 'burn down' chart, the points connected form a jagged line, as we connect the dots, sprint to sprint.
How does this help?
Well, 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).
For example, if they see they are in trouble, they might focus and fix impediments (more). Or remove stories from the release. If they see they are ahead, they might take on additional stories (probably more toward the end of the Release period).
We certainly hope 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.
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. It mainly means: the customer is really happy. And it is some balancing of scope, date, and budget. So that, for example, not only is the customer happy, but firm 'profitability' is also seen to do up.
So, again, it is similar to what we said before for the Spring 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 the discussion to lead to a better outcome. 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 we see an initial 'burn up' (ie, 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'.
And with the Release BD, we hope each Team and each Manager will learn respect. Respect for each other. The manager respects that each team will normally 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. And, in any case, the Manager can be helpful in removing impediments.
***
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 we will discuss other metrics soon.
Comments please...
No comments:
Post a Comment