How do you see the forest but keep teams focused on their own trees? With Subprojects.
Assembla recently introduced the Subproject feature to help service providers and companies with large projects handle two use cases:
Many client projects being serviced by one or a small number of development teams.
One complex project being developed by several development teams.
Subprojects, along with the new Tag feature, can help these companies manage their backlog better, let teams focus on their own work, and give clients and customers a restricted view of their own ticket lists but nobody else’s. It helps managers manage the “big picture” while making teams more efficient.
Use Case #1: Many projects served by one team
What if you are a service provider or custom development firm creating software apps for multiple clients? Or part of a corporate web site or application group serving multiple internal customers?
Then you want to maintain a master backlog of tasks, but also keep track of which tasks belong to which clients. You may also want to let your clients submit requests directly to the master backlog, and later view the progress of those tickets, but not be able to see tickets submitted by anyone else.
With Subprojects, you can set up a “Master Space” for the entire development team, then a series of “Child Spaces,” one for each client. The process will then work as shown in the diagram below.
As clients submit tickets, the tickets are tagged with the child space name of each client (in the diagram, “C1,” “C2” and “C3).
The space owner and designated tech leads have visibility into a master backlog of all submitted tickets. They validate and refine the tickets, then sort them in order of priority, taking account of the importance of the individual tickets and the need to balance the demands of the clients.
They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).
The development team can see all of the tickets in the Milestone, Planner and Cardwall views, sorted by priority, and tagged by the client.
If you want to give clients visibility into their tickets you can do so, but they are restricted to the tickets in their own child space - they can’t see tickets (or messages, or repositories) from any other child space.
Use Case #2: One project developed by many teams
What if you are working on a large project that is being created by many teams - perhaps an architecture team, a UI team, and a backend team?
Then you want to maintain a master backlog of tasks, but let each team keep track of its own tickets, documents and code, without having to sort through the work of the other teams.
With Subprojects, you can set up a “Master Space” for the complete project, then a series of “Child Spaces,” one for each development team. The process will then work as shown in the diagram below.
The product owner submits tickets to the backlog. The space owner and designated tech leads validate and refine the tickets, sort them in order of priority, and assign them to individual teams (in the diagram, “T1,” “T2” and “T3). They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).
Each development team can see ts own tickets in the Milestone, Planner and Cardwall views, sorted by priority. They also see only their own messages, documents and repositories.
The space owners and tech leads can always see the “big picture” and communicate with all of the individual teams, while the team members can focus on their own artifacts, without needing to filter out work from the other teams.
There are several variations on this use case. For example, tasks can be assigned to Git forks or Subversion branches, and each fork or branch can be managed in a child space.
Use Case #3: Many projects supported by many teams
What if you need to support multiple clients with multiple development teams? Subprojects and Tags can help you there too.
You can set up a “Master Space” for the entire organizations, “Child Spaces” for each client, and child spaces for each development team.
Now tickets are tagged by the source (client, product owner, etc.) and by the assigned team. Managers can maintain the master backlog and see the global view at all times. Teams can focus on their own tasks and code. And clients can be given a limited view of their own tasks.
How to use Subprojects
- To see how to set up a master space and child spaces, see Vadim Todorov’s blog post: Team Management like a Boss
- To learn more about using Tags and Subprojects see Andy Singleton’s post: Long Ticket List? Tag with Features, Teams, Clients
- The Subproject feature is available as part of Assembla Portfolio.