How to Show Your Value

A new ScrumMaster wanted to know what to do with a 20 point story that wasn’t complete at the end of an iteration. I explained to her that the story and its points move to the next iteration, but she wasn’t happy with the approach. She wanted to divide the 20 points between the current and next iteration. It was the only story in her iteration and she didn’t want to end up with an iteration with zero points.

“I’m having a hard time getting past this. Are you saying I have nothing to show for this iteration?”

What a telling phrase: “nothing to show for it”. Let’s dig a little deeper into that question: What does she want to show? How does she want to show it? Who does she want to show it to?

Of course, what she was trying to say was, “I want proof that the team did work this iteration.” She’s having trouble getting past the fact that we’re not measuring output, we’re measuring outcome. That means we don’t measure the hours we worked, we measure the value we delivered. Every practice and ceremony supports this paradigm. Check it out:

  • What do you want to show? Completed features, not completed tasks. If you want to end the focus on time tracking, you have to stop talking about effort and start talking about features. Either you did or didn’t deliver a feature. Whether you spent 80 hours or 8 is irrelevant.
  • Where do you want to show it? At the iteration review, not on the project status report. The iteration review is your opportunity to show the value you provide, literally. You should rehearse and polish your demonstration before inviting everyone to see what you’ve made – it’s your opportunity to impress your organization. If you do that, your stakeholder meetings become a matter of formality.
  • Who do you want to show it to? Product stakeholders, not your boss. You should be more worried about whether or not you’ve delivered value than if your boss knows that you’re actually working. In fact, if you’re working but not delivering delivering value, you must be pretty ineffective. You don’t want to show that to your boss. If you’re delivering value, obviously you’re working. Who needs a timesheet to prove that?

This is a difficult leap for organizations to make. It’s second-nature to assume that hours worked equals productivity. The organization won’t change until the conversation changes. So stop talking about hours worked. Stop talking about maxed-out resources. Start talking about value delivered. If you keep talking the language of features and business value, eventually those around you will to. If everyone around you is talking about value, your organization has made the shift.

If you’ve found ways to change the conversation, I’d love to hear it. Hit me up on Twitter at @johnkrewson.

This entry was posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Agile Velocity, Iterative Development. Bookmark the permalink.

5 Responses to How to Show Your Value

  1. John Hunter says:

    Readers may find this old post of mine on outcome and output measures useful

    http://management.curiouscatblog.net/2008/07/14/outcome-and-process-measures/

  2. John Krewson says:

    Such a good distinction between output and outcome, thanks for the link.

  3. Robin Berger says:

    How do we get people to be interactive in retro meetings. We have tried a few things, no winners yet.

    • John Krewson says:

      Have you looked into why they’re not participating? Are they afraid of repercussions or just disengaged? The first step is determining the source of the silence. If they’re silent because they don’t care, then perhaps there are other issues at play throughout the sprint. If they hesitate to speak up because they’re afraid of being labeled or punished, you may want to look into facilitation techniques like Innovation Games, developed specifically to address that issue.

  4. Robin Berger says:

    Thank you John, I think it is a little that they are not seeing the value and perhaps a little on the repercussions. Today is our retro, I am planning to take one of the Agile Values: Respect: and see if I can’t get that to engage them in telling us one thing they respect about the team in this last sprint. Maybe if I can draw some possivtives out of them, they will be more enaged. I think they do not want repercussions of the failures. I have noticed that our team tends to find them as a sore point instead of a learning point. This is the first retor that I will lead as we have 3 scrum masters and it is my turn. Wish us luck.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>