Component Teams in Jira
Kelly Albrecht
This talk will focus on a large scale Drupal project as a case study for this topic.
Products as Projects
If the focus or your group's work can be considered a product, then ideally, development delivers features into operation, to the delight of customers. While dividing different aspects of the product into individual Jira projects is always an option, the value flow for a product is usually best represented in a single ongoing Jira project.
Enter Component Teams
Even simple products can have a handful of critical components that benefit from focused improvement. If kept within a single Jira project, teams will naturally organize around these components, each concerning themselves with different subsets of issues.
Without frequent alignment activities, teams will typically each divide up their focus in Jira in different ways. Without a shared understanding and agreement about how an issue comes to "belong" to a Team, configurations and workflows can diverge fairly easily. As issues statuses are shared by all teams in the project, workflow divergence can lead to many statuses that aren’t relevant for other teams. This can lead to friction when transitioning issues or trying to make Jira Boards work, as teams need to find ways to filter the issues they are concerned with out from amongst other team’s issues, creates a feeling that issues can get lost. If each of these Teams instead applied a team-specific Jira Component to issues within their orbit (knowing issues can have multiple Team components), the broader team as a whole would experience more streamlined, cross-team collaboration.
Comments like, “we all know Jira, for better or for worse...” can be fixed! That doesn’t need to be the relationship with the team's arguably most used tool.
https://www.drupalgovcon.org/2018/program/sessions/component-teams-jira
This talk will focus on a large scale Drupal project as a case study for this topic.
Products as Projects
If the focus or your group's work can be considered a product, then ideally, development delivers features into operation, to the delight of customers. While dividing different aspects of the product into individual Jira projects is always an option, the value flow for a product is usually best represented in a single ongoing Jira project.
Enter Component Teams
Even simple products can have a handful of critical components that benefit from focused improvement. If kept within a single Jira project, teams will naturally organize around these components, each concerning themselves with different subsets of issues.
Without frequent alignment activities, teams will typically each divide up their focus in Jira in different ways. Without a shared understanding and agreement about how an issue comes to "belong" to a Team, configurations and workflows can diverge fairly easily. As issues statuses are shared by all teams in the project, workflow divergence can lead to many statuses that aren’t relevant for other teams. This can lead to friction when transitioning issues or trying to make Jira Boards work, as teams need to find ways to filter the issues they are concerned with out from amongst other team’s issues, creates a feeling that issues can get lost. If each of these Teams instead applied a team-specific Jira Component to issues within their orbit (knowing issues can have multiple Team components), the broader team as a whole would experience more streamlined, cross-team collaboration.
Comments like, “we all know Jira, for better or for worse...” can be fixed! That doesn’t need to be the relationship with the team's arguably most used tool.
https://www.drupalgovcon.org/2018/program/sessions/component-teams-jira