Inter team dependencies in one story

Question

What is the best way to handle task dependencies inside one story? The story itself is independent from other stories and we do have cross functional teams (design, backend, frontend).

For most tasks - especially at the start of a project - frontend work is usually blocked by the backend and design work.

Let's say that we want to implement a login story:

As a customer I want to log in to be able to access the private parts of the site

This story has a three parts:

1. Login form design
2. Backend API implementation
3. Frontend implementation (with styles and connecting to backend)

So, tasks #1 and #2 can be done in parallel, while task #3 is dependent on both of them.

They also have very different effort levels needed for the completion.

My questions are:

1. When doing estimate, should each part be estimated separately? How to calculate "total" estimate?
2. How to avoid spillover? If most of the tasks are entangled like this, it is possible that few tasks will be done-done, since the work is serial instead of being parallel
3. How to commit on something that is so uncertain (other people's work)?

I've read most of the topics that mention dependencies, but couldn't find a good solution to this problem

Answer 1

A lot can be done using mocks and stubs.

For example, the team could work out what the API will look like first and then rapidly build a stub API that returns fake data.

This helps to separate out the frontend and back-end development tasks. Now the frontend developers work using the stub and the back-end developers work to flesh out the implementation of the API.

It may be that a stub is insufficient to properly drive the frontend and in that case you might want to build a more sophisticated mock API.

This is just one example of the mindset of trying to reduce dependencies to allow the team to work more in parallel. This is a worthwhile approach as it easier for the team to focus on completing a user story rather than having many stories in progress at once.

Answer 2

For estimation, you want to estimate at the Product Backlog Item level. If you're using User Stories, the User Story is typically the Product Backlog Item. And when estimating, you want to account for all of the work necessary to get it to its done state, per the team's Definition of Done any any acceptance criteria on the Story itself.

The best way to handle any dependencies is to reduce or even eliminate them. This will help you avoid (or at least reduce) spillover, focus on not estimating other people's work, and having clear states of being ready and done.

In your particular case, I believe that you can eliminate the UX/UI design task dependency. I would normally expect this work to be done as part of defining the work. I would expect a UI design to be complete, at least to a wireframe level, before the Product Backlog Item is refined by the team. Unless you know what the form is supposed to look like and how the UI elements are to behave (from a UX perspective), how can you estimate and order the work?

If you move design (of the UX type) as a prerequisite for refinement of the work by the Development Team, you can open different possibilities for managing the discovery work done by product managers and user experience designers.

Answer 3

1. When doing estimate, should each part be estimated separately? How to calculate "total" estimate?

All the teams participate in the same Sprint Planning, discuss all the aspect of the User Story and fully estimate it.

How?

You first need a reference User Story which has 1 Story Point. You discuss this User Story so that all the parts are understood. It may be:

"As a web user, I want to reset my password, So that I keep using my account"

It has design, frontend, backend work.

Then, you ask the Developers (design, frontend, backend) to give their estimates on how much more complex your story is, than the reference story. If it's just as complex as the reference User Story, then it gets 1SP.

The user story estimation contains all the work to get it "Done". All of it.

2.How to avoid spillover? If most of the tasks are entangled like this, it is possible that few tasks will be done-done, since the work is serial instead of being parallel

You need to practice iterative development, most notably the inspection and adaptation.

In your case:

This story has a three parts:

1.Login form design

2.Backend API implementation

3.Frontend implementation (with styles and connecting to backend)

During Product Backlog Refinement you come up with some initial drafts for the three parts and add them to the User Story. Then you have an imperfect User Story, but still one which has all the parts, so all the Developers can start working on it. The User Story is selected for a Sprint and further discussed during Sprint Planning. More details are added.

Then you start working on it.

Iteration no. 1:

Based on the User Story details, the frontend uses the draft design and expects some backend endpoints, mocks them. All the work is integrated on the development environment.

One-two days later, the Developers and the Product Owner have a look at it (literally, on the UI). This is inspection. And decide how to modify it further. Adaptation comes next.

Iteration no. 2:

The design is updated. The frontend updates it. The backend delivered some endpoints. The frontend removes some mocks and uses actual endpoints. This is adaptation.

One-two days later, it's feedback time, again. Somebody clicks the login button, it doesn't work. Is it frontend or backend fault? Backend. The design could use a different font. This is inspection.

Iteration no. 3

The backend fixes and delivers all endpoints. The design is updated with the new font. The frontend puts it all together.

One day later, it's feedback time, again. Now it looks good and works as expected. This is inspection.

Now you merge the stuff and deploy it to staging environment. The Product Owner can now show it to stakeholders for more feedback.

More iterations might happen until it's "Done".

It's not exact science, it's complex, but this is the flow of working and collaboration.

Because one part might be delivered slower than the others, you (the faster one) may switch to work on something else. You may even demand feedback on partial work (design and frontend with fully mocked backend).

These things can be smoothen out in the Sprint Retrospective. In a true cross-functional team, the frontend can do some design and the backend can do some frontend (and/or vice versa) so that all the Developers deliver at the same time and you don't have to wait on one another. It's all planning, expertise and capacity.

Separating the people by expertise doesn't help at all, it only makes things worse. It makes the feedback loops longer. So, while you may think the User Story is "Done", you actually haven't received (yet) some feedback which will make you update it again, as a "bug".

There's no splillover if you expect it. You should actually want this feedback ASAP to get "Done" with it. Obviously, if you think it's "Done" and some unexpected feedback comes, you need to put more work in it and have less time available for other User Stories or Bugs.

3.How to commit on something that is so uncertain (other people's work)?

Along with inspection and adaptation, transparency is the third Scrum Pillar. Just be honest and collaborate to deliver the common User Story, to achieve the common Sprint Goal. This is commitment.

In Scrum, commitment was changed to forecast because the former has bad implications on the quality of work.

After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint.

Answer 4

If I understand you correctly, you wanted to title the question with "Intra team dependencies" - the dependencies are occuring inside the team. You should try to establish cross-functional developers, not just cross-functional teams.

Use pairing of developers of different disciplines (one backend with one frontend developer) or mob programming (the whole team sits around one computer) to improve the missing skills of the team members.

Ideally, each developer of the team can do any task at any time. In practice, you will have experts for each topic, and the rest knows more or less what and how to develop in that topic. The experts are consulted during development or explain details if estimations show big differences between team members.

You might be interested in search results for "scrum comb shaped" like https://www.linkedin.com/pulse/which-letter-shaped-employee-you-gaurav-sharma

For the estimations, @alexandru-jieanu already wrote an excellent explanation.