I think anopres was right: the best way is to avoid multiple projects at the same time with scrum. Do everything to convience that running too much in parallel is not efficient.
Let us assume 5 projects each about 3 months for team with 5 people.
Approach 1: each person works on single project in team
- 1/5 speed of delivery per project gives 15 months of delivery for all projects
- Every single person is expert but only in own project
- No team spirit
Approach 2: 1 sprint per project, switching projects
- Every 6th sprint work on project
- Too long time between project work - not regular incremental value for project (for product backlog yes), easy to forget, effort needed to restore context,
- First project delivered after about 12-13 months (assuming 2 weeks sprint)
Approach 3: 5 projects in single sprint
- Requires too much detailed split of tasks just to fit into sprint
- Very little incremental build per project
- Delivery of first project after about 12-15 months
Approach 4: recommended - Serialized work
- Team works on single project after project
- First project started and delivered after 3 months
- Second project started after 3rd month,delivered after 6th month
- ...
- 5th project started after 12th month, delivered after 15th month
- Team highly focused on project, intensive research and collaboration with customer
- Whole team has general good knowledge about all projects
- No waste time on context switching
- Require good team cooperation (conflicts can slow down delivery).
As you see, solution 4 is generally better because projects are deliveried much faster, team works together and efficient.
Other approaches includes waste time from context switching, no full team collaboration, very long total delivery time of all projects etc.
And what about backlog grooming? If team works on single project at once that is simple - everybody will join. If there are multiple projects we may need to delegate single people to separate grooming sessions (not full team is involved).
It is important to convience customers that starting 2nd project after 3 months will still result in faster delivery (after 6th month) rather than if we start it immediatelly with all others.
It is an illusion that managers see - we start 5 projects at once, we work hard and deliver little by little. In the end this is not efficient however.
That is why I do not belive that scrum is efficient for multiple projects in parallel, it is very tricky to match it into framework and work according to scrum rules. Sometimes it may be good having 2 projects to keep all people occupied, but the more projects we add the less efficient scrum will be.
Maybe kanban is an alternative just to see the progress and team work (not so strong like in Scrum team)?
Regards,
Adam
