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

Question

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?

Answer 1

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.

Answer 2

TL;DR

Your organization is fundamentally misusing the story point metric, and also conflating story points with velocity (which is also being misused). Please stop doing those things before you destroy your team cohesion and invalidate the potential effectiveness of the metrics that you could reap if they were used properly.

Story Points Reflect Relative Effort for the Whole Team

Story points are useful for creating estimated of relative effort, but "relative" simply means in comparison to some baseline work item. A 5-point story is theoretically interchangeable with a pair of 2-point and 3-point stories, but in practice all all you're really saying with the point system is that the team thinks the 5-pointed story will consume roughly five times the effort (and available team capacity) of a 1-point story.

Well-written stories are not individual tasks. They should be thin, vertical slices that help the team make progress towards the Sprint Goal. As a result, the best stories typically involve multiple team members, so the notion of individuals getting credit for story points likely indicates a foundational problem with the way user stories are being written in the first place.

In addition, the goal of a Sprint is not to fill it up with story points. The goal of a Sprint is to complete the Sprint Goal. That's actually the key measurement your organization should be tracking: is the Scrum Team meeting the Sprint Goal more often than not? And by extension, is the Scrum Team delivering Product Goals within some reasonable delta of the estimated number of Sprints? These are team-based metrics, not individual metrics, and that's quite deliberate. Scrum is a team sport; you gamify it or use it to track individual "productivity" at severe peril of undermining the integrity of the estimation and planning process, as well as the coherence of the team.

Velocity Reflects Team Capacity, Not Productivity

Finally, a word about velocity and story points. Velocity is primarily a trailing metric that relies on consistent estimation to predict capacity, although it is also somewhat useful as a forward-looking capacity planning estimate. When you gamify velocity by trying to treat it as an individual productivity metric, you basically undermine the reliability and utility value of the metric. Management is also often tempted to treat increasing velocity as a performance target, but that is yet another anti-pattern since the goal of velocity is to stabilize to increase the predictability of the delivery cadence.

Your goal should never be to maximize story points or velocity. Instead, you should be using them to optimize your team's sustainable and predictable cadence, and as a sanity check against taking on more work in a Sprint than you have capacity to complete. They are most useful when applied to the following question:

Based on our story estimates, do we have sufficient team capacity based on our historical velocity (adjusted for various fudge factors that affect the current Sprint) to confidently deliver our Sprint Goal on time?

If you are doing anything else with your story points or velocity besides using them to right-size your Sprint Backlog or assess the likelihood of meeting the current Sprint Goal, then you are Doing Scrum Wrong℠. This is likely driven by upper management's ersatz adoption of agility and lack of understanding of how to properly leverage the framework. It's also being driven by the relative inexperience of the Scrum Team (and especially the Scrum Master and Product Owner) with the framework, and this shows most clearly in the team's difficulty managing the interface between the Scrum Team and the rest of the organization.

Answer 3

I worked in an organisation some years back that decided to try and do performance reviews based on the number of story points delivered by individual developers.

It was a complete disaster: the output of the team dropped dramatically. Developers were purely focused on doing the stories they were assigned and they stopped helping each other.

There were a number of other issues, including:

• Developers would stop working on stories that were taking a long time to complete and as a result they often ignored some of the highest priority work
• Story point estimates became like political negotiations
• Some developers didn't report bugs they found as it would have slowed their rate of story-point delivery

The organisation quickly realised its mistake and dropped the approach.

Answer 4

The purpose of the Sprint Retrospective is for the team to "plan ways to increase quality and effectiveness", and this is done by inspecting the last Sprint in the context of "individuals, interactions, processes, tools, and their Definition of Done". There are any number of tools, techniques, or pieces of information that can help the team carry out the Sprint Retrospective. The team is free to choose how to achieve the purpose, and the Scrum Master is there to guide the team on their continuous improvement journey.

Does the team believe that spending the time and effort to produce a graph or chart showing how many story points were completed by each developer would help them find opportunities to increase quality and effectiveness? If so, then it may be worth running an experiment for at least a couple of Sprints and seeing if it helps the Sprint Retrospective. If not, then it's not worth it.

However, I do see some potential areas of concern with the plan.

First, individuals working on things alone tends to be an anti-pattern. It doesn't promote the cross-functional, cohesive, self-managing team that is central to Scrum. If the team is currently working together on work items, there needs to be a plan to make sure that everyone's contributions is considered, not just a single person who may be "assigned" to the work item in some tool. If the team isn't working together collaboratively, you'd probably see some gains if they were. Focusing on building a collaborative team would be more useful than gathering individual performance metrics.

Second, once you start collecting data, it often becomes harder to keep it contained. If your organization does individual-based performance reviews, this kind of data may be useful to managers as part of that process. If you aren't collecting it, it could be easy to explain why you aren't and why it's not worth the time to collect. However, once you start collecting it, it becomes harder to not share it. This entrenches the organization into thinking about individuals and output rather than teams and outcomes.

Third, it sounds like your process doesn't currently estimate every piece of work. If this is working out for you, that's good. However, if you need to mitigate some of the problems around getting visibility into collaboration, it sounds like you'll have to increase the effort put into estimating work. More effort put into estimation means less effort for other things, including delivery.

Is it a good idea? I'd generally lean toward "no". However, like most things, there isn't a one-size-fits-all solution. Scrum not only allows for iteration on the product, but the processes used to build it. You can run experiments and see if they are beneficial to the team or organization. If they are, you can keep them. If they aren't, you can drop them. You can also reevaluate past decisions at any point in time.

Answer 5

I find it difficult to see a business purpose for this kind of statistic: presumably, all of the developers are "on the same team." It should be entirely natural that different people focus on different concerns fairly-fluidly at different times. Therefore, I see no positive benefit for presenting this measurement, and possible unwanted social-dynamics effects within the team that might well be caused by doing so. Therefore, I wouldn't do it or advise doing it.

Answer 6

Statement #1: Story points is not a measure of individual contributor productivity.

Statement #2: Story points are a relative effort & complexity measuring tool.

Now some people infer from the above statements that since a higher story point means more effort and/or higher complexity, the developer who works/delivers it is "better".

Story points was never meant to measure individual productivity / experience. It was meant to be used determine velocity which helps in project delivery & timelines because effort & complexity involved software development projects vary from team to team. I've worked in 7 member team delivering 140 story points / sprint while another 12 member team delivering 30 story points / sprint. Both projects had developers with overlapping skills and experience, but the requirements of projects and the estimation done by developers were completely different.

Sprints allow you to timebox the development and velocity measures the output in each sprint. If managers start diving into why velocity has reduced / increased from a developer's productivity perspective; then that perspective needs to be repositioned. Increase / decrease in velocity is due to teams understanding of effort & complexity of the work that they are taking up. So if it changed then it means the team considered that the new requirements require more/less effort than previous ones and/or have lower/higher complexity than previous ones. That's it.