Estimating Stories That Cross Frontend and Backend
A story comes up that needs a new API field and a new screen to show it. The backend developers vote 3. The frontend developers vote 8. Nobody is wrong: each group is accurately sizing the half they understand and guessing at the other half.
This is one of the most common sources of split votes, and it has a predictable fix.
Why specialists vote their own half
People estimate what they can picture. A backend developer sees the endpoint, the migration, and the tests, and assumes the screen is "just displaying it". A frontend developer sees the loading states, the error handling, the empty state, and the layout on three screen sizes, and assumes the API is "just returning it".
Both assumptions are optimistic about the unfamiliar half. That's why the combined story almost always turns out bigger than either group's vote.
Make each side say what it's counting
When votes split along specialty lines, don't average and don't re-vote straight away. Ask the highest and lowest voters to name what they included, the same as you would for any disagreement.
It usually goes like this: the backend developer lists their work, the frontend developer lists theirs, and the room realizes the story contains both lists. The re-vote then lands higher than either original number, and closer to what the work will actually take.
Estimate the whole story, not a sum of halves
It's tempting to fix this by estimating the frontend and backend separately and adding them. Resist it. Story points are relative size for the whole piece of work, including the parts that belong to nobody in particular:
- Agreeing on the shape of the data between the two sides
- Wiring the two halves together and testing them end to end
- The round trip when one side's assumption doesn't match the other's
Adding two specialist estimates leaves all of that out. Voting on the whole story as a team keeps it in.
Consider splitting the story, carefully
If the two halves are genuinely independent and each delivers something on its own, split them. A backend change that other clients can use today is a real deliverable.
But a split that produces "build the API" and "build the screen" usually creates two stories that can't be demonstrated to a user on their own. See splitting user stories without losing estimation value for how to slice vertically instead, so each piece crosses the stack and still ships something.
Let the unfamiliar half inform the vote
Over time, the best fix is exposure. Teams where frontend developers occasionally pair on backend work, and the reverse, estimate cross-stack stories far more accurately, because everyone can picture both halves. Even one pairing session a sprint helps.
This is the same reason designers belong in planning poker: the people who can see a part of the work are the ones who stop the rest of the team from underestimating it.
A split vote along specialty lines isn't a disagreement about size. It's two people each describing half the story. Put the halves together before you vote again.
