Get certified - Transform your world of work today

Close

Scrum with a Small Team and Multiple Projects

18 August 2015


At my company, Scrum was adopted as our Agile development framework, and our team began working on the maintenance of six projects with different technologies.

Our Scrum team has these roles:
  • 4 Java developers
  • 1 Product owner
  • 1 QA analyst
OK, but how could we work on all our various projects and still take advantage of the benefits of Scrum?

It was not possible to create a team for each project, nor even to stop working on any of the projects. So we've started developing our sprint backlog via these steps:
  1. Predict how many real shifts we will have during the sprint.
  2. Estimate the priority items from among the six product backlogs, using Planning Poker.
  3. Set the percentage of importance that each project will have in the sprint.
  4. Move those items to the sprint backlog.

Sprint Backlog

In the last three years, we have had success with this approach. Have you faced a similar case? Please be sure to comment and share your experiences.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (13 ratings)

Comments

Tim Baffa, CSM, 8/18/2015 10:14:20 AM
Interesting. A few questions and observations:

1) Who sets the % of importance among the 6 competing projects?

2) How long are your sprints?

3) The item numbers in the Sprint Backlog don't conform to a prioritization order or the original item number from their product backlogs. Is this intended, and if so, why?

4) What were the business reasons for not investing in more teams to support 6 separate products? To me, this seems like a lack of recognition for organizational capacity.

5) If I read your Sprint Backlog correctly, the lowest priority "project" is project #6, and in the event that the team overestimates their productivity, it would be those stories (or that project altogether) that would be considered for descoping.

6) There is plenty of empirical evidence that supports higher productivity when a team can focus (Scrum Value) on a single Sprint Goal. It seems that in your framework, you are promoting up to 6 Sprint Goals per iteration. While you may have had some success with this approach, I firmly believe that your team would be much more productive if they were able to focus on one product/goal per sprint. I would be very interested in seeing the difference in productivity if your team was able to work on a single product each sprint, as opposed to the "overloading" model as presented.
Peter Derwa, CSM, 10/19/2015 6:41:50 AM
sprints should be based on project lifecycles, not on team processes. The importance of the items on the list are now indeed quite strange. In my opinion you will always allocate time from colleages to work on items, you could have someone joining your project partially or completely. When partially, he could also spend time on other tasks on the backlog of the other projects where he is allocated to.

I would also try to deliver one project completely before delivering another one (if possible according to requirements and impediments)

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe