Look for Predictability before Productivity for Agile Teams

Last week I proposed a productivity metric based on the proportion of a release that has been completed, accounting for story creep in the release.  Not all of our teams are using the version feature in Jira, but the several that are enabled me to perform a little analysis.  So far, I don’t think we have the maturity level required to make this metric work for us, but the data are instructive all the same.

Two teams in particular stand out.  Team 13 was our inital pilot team on agile, and they’ve been practising for about three years now.  Some of their releases look pretty close to what I expected from a productivity standpoint.   Here, for example is a five-sprint release that shows a ramp down at the end.  The last sprint only contributed small productivity because there was only one story left at the end to wrap up.

Team13R3.6

This made me wonder what was going on with their releases, and so, I mapped all of them, and I found a much more chaotic chart.  The chart below shows the raw number of stories completed in each sprint.  The different colours denote different releases (light blue stories have no release).

Team13Stories

Now team 13 actually has a legitimate reason to work on multiple concurrent releases: they manage change to multiple pieces of software.  So, my model would have to accumulate value produced across concurrent releases.  This analysis currently takes a certain amount of Excelling, and so, I looked at Team 12, which has only three releases:

Team12Releases

This is a chart of the proposed productivity metric for three releases.  As can be seen, each release kicked off with a killer sprint in which the team produced over ten per cent of the stories initially defined for the release.  Then a combination of deferred stories and probably bug-fixing killed them after that.  The result is a metric that is too unstable to provide feedback to the team.

Reviewing the shape of their velocity chart confirms the story and also raises some more questions and concerns.  In particular, this team’s velocity is too unstable to make for safe predictions.  So, while this productivity metric might be relevant for long-established teams with stable velocities, I suspect the majority of our teams need to concentrate on predictability first.

Advertisements

Tags: ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: