Is it right to appraise Scrum members according to number of successful user stories completed?

Question

When my Manager told to team that "now onwards successful user stories will be considered for appraisal!"

We sat there for while shocked and that was one of the several jaw dropping moments he gave us :-)

We felt that was stupid idea, since this will ruin all concept and goal of agile development methodology.

Let me know what you people think? and how can we convince him?

Answer 1

Sandy, unfortunately your manager's statement is a classic misunderstanding of scrum in particular and agile in general.

The proposed approach kills collaboration and counters the principle of collective code ownership. User stories in agile (if it is a real agile) rarely get completed before being touched by multiple people. Also, you will have user stories from time to time that need swarming in order to be finished within the iteration. How are you going to all get that when the individual incentives are aligned 180 degrees in the opposite direction?

Your teams instincts are correct. What sources would I suggest in the short term for you to read as you brainstorm the response to your manager? Look at blogs of renowned agile experts like Mike Cohn, Martin Fowler, Elizabeth Hendrickson, Jurgen Appelo, Esther Derby and several others and look for articles about agile team organization.

Answer 2

My main objection to this method of assessment is that it can be an obstacle to co-operation between developers. I think that an important part of the productivity of a development team is the willingness of team members to help each other. As I understand the suggested scheme, it could lead to developers sticking with their own assigned tasks and ignoring other team members who are stuck and could easily be unstuck by a little assistance.

We are always looking for the contribution the programmer is making to the team and the business.

Answer 3

This is on a par to measuring lines of code, or number of bugs - but slightly more sophisticated.

At first glance there's nothing wrong with the measurement, but when you think about it you start raising objections:

• what about more complicated stories?

is the most obvious one that springs to mind - I'm sure there are others.

You manager obviously thinks this is a good idea, so you need to be careful that when you raise objections you can also present solutions. This solution might have to be a modification to his scheme rather than a new scheme.

So for example you might want to point out that someone who just works on "easy" stories will complete more than someone who works on a more "difficult" one and this might lead to a concentration on the less important aspects of the development. So one solution might be to consider the number of story points rather than just the number of stories.

Answer 4

I agree with ChrisF that this goes back to the same problem with any measurement. What you praise is what you get. There are always going to be people that game the system, whatever that system is going to be.

The only real effective method that I've found for rewarding programmer's comes with three steps.

1. Leads know and understand the abilities of the people on their team.
2. Managers listen to the recommendations of the leads for team members who aren't pulling their weight.
3. The team is praised as a whole for successful sprints.

The entire key is that programmer's are not cogs in a machine that can be 'tuned' by looking at statistics. The real people need to be examined and improved as whole and the team needs to be able to rely on each other in a cooperative, and not a competitive manner.

The poor performers on the team are given every opportunity for improvement and enrichment before they are considered to be let go. Ultimately, good programmers will thrive in this environment and the poor programmers, who refuse to be improved, will be let go.

Answer 5

Most of the time, User Stories are completed in a collective effort. This makes it virtually impossible to base individual appraisal on this metric.

The metric itself can be easily manipulated since the planning process is also a team effort and even sooner than later, the whole system gets rigged. That's definitely what you don't want in a people focused process.

I think good performance has to be recognized by some kind of bonus system based on team success, but User Stories are not a good indicator of success.