Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been wondering if it would be smart to form a single scrum team for several tiny projects. I am aware that it would be very hard to state a single sprint goal, if a team is working on several different projects. On the other hand: Putting projects that usually are assigned to single developers in a common team backlog would (IMHO) benefit by the synergies of a scrum team. I should mention, that the projects does not vary that much from a technical perspective.

I am in a consultancy department where we have projects of very different sizes. For some time I have been working on a larger project using Scrum. Lately, the team has been disassembled, and I am left with one-man assignments. The idea came to me because I was getting more and more frustrated about not having my old teammates for sparring, QA and good old fashioned team spirit. I realized that about half of my department is working on one-man assignments. Then it dawned on me, that there might be a way out of the solitude: A Scrum of small projects.

I am keen to hear your opinion on the matter:

What do you think of the idea?
What are the pitfalls?
What are the limitations? How do i convince management that it is a great idea?


migration rejected from Sep 6 '15 at 10:40

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by durron597, MichaelT, Ixrec, GlenH7, Bart van Ingen Schenau Sep 6 '15 at 10:40

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 4 down vote accepted

I don't see anything wrong with working in a single sprint with several products.


  • Team collaboration. Anything you can do to encourage team collaboration will ultimately lead to more effective development. As team member learn from eachother you'll see better quality code, fewer defects and faster actual development.
  • Self Organizing teams make everyone's life easier. Waiting for Bob to finish his task so he can start the next most important one sucks. With a self-organizing Scrum Team, the next developer to finish something up can grab the next most important item in the backlog.
  • Regular releases. Release often, even with smaller projects you'll find that finishing a sprint every 2 weeks or 3 weeks (or whatever) increases predictability and gives you a nice interval for inspect and adapt which every development effort should use.

Potential problems:

  • You don't want multiple product owners for a single Scrum Team. Find someone to be in charge of the backlog. If you can't do it then find a Scrum Master and do it yourself (don't do both, it really doesn't work well).
  • Complex Workflows. You'll probably find that product A has X approval process and Y overhead while Product B doesn't need specific approval but has Y + Z overhead and so on and so on. As Scrum master you'll want to shield the team from as much of that as possible since they're no longer specialized in a single project. If you can, simplify the process after it gets to you but at the very least you'll need to do what you can to shield the team from the potentially complex overhead (which means more work for you).

Yes, absolutely!

Code ownership leads to problems like this one discussed yesterday.

You should also be doing code reviews on every piece of work, meaning at least two people working on each task.

You should also be able to suddenly reprioritise everything to finish one project quickly while delaying others.

One team, everybody is involved in everything.


Are you a developer or manager? Your proposal is applicable in very special scenario but it requires complete change in your development process and the way you do the business.

What did you do when you work as one team:

  • You had regular sprints with commitment, vision, meetings, scrum board, burndown chart etc.
  • Sprint was safe zone for the team
  • You had a product owner responsible for defining product backlog
  • You had a Scrum master taking care of you and dealing with your impediments
  • You had a global code ownership and team spirit
  • You was empowered to choose a task
  • At the end of the sprint you delivered probably shippable product which offered new business value to your customer

What you have now:

  • Multiple people working on separate micro apps - no shared code, people are not empower to select task from other team member
  • Probably each team member have own product backlog and own "product owner / customer"
  • Probably each team member have different deadlines - different sprint start, different number of sprints, different length of sprint
  • Team member has commitment only on his micro app

Do you see a difference?

  • What will be purpose of Daily stand up if each team member is working on different commitment?
  • What will be purpose of planning meeting if each team member is working on separate application? Will you have one planning for each team member / customer?
  • What will be purpose of Retrospective if team members doesn't work together - they don't share any code?
  • Will you have one review meeting for each team member / customer?

The first is Scrum, the second is not and cannot be. Narrow this to Scrum would be hard - it would require you to consolidate the process to single development team extending the application and sharing commitments for all customers - basically abstracting customers by single Product owner. Requirements from customers would be prioritized by product owner and delivered in sequence by priority.

Well as I wrote this I see that you don't need Scrum. You would get more value by switching to Kanban which will much better work in scenario where customers are not able to define requirements in the same time and require different delivery dates.

This is applicable if all customers requests some extension to single application or if it same type of programming - for example doing data transformation, integration packages, etc. If it is based on multiple applications you should not combine them in single team.


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