Sprint Planning - Team members with different competencies

It's first worth noting that Story points are not an element of Scrum, and overall I would say most teams are actually better off long term trying to get away from story points. 



That said, the purpose of story points is not to create some fixed or 'understood' scale of time, it's to uncover differences of thought so we can discuss variances. 



So yes, story points are intended to be a single number used across skillsets. 



That's because if a tester says something is a 8, but a developer says it's a 2, that's an important conversation to have. Is it hard to test, does it touch fragile parts of the system we don't have a regression suite for, is automating it a nightmare because we don't really know yet what it's for?



I always use the line 'story points are not about reaching agreement, but about finding out why we disagree' 



It really doesn't matter what numbers we end up choosing or why, all that matters is that we're having a robust conversation about the complexity and uncertainty of the work. 



Allowing different skillsets to use a different number scale undermines that purpose because we just start saying 'test says its 5, dev says  it's 3, so it's an 8'. 



Well okay, but 8 what? 



It's still a made up, meaningless number. 



Our goal should be 'I think it's X' 'you think it's y', why is there a gap and what does that tell us?

Hi Alessio,

I had a similar issue (or at least I thought) figuring out the exact team velocity and how the individual team member's experience and skill set will affects the velocity.

One of the mistakes I think I did is unconsciously considering the velocity as a performance measure. Although the two are related or even correlated they are not interchangeable. Furthermore, using velocity as a performance measure will lead to perversion, especially if used by people outside the team. The velocity (using story points or no-estimate technique) is only needed by the team (including PO and SM) to figure out how much work they can commit to. If they are asked to improve the velocity, they might just increase the estimate (consciously or unconsciously) to reach that goal; this is known as Goohart's law.

I think the most important thing when estimating is the discussion about how they perceive the quantity of work needed. Also, in order to have a meaningful velocity it's important to complete as many work items as possible during the sprint.

The other thing that I experienced with teams with specialized developers is that they tend to favor efficiency over effectiveness. In other words, the team tends to split the work according to the skill set because they believe it's more efficient leading to issues like local optimization. There are many reasons for that, maybe it will be the subject of another post.

Just as an example, you could have one competency delivering the double of Story Points of another competency.

Let's focus on that example. How are story points "delivered" at all? Is that really what the team are offering to provide, and if so, to whom? What do the recipients then do with those points?

Thank you all for your comments!

Let me answer the interesting question coming from Ian.

I agree that my wording is incorrect. We are not and should not be here to deliver "Story Points". Which verb could we use instead? Story Points are "completed"/"done"?

I also take the opportunity to try to redirect to my initial discussion/doubt and make a clarification on the term "competency": I am not talking about "developer" and "tester", but more about different kind of software development targets (for instance Back-End, Front-End). Maybe at this point, we could probably just create a User Story which itself embeds Back-End and Front-End), however sometimes you could have specific developments only for one speciality.

I suggest you read this article from Ron Jeffries, the person who is said to have invented Story Points.  https://ronjeffries.com/articles/019-01ff/story-points/Index.html You are falling into some of the traps that he mentions in the article. 

Story Points are estimates.  Estimates are guesses made based upon the information you have available. But estimates are never accurate.  If they are then you are not guessing. As @Michael pointed out, the effort of estimating with Story Points is to encourage discussion and debate.  This article from Mountain Goat Software explains how Planning Poker is done.  https://www.mountaingoatsoftware.com/agile/planning-poker. This is the part that many people don't understand because "everyone knows how to do an estimate".  Sure everyone know how to estimate but very few understand the importance of allowing everyone to estimate on their own, discuss why estimates are different and then come to a consensus as a group. 

I agree that my wording is incorrect. We are not and should not be here to deliver "Story Points". Which verb could we use instead? Story Points are "completed"/"done"?

Think of it the other way around. It isn't delivery which is the problem. It is better to deliver than to merely complete.

The important matter is what gets delivered. In Scrum it ought to be at least one Done finished increment every Sprint. Hence the only purpose of estimation in Scrum is for Developers to get their arms around how much work they can take on each Sprint. Everything else resolves to value and empirical process control. Developers should therefore take great care not to become story point accountants.

Thank you all for your answers!

Let me recap what I've understood so far.

There are different ways to handle this "planning activity", but whether we are using Story Points or not, they are estimates, meaning that we will not be accurate, and everyone inside and outside should be aware of it, understand and accepts it (which could be the most difficult thing in this context).

Would you agree with that?

My last personal feeling now, would almost be that I hope that the Scrum Guide would one day remove the concept of "set of Product Backlog items selected for the Sprint" from the Sprint Backlog, and just keep the Sprint Goal, so everyone inside and outside the team would focus on that and on agreeing if that goal is achievable within one Sprint or not.

My last personal feeling now, would almost be that I hope that the Scrum Guide would one day remove the concept of "set of Product Backlog items selected for the Sprint" from the Sprint Backlog, and just keep the Sprint Goal, so everyone inside and outside the team would focus on that and on agreeing if that goal is achievable within one Sprint or not.

If they did focus on that, they may then find it hard to limit their work in progress during the Sprint, and they would be left with a poor means of risk control.

It might be better to describe the Sprint Goal as a shared commitment, while the focus ought to be on completing whatever valuable items are being forecast, early and often.

discuss why estimates are different and then come to a consensus as a group. 

What if we have two developers—one with 2 years of experience and another with 20 years of experience—on the same team? Almost all of their estimates will be very different simply because the second one, for example, knows SQL better, is a database expert, or just types twice as fast as the other.

Discussion "why estimates are different" is ineffective here, because the only reason of different estimates is the different level of expertise of people. Is it true that in that case they should do pair programming? All the time?

Almost all of their estimates will be very different simply because the second one, for example, knows SQL better, is a database expert, or just types twice as fast as the other.

I once had a college intern ask a question during a refinement session.  Included in that session were developers that ranged from 5-25 years of experience.  His question brought a new perspective that none of the other developers had considered.  It completely changed the way that everyone, including the Product Owner, looked at the issue we were trying to solve.  His estimate for the item was a 3.  The rest of the team had been posing 8 and above.  After the conversation discussed the new ideas, everything changed and a much simpler solution was implemented.

That is why you want the conversations to occur.  It allows everyone an opportunity to shed light on their thoughts, share their insights, and collaborate using all of the information available. Just because one person has more experience and wider knowledge does not mean that their estimates (i.e. guesses) are better than everyone else. 

Is it true that in that case they should do pair programming? All the time?

I can't answer that question because I don't know the people.  It could be that the newer person has experience with a technology that the seasoned person does not.  It could also be determined that neither of them has the right experience.  The choice of pair programming should be something that the people doing the work determines.  

Transparency, Inspection, and Adaption.  Those are the pillars of empiricism which a foundation of Scrum. Notice that experience, longevity, or seniority are part of those.