Planning and estimation in a challenging setup

Scrum Master's Home
1

Dear Scrum Masters,

I would like to hear your opinion or ideas regarding estimations and sprint planning in the following scenario:

We’re currently working in a bigger software development project using the Scrum framework. The project comprises a frontend as well as a backend. Both require different skills: Typescript, CSS and React for the frontend and Java/Quarkus Kafka etc. for the backend. Hence, there are two teams: One for the backend and one for the frontend (no fullstack developers).

But the features usually comprise backend and frontend togehter, e.g. a new form or dialog in the frontend and a belonging backend service. In the beginning, we had separate stories for backend and frontend. But this setup resulted in a bad alignment between frontend and backend team. So we moved back to combined stories which describe a single feature from business perspective only. We would like to have both teams organize themselves of how to solve them from a technical point of view by defining tasks.

The combined user stories pose some challenges regarding estimation and planning: Both teams operate on their own pace. And a single story might result in a totally different amount of work involved for either backend or frontend. We think that we still need a separate estimation from the backend and frontend team so that we’re able to balance the amount of work in the sprint planning. And it turns out that the frontend team is not really able to estimate the work in the backend and vice versa.

In summary, our solution looks like this: Both teams will get combined user stories which describe a certain feature. Both have to align on that and define the tasks involved. Doing so, it might turn out, that e.g. the backend part would be too big for one sprint if it was to be fully completed. So one team might ask for a compromise and split out a part of the work in a separate story. Afterwards, both team will be asked to estimate the frontend and backend part separately. The combined amount of story points will be noted on the story, but both seperate estimates will be maintained as well. This will allow us to balance the amount of work for both teams in the Sprint Planning (and the preparation for that).

What do you think? How would you handle it? I really appreciate your input!

2

Hi Volker,

there are multiple ambiguous definitions for user stories. On one hand, they should describe user visible behavior. On the other hand, they should be doable by one team in one sprint.

To be completely clean in the issue tracker, you could either create a third backlog item (epic or feature) summarizing two individual stories, or the other way round split a user story in two technical stories. But for only two teams, this might be overkill and too much administration effort. (Unless the teams like it of course, or for example the implementations are done in different sprints, e.g. first backend with unit tests and then frontend in the sprint afterwards).

To me, your approach seams perfectly fine and could be called “Cross Team Refinement”. Just make sure, both teams (depending on the size only a representative each or the whole crowd) have discussed the story together and do not estimate based on different assumptions.

Oliver

1 Like
3

Sorry that I have to state something obvious (without knowing more of your context): have you thought about changing your team setup?

You’re already feeling the planning pain as a symptom. Sure, your proposed way of estimation and planning works somehow.

And regardless of your planning efforts, you still have two separate teams working on different parts of a single feature. Which means that, for whatever reason, just one team could finish their work without the user getting anything usable/ valuable.

4

Hi Oliver and Marco,

thank you very much for your valuable responses.

@OliverC: We will try it with one story and separate estimates now. Hopefully, both teams are better aligned this way. Separate stories under one common epic was the previous setup, but came with its own challenges.

@MarcoSpoerl : Yes, a different team setup, ideally more cross-functional, could be helpful. Unfortunately, I can’t change this (customer provides the backend team and we are hired for the frontend).