Story point on team with separate technologies

Question

Currently we do like this:

• we estimate backlog in hours
• on sprint planning we fill backlog by assign tasks to persons as each one has different technology background and we need to know how much of the stuff could be taken in (we also have a buffer time on 30% of working hours). Actually we have 2 of each, but for historical reasons we still assign at sprint start.

The question: if the team would go for story points, how would you choose what to put on backlog, as even for a velocity X you still have to take into account available resources for each technology.

Answer 1

It's better don't use Story Points during Sprint Planning. Story Points are about productivity of whole team (not individuals).

By my opinion, you should do exactly the opposite: use Story Points during estimation of Product Backlog Items and use hours during Sprint Planning.

Please, take a look at this article: Why I Don’t Use Story Points for Sprint Planning by Mike Cohn.

I apologize for overquoting, but following text exactly answer the question:

Velocity will bounce around from sprint to sprint. That's why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It's just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.

When a team finishes planning a sprint in this way it is indeed likely that the number of story points they have unknowingly committed to should be close to their long-term average but it will vary some. It will also be true that a team will commit to approximately the same number of hours from one sprint to the next. I use the term capacity to refer to this number of hours because velocity is reserved for referring to measuring the amount of work planned or completed as given in the units used to estimate the product backlog (which I recommend be done using story points).

So, use hours during the Sprint Planning as you did it before (including taking account of technical knowledge each of team members), but change estimation units for Product Backlog Items from Hours to Story Points.

---

Also, you may have a look to these questions:

• Why use both story points and hours?
• When it is time to do poker planning - during Story Time or during Sprint Planning

to learn more about benefits of double estimation and

• Why use story points instead of hours for estimating?

to learn more about benefits of Story Points as long-term measure.

Answer 2

Story Points help in release planning. Not much use if we assign them during sprint planning. You may reassess the story points during backlog refinement or sprint planning but to do so for the first time in sprint planning might not help much.

The metaphor of 2 runners would help understand the concept behind story points. Both of them cover the morning jog (10 KM each) but one of them finishes in 20 minutes while the other finishes in 15. If you were to ask them how long would it take, the answers would be different but if you ask the distance, they would agree.

Answer 3

We commit to work based on the last iteration, commitment and capacity for the next one.

First, we check the last iteration(s). If in the last iteration, we committed to 20 points and we delivered only 15, our success rate is 75%.

Second, during the planning, we check our capacity - how many of us will be in the office and will be able to work on the features - and collect user stories based on that. For example, if one person can do one point a day, and only two of us will work during the iteration - which is 5 days -, we'll have a capacity for 10 points.

Finally, we take work for 7 days: 75% of the 10 points.

In your case, the capacity can be based on knowledge. For example, if your technology A expert can work only provide 30% during the sprint, calculate how much would it be in point based on the last iterations and commit only the possible amount of user stories.