Are story points achieved a good individual quarterly goal?

Question

Our company is starting to set quarterly goals at a more individual level. For many engineers on the team, these goals will include product impact, automation and code coverage, new responsibilities, etc. I am considering working with individuals to set quarterly story point goals as well. On the surface, this makes sense: as a team quarter to quarter we're always trying to improve velocity, so it makes sense to attempt to improve velocity at an individual level as well.

However, I have reservations (... as evidenced by the fact that I'm asking a question on Stack Exchange... :) ). Completing stories is generally a team effort and relies on different roles within the team (engineering, design, QA, etc) coming together, so the goal isn't entirely within an individual's control. I also wonder if setting these individual goals creates a bad culture within the team where people are optimizing for individual story point credit rather than total team accomplishments or velocity.

Does anyone have experience in this kind of set up, or have knowledge on whether it's a good idea or a bad idea?

Answer 1

Your question already contains a lot of answers :)

However, I have reservations (... as evidenced by the fact that I'm asking a question on Stack Exchange... :) ). Completing stories is generally a team effort and relies on different roles within the team (engineering, design, QA, etc) coming together, so the goal isn't entirely within an individual's control.

Indeed, and that's for a reason, you want people to work together towards a common, shared and valuable goal, not an individual goal that trumps the common one (being able to produce x story points per quarter).

I also wonder if setting these individual goals creates a bad culture within the team where people are optimizing for individual story point credit rather than total team accomplishments or velocity

Yup, that might well be the case. When forced to do so, people choose themselves and their interest over the others... there's no point in helping my colleagues if this stifles my goal of reaching x story points/quarter. Since anyone will be evaluated (and maybe rewarded?) against their story points, my story points obviously come first ;)

There's another interesting remark in your question:

as a team quarter to quarter we're always trying to improve velocity, so it makes sense to attempt to improve velocity at an individual level as well.

Just make sure that velocity is treated for what it is: a meta information, that is an indicator that helps you understanding if your team is performing (as in the forming, storming, norming, performing concept), and not a goal in itself.

You surely do not want your team to game estimates or apply whatever other technique to show that velocity is increasing for the sake of it. In the end what really matters is the value your team is capable of delivering at the end of each sprint.

Answer 2

I would say no and I would recommend against using them.

What can cause a discrepancies in story points # for individual devs in a team?

• Someone works mostly on bugs/spikes, so no story points for them. This does not mean they don't perform.
• Some devs works more than others
• Some devs are lazy

All the above are issues in the team that should be adressed. So basically a discrepancy of story points per individual will show you if there are issues with how the team works, which you will try to solve. So ideally the discrepancies disappear in a few months.

How will this help individual performance? The devs would chase the big stories, they will avoid bugs / spikes, no matter if needed or not, not to mention that the relationships within the teams are affected. I don't think this team will work cohesively with the focus on reaching the sprint goal, as they will have to focus on gaining points.

I have an idea of replacement: how about # code reviews? This shows the person is focused on quality, stories are delivered faster (we used to have a lot of stories in "waiting for review" state), and if people fight to do more code review it's just much better for the team overall. Feels like healthy competition and it's win-win for devs - team and the product.

Answer 3

You don't specifically mention Agile, but there are hints of it in there. Even if that is not the operational mode, the following points are still applicable.

One of the benefits of properly embracing and executing the Agile philosophy is truly collaborative teams, not a group of individuals assigned to work "together" (i.e. answer each others' questions) under a single manager. The team works toward creating quality, valuable products. Framing thins on individuals can be an impediment to team development and maturation.

The majority of the goals need to be team oriented in order to facilitate the team concept. These are generally manifested in Sprint Goals. Limit scope and time to ensure quality and reduce risk. Focus on the team's short term mission. Creating and attempting to adhere to longer range planning will lead to disappointment. (see history)

Any individual goals need to be tailored to that person and not be based in what the team accomplishes. For example, achieving X story points is bad as an individual goal; it can also be bad as a long term team goal. (It also goes against the "maintain a constant pace" principle.) Instead individual goals should focus on items such as skill or education.

Velocity is not something that needs to be continuously improved. (again see "maintain a constant pace") It is one tool option for forecasting the possible completion of future work. It is not a measure of productivity. (see "Working software is the primary measure of progress.") Is creating pressure to essentially work faster/harder beneficial for results?

tldr; Base individual goals on the individual, not on the team.