In my team, everyone would like to do everything, including backend, frontend, middle layer. I told them that we should divide the work according to roles and area of expertise.

What are the pros and cons of dividing the work vertically (each user story is done by the same person from the back end to the front end) versus dividing the work horizontally (each abstraction layer is done by the same person)?


6 Answers 6


These here are good advices,I guess the answer depends on your point of view. Here's how I see it...

  • Divide the project vertically so that each iteration when completed yields a usable subset of the whole.

  • Divide each iteration horizontally as you work together to achieve the goal.

  • Re-use and refactor work done from previous iterations so that you grow the system coherently.

  • Make sure each member get a taste of all aspects so that all can work interchangeably and none feel uncomfortable with any parts. this will allow you all go gain and learn the most while ensuring the project will not suffer should a bus veer off dangerously close to one of you.

  • Prefer working together on a single aspect rather than each on your own piece. This will make it more fun and you will gain peer reviews almost for free.

  • Prefer the tools that make team work fun (git) over tools that sow fear and uncertainty over your code (VSS, TFS)


Break each user story up into tasks, and then see if people want to split them.

The risk is that if one person spends too much time on a certain related set of features then others may not understand that code as well, and that person becomes the expert for problems there.

Since everyone can work on each level, it may be that at times it just makes sense to have one person do the task, but it depends on how complicated the work is going to be, for some sufficiently complex user story it may make sense to have 2 or 3 people split the work and get it done.


Good question. I would say it may worth to divide the work frontend, backend - server side and database design. However having multi-talent team would be benefit for project. So, it worth to consider every one knows and understand each area what is going on and based on expertise spend more attention on that area and guide the other members on that area. bascially i grown up with that team culture.


What about:
Instead of dividing the work according to roles and area of expertise,
"swarm" together and tackle 1 by 1 user story as a team (or pair)


  • Sharing of knowledge across team members
  • User stories get done and not tasks (we care about done user stories and not done tasks)
  • Encourage team to focus on features, instead of tasks

Google Forming, Storming, Norming, Swarming

  • This only works if the work can adequately be divided into chunks the entire team can work on in parallel, and if your team has actually reached the final stages of group formation. Otherwise it degenerates into constant cross-talk and indecision. Apr 11, 2011 at 14:16

In our team we have some role functions that we turn over each iteration, so everybody gains knowledge in some other areas.


You're dealing with people and each team has a different DNA. What works best for your team & product, might be bad practice in another situation.

Just let the team try it their way, and discuss after a few weeks what went well and what went wrong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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