One of the most common errors I see in sprint planning is the tendency of people to try and come up with story points based on who is going to work on a story.
If the developer is somewhat inexperienced then the entire team leans towards assigning a higher number than they would have otherwise done.
This is a mistake because if you do this you will never be able to increase that part of your team’s velocity which accrues due to the team becoming better at the task.
If a story is truly worth eight points, and you assign it 13 points based on the fact that the person doing the story will take more time then sure this time it seems like the person contributed 13 points to the team, but in reality they delivered lesser business value. Two or three sprints forth if this person is now more efficient and does 13 points worth of work that will not show up in your team’s velocity because you will assign this story 13 points as well. So, while the person did more work from one sprint to the other – the team’s velocity remained the same.
You see this happen a lot, and I believe a big part of the reason is that people are just used to estimating based on the time it will take them, and not based on relative sizing. This is why it is often helpful to remind everyone what the team’s baseline is and that’s to be kept in mind while doing relative story point estimation.
Leave a Reply