If your company is using story points to “measure” developers, they are completely misusing that concept, and it probably results in a low-teamwork environment (as you describe).
The purpose of story points is so a team can say “we’re not taking more than X work for the next two weeks. Make sure it’s the important stuff.” It is a way to communicate a limit to force prioritization by the product owner.
And, in fact, data shows that point estimation so poorly converges on reality that teams may as well assign everything a “1”. The key technique is to try to make stories the same size, and to reduce variability by having the team swarm/mob to unblock stuck work.
Who creates these tasks? They need to close the year old items, reevaluate the work and break it down into sub-5-day chunks. If there are so many unknowns that it’s impossible to do that, the team needs to brainstorm how to resolve them.
Ahh, I see. I had no idea. I’m not from a programming background originally but fought hard to get into a programming job from a closely-related field. The way our team uses them is to justify our contracting support, “Look at our developers, they did X points! You should contract more work to our company!”
So if point estimation is that poor, maybe I should stop agonizing over adding points to a task… it always feels like I’m broadcasting that I can’t solve a task when the points go… 5… 10… 15… 20… 25… etc.
Who creates these tasks? Anyone can, most of the existing tasks were created by people I’ve never met, sometimes people no longer with the company, sometimes people on a different development team, the tasks get assigned to the team working on “the product” that we support and then are handed out.
If your company is using story points to “measure” developers, they are completely misusing that concept, and it probably results in a low-teamwork environment (as you describe).
The purpose of story points is so a team can say “we’re not taking more than X work for the next two weeks. Make sure it’s the important stuff.” It is a way to communicate a limit to force prioritization by the product owner.
And, in fact, data shows that point estimation so poorly converges on reality that teams may as well assign everything a “1”. The key technique is to try to make stories the same size, and to reduce variability by having the team swarm/mob to unblock stuck work.
Who creates these tasks? They need to close the year old items, reevaluate the work and break it down into sub-5-day chunks. If there are so many unknowns that it’s impossible to do that, the team needs to brainstorm how to resolve them.
Ahh, I see. I had no idea. I’m not from a programming background originally but fought hard to get into a programming job from a closely-related field. The way our team uses them is to justify our contracting support, “Look at our developers, they did X points! You should contract more work to our company!”
So if point estimation is that poor, maybe I should stop agonizing over adding points to a task… it always feels like I’m broadcasting that I can’t solve a task when the points go… 5… 10… 15… 20… 25… etc.
Who creates these tasks? Anyone can, most of the existing tasks were created by people I’ve never met, sometimes people no longer with the company, sometimes people on a different development team, the tasks get assigned to the team working on “the product” that we support and then are handed out.