10

On past projects, I've seen a common theme. A particular feature will require very simple front end work (eg. make a button on a screen that says "submit"), but there will be a large amount of work on the backend. If we have say one backend developer and one front end developer, the backend dev finds themselves often doing work that doesn't get feedback, is behind the front end by several days or more, and so on.

Some solutions would be to either slice the story in a more even vertical between the two types of work, to go less "in-depth" with the backend work, or to work to make your developers cross-functional between the back and front end work, but I haven't had a situation yet where that's really a reasonable solution. Is there anything else that can be done?

agentem
  • 181
  • 1
  • 7

3 Answers3

12

One approach I have seen work is to initially stub the backend functionality before doing the detailed development work.

These are the steps the team takes:

  • The backend developer defines an API that the frontend will use for the feature
  • The backend developer builds a very simple stub that allows the frontend developer to make API calls and get back reasonable results (e.g. they make the call getUser() and always get back the same user details)
  • The backend developer carries on with developing and when they are ready swaps out the stub and swaps in the real code
  • The frontend developer is no longer blocked and can get feedback on their work

It is worth noting that this approach often helps with testing as well.

However, although this approach is effective it is not the best solution to the problem. The best long-term solution is to cross-skill the developers so that they can do both frontend and backend development. This gives the team a lot more flexibility on how they do their work.

Barnaby Golden
  • 19,475
  • 3
  • 17
  • 50
  • 2
    I second this. :) However, in my case, I have the front-end developer defines the API and build the stub incrementally. During this phase, the back-end developer can see the stubs being developed and get to work on the back-end code. – Amir Syafrudin May 24 '16 at 23:07
  • You could try to develop the backend services/API in the previous sprint, if you have the priority determined already. This could be a technical story which will help the team to complete the UI/Frontend story in the coming sprint. Stubs, services, etc. could be covered in the first sprint along with unit testing and UI in the coming sprint to complete the feature. Another option is increase the number of backend developers if it is feasible – Mincy George May 26 '16 at 05:37
2

I assume that since the question was tagged as scrum, you are using sprints and stories.

A Scrum story has the following basic conditions:

  1. The story description relates to a user persona, such as administrator, and either describes a business value or addresses technical debt.
  2. The story acceptance criteria are measurable and testable.

Given your example and the story definition; let's look at your solutions.

  1. Slice the story in a more even vertical between the two types of work

    a. This is not valid because having a story to add a button to the UI without adding any functionality is delivering no value and would be considered a bug if a user clicked the button and nothing happened.

  2. Go less "in-depth" with the backend work

    a. This may be a viable solution, but in some instances you can't break the "back-end" work into multiple functioning stories that each deliver value.

  3. Work to make your developers cross-functional between the back and front end work

    a. This is the most viable solution because you are able to have a single story, but it is not always viable with a more complicated UI. On top of that, there is the time constraint and learning curve of brining both developers up to speed in areas outside of their comfort zone.

The "Solution"

What you are describing is: multiple tasks belonging to a single story. Multiple developers can work on a single story, and that story is done when all of the tasks are completed and verified.

These tasks should be identified during the teams planning session prior to the start of the sprint.

Note The problem comes when you have backend work that goes across multiple sprints at which point there can be a debate about the best course of action. In my opinion, I would break the technical work into multiple stories and the UI work would be a part of the final sprint / story.

drneel
  • 383
  • 1
  • 9
2

If we have say one backend developer and one front end developer, the backend dev finds themselves often doing work that doesn't get feedback, is behind the front end by several days or more, and so on.

I don't understand how the situation you describe could result in the backend dev not getting feedback - could you elaborate on that?

But as for backend being days behind frontend, one possibility that occurs to me is to take a larger rather than a smaller view, and ask about the balance of work in your sprint. In my team, it is often the case that one subsystem has significantly more work than another subsystem in order to complete a story. In this case, we might do a couple things:

  • assign all the DefnOfDone tasks for this story to the frontend dev (documentation, testing, etc)
  • look for a story that had the reverse balance of work (complicated frontend, simple or no backend) to add to the same sprint

We also look for multiple "subsystem handshake" opportunities, similar to Barnaby's answer: stubbing out pieces & defining API early, so that we can verify the system is performing the round trip (user info in, properly received, backend info out, properly displayed) even if the values produced by the backend aren't yet correct.

Vicki Laidler
  • 3,640
  • 11
  • 17