Jira Organization for Platform / Product Line Development

[Peter Kahn]

How have you structured your jira projects when developing a platform of shared components?

We have two main product lines and used to have a defect tracking + greenhopper project for each. Support, operations , program management created issues in the defect tracking project and the dev team handled implementation in the greenhopper project via sprints.

Now we are moving to having two "platforms" comprised of components of which we share some between them. How should we organize jira projects to support the following goals:

• Easy reporting of issues for the platform
• Easy to find all issues related to a release
• Easy linking of platform issues to component work (planned or completed)
• Clear understanding of what's been released
• Ability to track component changes to platform issue
• Easy to know what needs to be tested or implemented on platform

What I'm thinking of is this:

Two "platform" jira projects for defect tracking only. All customer requests and reported bugs begin here. In orbit around these we have a series of greenhopper projects. We have one greenhopper project for each component and we use release lifecycle or teams to determine how to draw the boundaries. The normal use cases would be:

Issue Originates At Platform Level

• Issue found in Platform and determined to involve components A,B,C
• Linked issues created in component projects for A, B, C
• Sprints complete and A,B,C work is finished
• Final testing performed during platform integration
• Platform Issue closed

Issue Internal to Component Originates At Component Level and Resolved

• Issue found in component A
• Sprints complete and A is finished
• During component integration with platform standard test suite finds no problems

If a problem was found then we'd create a platform bug and go through the Issue Originates At Platform Level case

Please let me know if you have had to deal with this situation, if you have any suggestions or if you see any pitfalls to this approach.

Thanks

Peter

Questions remain:

• How should we handle deferred issues in the components?
  • In the defect tracking workflow we have a deferred and awaiting triage state
  • In the Greenhopper we have open-inprog-resolved-closed
  • How do we differentiate between backlog vs deferred, by the ranking?

[boardtc]

1 or 2 Kanban boards look like the answer here, did you give them a go?

You can distinguish by ranking, another option is to create an Out Of Scope Backlog or Out of scope label.