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?
  • (Question, before I add an answer:) Can you define deliverables for each developer, and use that as milestones? (And don't forget to add integration.) Or try the old EVS (Earned Value System) system. Or am I misunderstanding your question? Mar 3, 2016 at 9:15
  • 1
    Can you give an example of a user story? Before I'd answer, I'd want to make sure I'm not making the assumption your stories are detailed, in-depth requirements and not "As a $type of user, I want to $do stuff, to get $business value" format, which is what scrum prescribes. After all, story points are supposed to be high level, not in-depth detailed estimates.
    – jmort253
    Mar 3, 2016 at 10:23
  • 1
    @DannySchoemann I am sorry for the delay with my answer. We decompose the User Story to technical tasks and that separates tasks to subtasks (if needed). Despite the fact that most of the Stories does not assume the parallel work of two (or more) developers, well separated tasks help me to track progress well. So, there is no problem with monitoring and control. The problem is that we lose main benefits of the Story Points, such as its relative and universal unit of the capacity of the team (with help of witch we can understand if we increased the productivity of the team, or not). Mar 8, 2016 at 18:13
  • @jmort253 My apologies for the late clarification. Yes, during estimation our Stories are already well refined and "detailed, in-depth requirements". But this is not the root of my problem. The root of the problem is that we have a lot of technical systems and few developers. So, there are a lot of cases, when only one developer has knowledge about the technical system and can make an estimation about the amount of work with it. Mar 8, 2016 at 18:16

4 Answers 4


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.

  • The team does want to become cross-functional, but we do not have enough resources for it right now. Too much work, too much knowledge for sharing and only a few developers. I hope the progress of sharing will go faster, when we can hire more developers, but it will take some time. I think, separation of capacity for different fields is an interesting idea, but a little bit complicated. I am inclined to use man-hours instead Story Points, as you suggested in your last paragraph. Mar 8, 2016 at 18:19
  • I would recommend the book "Agile Estimating and Planning" by Mike Cohn. It includes a chapter on estimating in ideal days. Mar 8, 2016 at 18:28

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.

  • I am afraid, that it will always be the same situation: the guy, who has enough knowledge about the system will make an estimation, and all other team members will just agree with him. Even if someone does be not agree with the best-known-guy's estimation, he will have no knowledge with which to argue his position. Mar 8, 2016 at 18:24

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.

  • As I commented to Barnaby Golden, separating different kinds of Story Points is an interesting Idea, but complicated for us. And you are right about your concerns: planning will be much harder. Mar 8, 2016 at 18:30

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.