Best measurable units for non cross-functional team estimation

Question

I have a new development team and I want to use Story Points for high-level estimation.

But I have two problems:

1. My new team is not cross-functional (we are trying to solve this, but this is a slow process).
2. User Stories are very specific and demand detailed knowledge.

So, during Product Backlog Refinement we assume, that in most cases concrete Story will be implemented by a concrete developer. Obviously, only this developer will estimate his Story (because only he has required knowledge).

But Story Point is measurable units for whole team, not for any single person within the team. If we will estimate Stories by a concrete developer, a Story Point of one developer will not be the same as a Story Point of another developer.

So, the question is:

1. Is it a good idea to use Story Points in my situation?
2. If not, what measurable units are better to use? Old-fashion man-hours / ideal man-hours or something else?

Answer 1

The reason for using story points is that it allows us to work out the capacity of the team.

The question you have to ask yourself is what is the best way for the team you describe to work out its capacity.

If you force boundaries between disciplines then really you have several capacities and not just one.

For example, say the team consisted of 5 developers. 2 developers can only work on stories relating to the database. 1 developer can only work on the front end and 2 other developers can only work on the web services.

In this situation the team has a capacity for database work, a capacity for front end development and a capacity for web services. That is even before we start talking about testing. Is there just one tester who can work on each area? Do the developers do the testing?

Estimating in Scrum works best when we assume the team members can work on any story. They may be better at working on some kinds of stories than on others, but they can still work on all types of stories. If a developer does not know how to do something, they can get training or pair with a developer who does know how to do it. That way knowledge is shared across the team.

I would recommend you adopt this approach to knowledge sharing and have every team member estimate on every story. You will find that developers estimate high on stories they are unfamiliar with and low on stories that they understand well. That is fine, just get the team to come to a concensus estimate that incorporates every team members input. The way velocity is calculated as a rolling average tends to compensate for this kind of thing over time.

If the team does not want to become cross-functional than you are better off estimating at the task level rather than at the story level. You may well find that estimating in ideal hours is more useful than story points in this approach.

Answer 2

Story points are always a good idea, the challenge lies in finding a task that all the team members can understand which can then function as a 'reference point'.

When estimating a story based on this reference task, the person who has the in-depth knowledge on the subject should explain to the best of their ability what factors are involved in the story-to-be-estimated so that the other team members can make a reasonable estimate of how complex it is when compared to the reference task.

In the beginning this will be difficult since the cross-domain knowledge is still limited but as the team continues working together you will notice that the estimates are rapidly increasing in accuracy. That is assuming you have a retrospective meeting in place after every sprint where the team takes some time to analyse what went well and what went wrong during the sprint, part of which will be comparing the initial estimates of stories to the actual time it took to complete them.

Answer 3

This is probably not your situation, but this is an inherent problem with game development teams (my primary area of experience), because there is typically no overlap in skill sets, and never will be if the project is larger than a couple scrum teams. In these cases, I've used separate story point estimates in each department, but it comes with a few cons. One, it can increase silo mentality and culture (bad), and two, it makes planning clean sprints and releases much more puzzle-like. I often need to "fill small gaps" with feasible overlap like testing or shadowing to learn how the other departments work, or personal/stretch goals. One positive is that it quickly shows where parts of the release plan are lopsided and/or you may need expert capacity.

That being said (and before you downvote me :) ), I would recommend Barnaby Golden's advice, with emphasis on a concrete and tangible plan to cross-train and pair up with the goal of shared, single-value estimates.

Answer 4

This is a common misconception. People think that a cross-functional team is one on which each person possesses every skill necessary to complete the work.

A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.

Mike Cohn once said:

If my team includes the world’s greatest database developer, I want that person doing amazing things with our database. I don’t need the world’s greatest database developer to learn JavaScript.

My team usually contains 2 BE devs, 2 FE devs, and 2 QA. Every team member is involved in the estimation process. We do scrum poker altogether. Everyone participates and gives input, and we decide on the final points as a team.

The only thing that you need to keep in mind is:

• if you have a balanced amount of FE and BE work, then you'll be able to accomplish more story points
• If the work to be done is weighted towards one layer over another, then you'll be able to accomplish fewer story points