My team consists of 2 backend devs, 1 front end dev and designer. Lets pretend we have next user story:

As a user I want to sign-in/sign-out to use the system

Designer says that it is equal to 2 story points. Back end devs believe, that this is a 1 point story, while front end dev thinks, that it equals to 3 points (due to animations,transitions etc.) What amount of story points should be the outcome of this user story?

Should I sum up the overall number of points for 1 user story?

Should I split the user story to 3 different stories? (backend, frontend, design)

Should I just lean to the maximum story point value?

5 Answers 5


When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members).
The advantage of using story-points here is that the values are relative to previously estimated work and most people are able to estimate if something is less/more/a lot more work than a reference story, even if they do not have the competences to actually perform the work itself. This way, the front-end dev can take the work of the other disciplines into account when making his estimate for the complete effort to finish a story.

Once you have everyone estimating the complete effort, it is still possible that different people come up with different estimates. The usual reasons for this are

  • The acceptance criteria for the story are not specific enough, causing some developers to see the story as broader than the others do,
  • Some developers see risks or additional effort that some others overlooked
  • Sometimes work you are not familiar with looks deceptively simple or complex, and that gets taken into account in the estimate.

If there are significant differences in the estimates, a discussion should be held among the team to find out where those differences came from and if everybody is on the same page.
With your example, chances are that the back-end dev overlooked the amount of effort that is needed to get all the right animations (or thought that it would be easy).

After everyone has had an opportunity to say what they considered in coming to their estimate, you can do a new round of estimations for that story. Most likely, the estimates will be much closer together.

If there are just small differences between the estimates, then you can choose to just pick one of the values (for example, the average value or the value that most people are on).

  • 1
    to add to what Bart said, you could ask the team to compare the story with a previously done story to get the estimates in relative terms. Commented Feb 15, 2016 at 15:47
  • But how would a front end dev know how many points the task will take from a designer, tester or back end dev perspective? Commented Jun 14, 2016 at 11:24
  • 1
    @RuslanDoronichev: See my edit Commented Jun 14, 2016 at 11:37

Just came across this (rather old) post.

I'm managing a team of dedicated frontenders and backenders. It'll be a cold day in Hell, when they start doing each other's work :-)

My concern with the community score, is that it gives a false velocity for the team, in the case of having dedicated Front- and Backend developers respectively.

EXAMPLE: Say a story ends up at 20 story points, after a healthy discussion in Refinement. Of these 20 points, it was clearly the backend developers stressing the complexity of building their part, whereas the frontenders needed only implement a new form. So the backenders account for 80% of the story points (so to speak, they are the ones who raised the score). Now, let's say the team has 4 backenders and 2 frontenders. And they make the above story in the sprint. All is well, and velocity could be said to be 20 story points per sprint.

Next refinement, tables are turned, frontend is a nightmare, backend a breeze, but it still adds up to 20 story points. Given that frontenders now have to do 80% of a 20-point story, with only 2 frontenders to do it, how does that affect velocity?

For the sake of predictability and getting a trustworthy velocity, I think the community score has some major flaws. Unfortunately, I have yet to find the fix for them :-)

  • 1
    I recently had a project where 3 agile coaches were talking about the promise land of backend java devs writing ios apps if we start using combined storypoints. I said to myself - ok, maybe I don't know something let's see how it works. Of course this never happened. And it won't unless you work with a bunch of super smart people. The problem with agile coaches is that they're very far away from development and never get deep enough to understand how much inefficiency this approach with combined storypoints brings to the table. Your example is 100% correct and should get more upvotes. Commented Aug 1, 2020 at 17:48

During the planning poker sessions average out (rounded up) story point estimates which are close to each other. In your example this would be come 2 story points.

Lets say you use the Fibonacci scale:

0 1/2 1 2 3 5 8 13 20 40 100

When the estimations are more then 3 steps apart, say 1 and 5, then discuss and re-vote. When the estimations are less then 3 steps away, say 2,3,5, average them rounded up.

The reason to average is because you don't want to spend to much discussion on things the team relatively agrees on. As the story points are used as a forecast its not to important they are exact. The fault margin will compensate on average on all estimations.

I got the averaging from the book Scrum: The Art of Doing Twice the Work in Half the Time, where Jeff Sutherland suggested this. I think it makes total sence.


Short Answers

Should I sum up the overall number of points for 1 user story?

No. Summing developer guesses will yield efforts that are much larger simply because more developer are guessing.

Should I split the user story to 3 different stories? (backend, frontend, design)

Probably not. Rather, ensure that each piece of work represents a valuable increment of the software with clearly expressed business value, if at all possible.

Should I just lean to the maximum story point value?

Yes and no :). When there is a wide gap between developer guesses, encourage the devs to figure out why their guesses have diverge. With narrower gaps, tend toward the higher number.

Sum Up

Ultimately, commit to consistency, rigorous inspection and adaptation in whatever techniques you adopt. This ensures that good practices will emerge and bad ones will fall by the wayside.


Here's my two-cents:

Bart hit directly upon "the essential reason for 'story points'" in his first post: that "a single 'story,'" when parsed-out to the various actual work groups that are going to work on it, will actually consist of a separate (and different) number of steps, or "points," for each group.

So, I'd count this as "four points":

  • "The designer, bless him-or-her, really isn't going to be doing the work."
  • The back-end folks count 1.
  • The front-end folks count 3.
  • Total 4.

But ... be very keenly aware that you are counting apples with oranges. A "point" for a back-end team might take the entire sprint, and each "point" for a front-end team might well be very different from the other "points." The notion of "points" is useful as an estimating tool but it only goes so far. Use best judgment. There are no absolutes here.

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.