We have two developers working on the same project. One is doing the front end and the other doing the back end.

Everything is working well, however we have come across the developer doing the back end stuff and getting though it faster than what the front end developer is working on. Therefore the back end dev skips ahead to other stories that he needs to work on.

I'm guessing this is fine but I'm not sure what happens when the front end developer goes in and ends up not being able to get though all of the stories, and we have to stop because time has been spent ahead by the back end developer doing his tasks out of the priority order.

Should the back end developer wait until the front end developer to catch up or should he keep going?

If he keeps going, what do you do about the budget and not completing the sprint?

  • 4
    As the backend guy is doing stuff that needs be done anyway I would be careful interfering in any way. He's on a roll, apparently enjoying it (not telling you he's done and waiting for you to solve a problem for him). Asking questions would be OK (are they testing what they did match up before running ahead?) but better not kill the buzz and let them sort it out amongst themselves as long as they get along. Aug 23 '18 at 11:15

Slowing one worker down would be a very poor choice.

Things I would consider:

  • See if you can rebalance the workload. Some things aren't clearly front end or back end tasks, and you can shift more of the burden to the programmer who is running ahead.

  • In this same light, there is no magic about front end versus backend work: especially as they share a common purpose (application), API, etc. You could consider having the less busy programmer pick up some UI tasks. I would DISCUSS it with them at least, at see if they are open. This is a very personal thing, and some people just wont want to and others will love the chance

  • Bring in another UI resource to help out (even if just part time).

  • Start the backend programmer on another task, and have him split time between the two projects.

In short - be pragmatic, and efficient. Remember, agile (and its tools/processes) are just there to help. Rigorous adherence to dogma will not produce better results than pragmatism and flexibility.

  • 4
    The backend-devs can also work on tooling, which makes the whole team more efficient, like automation-scripts, the CI-Pipeline, Liners, etc. Aug 23 '18 at 7:56
  • 2
    If the client part is separated, the backend dev can also do the "backend part" of the client (the one communicating with the server).
    – Walfrat
    Aug 23 '18 at 11:59
  • 1
    I think the suggestion of having the back end dev work on front end is quite reasonable. Certainly helps to spread the knowledge. But I'd disagree a bit about the lack of difference between front end and back end. I do both on a single page app and the amount of knowledge and technique I had to pick up to work on the front end was incredible. Again, not saying it's a bad idea to have the back end dev get up to speed on UI, just that they might need to allocate considerable time.
    – DaveG
    Aug 23 '18 at 12:37
  • 1
    The less distinction between front end and back end the better. The more you can create full stack developers the better. You'll always have people stronger in one or the other, but it usually pays to have someone who can backfill for when the other guy goes on vacation. Aug 23 '18 at 13:33
  • @DaveG Easy to argue either way on how much difference between fronend and backend. Depends a bit on languages too (like nodejs backend). There do tend to be significant knowledge base differences, but as almost everyone here seems to agree, they are learnable and good to have the knowledge more broadly shared (IMHO). Aug 23 '18 at 14:03

Make your fast developer learn how to do 'front end' tasks.

Splitting developers up by language or framework experience is just something HR does to make it easier to advertise for employees.

In real life developers are, or should be, constantly learning new languages, frameworks, software tools etc.

Not letting some developers work on a subset of tasks is slowing down your project and impeding the developers careers


If you are practicing agile there shouldn't be a front end dev and a back end dev, there are two devs. They can break up work based on their strengths, and the back end dev can do the more complicated back end parts and vice versa, but they should both be able to back each other up. Your back end developer may not be as efficient at developing front end parts, but both are needed to get any value from the project.

The concept of font end or back end developer is largely outdated, any developer should be able to learn the relevant technologies to become proficient. This is beneficial for you as a manager/product owner because you get more benefit from your developers, and it's beneficial for developers making them more marketable and better potential for career growth.

  • I agree with what you're saying about agile, but completely disagree when you say that the concept of backend/frontend is completely outdated. Agile came way before the separation between frontend/backend. The problem is that it conflicts with the idea propagated with agile principles. And that said, the agile principles is actually what is outdated (in this context), as it's not considering specialization. In the past you could easily be a fullstack dev. Nowadays, you can never be a senior fullstack. technology is evolving too fast, and there's no time to study about all areas. Jan 29 '20 at 8:29

Therefore the back end dev skips ahead to other stories that he needs to work on. I'm guessing this is fine

From an agile perspective (specifically, scrum) it is definitely not fine. The back end dev should be helping the front end dev finish their stories. For example, they could help write or perform tests, do some documentation, help prepare for the demo, etc.

Should the back end developer wait until the front end developer to catch up or should he keep going?

Waiting is an option, but again, the best solution is for the back end developer to help the front end developer in whatever way possible.

In agile, the goal is to optimize for the team, not the individual. The important thing in a sprint isn't necessarily to keep everyone busy, but to deliver finished, shippable code.


This sounds like a very familiar situation.

Early on in my career I worked for a small startup. It was a three person team. A back end developer (a seasoned PHP developer), a front end developer (me, fresh out of college) and a graphic designer.

I was the slow front end developer.

We weren't practicing agile, but we did find a way to utilize our resources to the fullest, which is the true root of your question. The back end developer would inevitably surge ahead of me. He had to know enough "front end stuff" to get the information right on screen. He knew basic HTML, and that was enough to verify the output. Later on I would come in and completely rewrite the UI layer. If any AJAX-y stuff was needed we designed and agreed upon that ahead of time. We treated AJAX calls like any other API call between server and client — you need to think about it ahead of time.

So just let each work at their own pace. Design ahead of time so back end and front end developers know the data structures before work starts, and then turn each one loose. It sounds like your challenge is keeping up with the back end developer, not speeding up the front end developer. Speed comes with practice.

So stories get completed in longer periods of time. Split the stories into smaller ones (waaaaaaaay smaller) to limit the work in progress, lengthen your sprints or just live with it. Which one you choose is irrelevant, as long as people are constantly working, and working software is being delivered. That's the true spirit of Agile Development.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.