Knowing When You Release Value
Knowing When You Release Value
There are already a ton of metrics associated with Agile development, but consider adding an evaluation of value to your scorecard.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Sometimes, teams have trouble releasing their work, showing the value of the work they've completed. There are many possible reasons for this release problem:
- The team doesn't have sufficient working agreements about what "done" means. I've written about frictionless releasing. In Create Your Successful Agile Project, I wrote about the done, done-done, and done-done-done words we sometimes hear.
- The team works on huge, gigantic feature sets where they have to finish "all" of it to release any of it.
- The team depends on another group to release. They can't release to customers on their own.
- The team has interdependent features, and they can't release anything until the other team(s) has done their part.
I use the term "feature sets" for a reason.
When we talk about "an epic" or "a theme," we hide the bigness of the thing we're discussing. I started with feature sets when a client used two different tools across a program, and the definition was not consistent across the tools.
I realize I have not yet converted everyone to the language of feature sets. I can wait.
One team has a problem with a gigantic feature set, about 50 stories. The PO thinks this feature set has to be complete before the organization can take the risk to turn it on. The team has worked on the feature set for the last three iterations and they are still working on it.
Their management wanted to know when the heck this feature set would be done. The team showed them their version of this board and explained their cycle time. Of course, on their board, they had about 20 items in Waiting for Release. The team thought they might have another three iterations before they could release the entire feature set.
That's a long time to wait to see the value.
The good news is that showing the visualization of what was done but not released got everyone's attention.
Measuring done is a piece of what we need to measure. Measuring value is another piece. Measuring what remains might be another piece.
I happen to like also measuring the frequency with which we release. (Not when we can, but when we do release. Do we release once a quarter, once a month, once every two weeks, once a week, more often?)
All these things: what's done but not released, the last time we released, and our cycle time helps us know the answer to the question, "How often can we release value?"
Published at DZone with permission of Johanna Rothman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.