8

In our company several teams will work on different components of several projects at the same time. For example, one team might make make specific kinds of software (or hardware) for some project(s), another team another specific kind of software. We use Jira projects to host issues for specific projects and Jira boards for sprints for different teams.

We face the issue of avoiding code duplication across projects, and have developed a set of core libraries which we use in those projects. While working on a project, some developer will realize that a piece of code they have written is of greater interest and should be extracted into a core library, or that some core code they are using has a bug, needs some more parametrization, or a new feature... you name it.

So they create a core library issue that goes into the core project's backlog. All these issues are reviewed, prioritized, and estimated in a core library meeting (once a week), and will be tackled according to their priority (alongside project-specific issues) in some future sprints.

Prioritization is done by sorting issues, and we put a sorted label on sorted issues (so we can search for non-sorted ones). Then we manually put one issue per core component to the top of the backlog in order for them to be tackled first. When some team puts such an issue into their sprint, they have to manually drag another item to the top of the backlog instead.

This is quite error-prone. Basically, what we have is the additional issue statuses "sorted" and "estimated" between "open" and "in progress". Reflecting this through the sorted label and their position in the board is rather cumbersome and error-prone. (For example, if someone moves an issue in some sprint up and down, this will be reflected in the core board, silently scrambling the order of issues the team might have had decided about in an extensive discussion weeks earlier.)

So what would be a better way to implement this?

sbi
  • 10,052

3 Answers3

2

If you want to track this in JIRA I would follow it through as if it were a new task.

So for example:

Let's say you have the story CORE-75: Foo the Bar.

Once it is decided which team will take the task, they can then create a new task: SUPPORT-123: Foo the Bar in Core.

You can then block CORE-75 with SUPPORT-123. Once SUPPORT-123 is finished, you can then go back to CORE-75. Either you can have the reviews merged, or review the code twice (once by the designated team, once by a more core-specific team).

This is really what you are doing anyway: Consider the core library as its own product/customer, don't go half way.

Erdrik Ironrose
  • 4,976
0

One approach is for the team to create a new issue for their sprint that links back to the core library issue. It's kinda like you're making a sub-task for a task but across the boards/backlogs.

Another approach is just to track this separately outside of JIRA. Export the existing backlog as CSV or spreadsheet and organize that.

By separating the issues from JIRA, you have flexibility to define the priority in the planning meeting and don't have to worry about JIRA's sorting algorithm on the boards and you won't have to use labels either.

In the prioritization planning meeting for the core library you can create a shortlist of tasks to complete for the core library and whoever is responsible/accountable for the core library can make sure these tasks are started by the different project teams and completed.

-1

There is a view that Core Libraries which encapsulate a lot of common, but unrelated functionality are a 'bad thing'(tm)

There are a few reasons for this

  • They pull in dependencies and code that you don't need
  • Changing them causes changes to all applications
  • No single 'owner'

In your case I think your division of tasks by the application the change would be made to is the root of the problem. A kind of reverse Conway's law.

I think the best solution for you would be to move away from having 'Core Libraries' Libraries should have a specific (small) set of logically grouped functionality. It should be possible to complete them. ie JsonParser, LogWriter etc it should rarely make sense to add a new feature.

However, assuming this would be a long and difficult task, as a secondary solution I would simply keep the core library tasks with the team that needs the functionality. ie.

Task : add feature X to product Y

Dev : hmm some of the code for feature X should go in a corelibrary.. I will put it there as part of this task

Ewan
  • 83,178