As projects wrap-up and start-up, you may have the challenge of accommodating end-of-project vacations, hiring new team members and reforming teams to best meet the needs of the new project. Teams should be kept together as projects move in and out, but that is not always possible, particularly in some industries. To help you visualize and figure out what new teams will be formed and when or how to best assign your existing teams to new projects, use your laminated scrum-ban-plan board.
- Along one side, write the major Epics for each project that you think may need their own team.
- Along the other side, write the timeline. Depending on the length of your project, increments can be in weeks, months or quarters.
- Use sticky notes for the names of your prospective team members.
- If you need to ensure you have a particular mix of skills on each team, use different colours for different groups of skills, which is what the illustrated example shows.
- If the exercise is to figure out how to assign existing teams to new projects, the color coding could reflect any other parameter, such as identifying a need for new hires, who may need training, etc.
- Like you would do for Release planning, work with your key team members to determine your teams, based on their skills, when they are available and what the project needs.
The above image illustrates a possible result of the team planning exercise.
How do you plan or define your scrum and kanban teams during project ramp-up and ramp-down? What tools do you use? How do they help you visualize what teams you will need?
Sockets and Lightbulbs 
October 2, 2013 at 6:48 pm
This approach seems to be geared to expect a high level of team change, each time a new team comes together it will go through the different stages of forming, storming, norming, and then finally hopefully performing. Better to keep your teams together to create long lived delivery teams that outlive projects/epics. When available they pick up the next prioritised item from the portfolio backlog. A small pool of SMEs may need to be available to help teams build skills in new domains. With this approach you will need to handle team changes as the exception rather than the norm which this visualisation is trying to support.
October 2, 2013 at 7:39 pm
I completely agree – keep teams together. In many software development environments, this visualization should rarely be needed. I could imagine it being used if there is a major shake-up in the portfolio or in the business structure. However, in heavily project driven industries, like game development, entertainment and 3rd party work-for-hire businesses (multiple industries), projects can last for years but when they end, they end, and new projects, which may have completely different needs, start up. As much as possible these industries try to keep teams together for the next project, but it’s not always possible, or ideal. Using the board can help visualize and plan that. This exercise is about business planning. It could even be used to fit existing teams into an upcoming project and plan for their vacation time between projects. I’ll update the post and clarify that context.