Dev Teammates feel that Sprints could be more equally weighted across all team members if Story Points accounted for skill types (Development, Design, QA, and etc...)
Happy Friday everyone,
Looking for some advice on a situation that arose this morning. A team member presented the idea that Story Points could be more efficient or accurate by also considering different team member's time. They reported that not all sprints are built equally and some sprints caused more work on certain team members than others. Usually, I'm quite comfortable with in justifying the scrum framework and its practices and why certain procedures in scrum are important; however, in this case I asked if I could meditate on this question a bit more. To me, this seems like two separate issues:
- Team members feel that Sprints aren't equally weighted
- Team members feel that Story Points aren't specific enough
For #1, this suggest two things to me: that more consideration of team composition should be made during Sprint Planning AND teams need to work on being more cross-functional. Now I've spoken to my team of cross-functionality before, and they've been expanding their skills sets since the beginning of this year. However, two members have mentioned that there's only so much cross-functional skill sets they can learn considering our scrum team works on a multiplatform product (iOS/Web/Android/Backend). As a former dev, I'm sensitive to the fact that learning new programming languages and tech stacks is a slow process. It is for that reason that the development team get the final say during Sprint Planning on the Sprint Backlog.
For #2, I'm having more trouble with this idea, but this is what I got: Story Points are usually imprecise - this is why we use the fibonacci sequence when estimating; however, it seems that the team wants more precision and skill distribution likely because it would help with #1.
I have an upcoming Sprint Planning Retrospective meeting where the dev team and I will speak about these topics, so any additional insights or though experiments would be appreciated. Please let me know what you guys think!
Victor
What's the actual problem they are trying to solve through improved estimation? How good are they at achieving a Sprint Goal with a Done and immediately usable increment of work?
Story Points will never be precise. I say that because they are just guesses (estimates) made at a point in time based upon the information you have available. And in my opinion that point in time is when you know the least because you haven't actually started any work. There is no expectation, nor has there ever been an expectation, that Story Points will be precise. Their purpose is to give the Scrum Team a general idea of the amount of effort in relation to other items. This information can be used for the Developers to further estimate whether a selected body of work could be potentially completed within a Sprint boundary.
If you want to get metrics that will be somewhat more precise you could introduce the metrics of throughput and cycle time. Those reflect the actual work being done and take into account the discovery that happens.
I suggest that you and your team read this article by Ron Jeffries. Knowing the history of Story Points from the man that is said to have created them should help understanding.
And I am going to wrap up this with the reminder that User Stories and Story Points are not even mentioned in the Scrum Guide. The framework does not require them nor does it provide any guidance on how to use them. So ultimately, this is an issue that your Developers need to resolve. After all they are the ones responsible for providing the estimates.
Hey Daniel,
Thank you for your well considered answer. I have read through your response along with the aforementioned article and I think this is just the kind of resource that will help our team get into the right frame of mind come next Friday. I will share your link with the rest of the team.
Thanks again!
Sample Response