Is it a good idea to show a 'story points by developer' graph at retrospectives?



  • I am part of an agile team in a large organisation. At our fortnightly retrospective a graph is shown of how many story points each developer has completed over the course of the fortnight.

    We are not 'shamed', if the scrum master wants to ask why we are not completing as many points as others it is done privately and the team is generally friendly and helpful.

    I think when tasks have high estimates developers rush to allocate them to themselves quickly (myself included!). I feel that jobs which do not earn story points like doing code reviews, dealing with technical debt and helping other developers are suffering as developers don't want to look bad in the retrospective.

    Is it a good idea to show 'story points by developer' graphs at their retrospectives? What about allocating story points to tech debt / reviewing / helping others so 'helpful' team members do not lose out on the story point metric?



  • TLDR: The team should be a team.

    We are not 'shamed' [...] developers don't want to look bad

    See the problem here?

    Whether or not your developers are being 'shamed', your developers are afraid of being shamed. That's not conducive to productive work.

    Is it a good idea to show 'story points by developer' graphs at their retrospectives?

    There is a 99% chance the answer is 'no, all that's going to do is make your developers feel less like a team and more like competitors'. There is a 1% chance the answer is 'yes, your specific company has a bizarre reason for this, so make really darn sure you communicate that bizarre, specific reason to your developers so they don't feel like they're not a team.

    You're probably in the 99%.

    What about allocating story points to tech debt / reviewing / helping others so 'helpful' team members do not lose out on the story point metric?

    Your reasoning, so 'team members do not lose out', indicates the toxicity alluded to above. There could in theory be other reasons to do this, but I would caution against it.

    Story points are a measure of velocity/throughput. If you're spending all of your time on cleaning tech debt/review/bugfixes/etc, then you're not getting any direct business value done, and so your velocity should be zero.

    Which makes sense. If I were questioned about such a situation, I would answer "Yeah, we're cleaning up the mess created earlier from when we had to rush things through. We have to stop our throughput for now to avoid it slowing to a crawl permanently".

    This is fine because, again, you shouldn't have individual metrics. So it's not Alice 'getting stuff done' while Bob 'cleans up crap'. It's the team 'getting half as much done as usual because it has to clean up crap'.

    Do not pit your developers against each other. That's a recipe for failure.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2