Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com May 4 '11 at 13:30

This question came from our site for professional and enthusiast programmers.

4 Answers 4

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).
share|improve this answer

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.

share|improve this answer

I can't believe you truly have one-man teams. OK you may just have one developer, but what about the project sponsor and QAs? They may be working on other teams as well but they're still stakeholders of the project, as such, you have a scrum team. People can be in more than one scrum team at once.

In any case, the problem with the solution you propose is the team is focussed on different things; you're not working on one problem. You each have no incentive to get involved in other people's code because it's not your project. I suggest you merge the projects into a larger team that manages several "micro-projects", but with the whole team concentrating on one sprint goal at a time. That way everyone works on each of the micro-projects and you don't end up with unshared domain knowledge.

share|improve this answer
Yes we have one-man teams in the sense that a customer will order some small app or some data processing, and one man will be assigned to deliver this. My intention was to force the sharing of code, responsibility, technical knowledge, domain knowledge by using a micro-project Scrum team. Note, that the projects often are so micro, that there is not enough work for an entire sprint. –  Morten May 4 '11 at 13:40

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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