Kanban flow of front-end / back-end user story

Question

My team is currently splitting up our work in front-end and back-end related tickets, which I found out to be against agile. So, I am currently thinking about the flow of our Kanban board when working on the same user story.

My question is: If you have a user story which has frontend and backend work involved, where the frontend work depends on the work of the backend, how do you manage the flow of a card in a Kanban board? I thought about two options:

1. The backend dev assigns the user story to himself, puts the card in progress and then puts it back in the sprint backlog after finishing his work, for the frontend dev to pick up the user story.

2. The backend dev assigns the user story to himself, the frontend dev as well. The ticket stays in the progress column all the time. There is some communication needed to signal the front-end that it is ready for work.

What is the best way to communicate the "hand over"? Also, when should two devs decide to work on the same user story? In the daily?

Answer 1

Stories can have two subtasks; 1 for the backend and 1 for the frontend. The subtasks can individually have their own status. The status of the story can be set as the status of whichever task is behind according to the workflow. The status of the workflow can be changed by the developers by inter-communication.

Answer 2

None of these approaches are the best. The best approach involves eliminating the handoff between a front-end developer and a back-end developer. There are a few ways to do this.

One option would be to have the two developers work together, such as in a pair programming setting. They can talk through the details of their work, not only the happy path, but also edge cases or error cases. Instead of implementing to a spec which may not account for all the cases or meet the realities of detailed design and coding, the two sides are implemented together against each other.

Another option would be to develop a cross-functional team. Teach the back-end developers your front-end technologies and frameworks. Teach the front-end developers your back-end technologies and frameworks. Work toward a single person who could implement this work, perhaps with minimal review and guidance from a person with different expertise.

Not only will you solve the problem of how to visualize the work, but you'd be eliminating one of the wastes from Lean Software Development. You would be able to deliver faster, increase quality, and focus on value-adding work.

Answer 3

where the frontend work depends on the work of the backend

One thing that can help is to reduce the level of dependency between the frontend and backend work.

A good way to do this is to use mocks or stubbs. The workflow becomes:

• Backend and frontend devs agree on API changes for the ticket
• Backend dev creates a stubb or mock
• The frontend dev is no longer blocked and work can continue in parallel

Teams that get good at this approach can minimise the level of dependency and have fewer concerns with how the work is visualised on their Kanban board.

Answer 4

From your explanation, the first option would work but it can be better if your team has daily stand-ups so that the frontend and backend dev would be able to know when each other's task is completed. And instead, once the backend dev is down, he can assign the task to the frontend to take over. That way you would have any form of delayed risk that may occur.

The second option might work because a task in progress surely has a duration for completion. But I would suggest a mention for the frontend dev once the backend dev is down with his part.

But another option is to spilt the task in two so that each dev has his/her own card. The frontend card would be a subset of the backend card, which tells that the second card can't be done without the first being completed. That solves the back and forth that may occur, but I also recommend a daily stand-up for the team so that they can communicate between each other since their work depends on one another".

Answer 5

Agile or Kanban is based on situation agility and not on hard prescription what to do. With that being said, I have worked in both full stack development, backend only and some maintenance projects.

1. first thing before start of story I will suggest to have to clear contracts defined for data exchange between Ui & backend so that either one has no dependencies on each other and can work parallely.

2. For tasks division it can be one story with functionally testable result with clear definition of done. It can contain separate tasks for UI, backend and integration with testing which can be easily estimated. Backend & frontend developers can assigned tasks to themselvers, estimate & can work on it paralley & separately.

3. For efforts I will suggest to estimate at task level & calculate story effort by estimation of all tasks under it including testing & integration plus some buffer.

4. In agile it is expected to have itertations so if there are some bugs, or change in UI or functionality as per demo feedback capture it as separate improvement story or as Bug so that completed story can be closed and separate work can be estimated based on new requirements.

For keep track of all the bigger functionality please define epics as collection of stories in backlog grooming. All of this is based on my experience of few successful projects but everthing is customizable and depends what works in your team.