JIRA is a great tool for project management, but drawing the lines between JIRA projects correctly leads to painful collaboration across teams.
At my company, we have two JIRA projects: Monolith (
MONO) and Service (
MONO comprises 2 scrum teams that work across 3 legacy codebases.
SVC comprises a third scrum team that only works on a new API codebase: Dragonfruit.
To no surprise,
SVC have different processes for things like stand-up, testing, code review, and demos. However, the legacy codebases are starting to depend on Dragonfruit. When we need Dragonfruit work commissioned, we write tickets in the
SVC project and wait until they’ve been groomed, pulled into a sprint, and completed to un-block
Obviously, this is not a good system since it requires an almost waterfall approach where we as
MONO developers turn into POs for the
SVC project. If the requirements change, the scope of the
SVC sprint changes.
The best solution seems to be allowing
MONO developers to work in the Dragonfruit codebase but that messes up the
SVC scrum team’s demos and testing cycles, since they “own” that codebase. Unexpected changes to the API, potential breaking changes, that kind of thing. We could permit these breakages, in my opinion, if it led to faster development if and only if the two codebases have the same milestones.
Unfortunately, given that they are two JIRA projects they cannot share the same milestone reporting metrics (“Fix Version”). When new work is discovered in
MONO and ticketed up in
SVC, the estimated date of milestone completion in
SVC gets pushed back while it remains the same in
MONO. In our company, this is illogical when you consider that Dragonfruit has no business value except to support milestones in
Where am I getting with this? Oh yes, a solution.
Draw JIRA projects across milestones, ideally no more than two or three at a time. A scrum team should span projects and can have that number of sprints in progress at a time (or, if possible, let a sprint comprise tickets across projects). When a milestone finishes, archive and close the project. When projects are “owned” by one team then all other teams must conform to that team’s process, and when projects are tied to a codebase then business-value milestones must be arbitrarily split and tracked separately.