It's All Coming Together

If you've organised all of the projects that your team needs to do into a backlog, then you're already on your way to achieving all sorts of glorious outcomes.

Making a big old list of things, followed by unrelentingly grooming it and always using it as the focal point for all planning conversations solves at least a few of the problems inherent in wrangling a bunch of people together towards a common goal.

I don't recommend having two project backlogs though.

That just complicates things.

So, Is Everything Ready?

Sometimes, you're chugging along, working from your project backlog and generally having a merry old time creating all sorts of useful benefits for the business.

Then, uh-oh, it's re-org o-clock and all of a sudden you get merged together with another department who has been doing exactly the same thing.

No-one has done anything wrong in this situation, but you're still left in a crappy situation, because now you have two project backlogs, each representing a part of the whole.

Now, this isn't the worst situation to be in. Two departments working from their own backlogs, following their own slightly different planning processes and achieving their own outcomes is a perfectly sustainable position to be in.

But it's irritating.

Everything is just a bit more fragmented than it could be and a bit more siloed than it should be and rather than publishing a nice, ordered, structured backlog of the work, you have to keep making Confluence pages to pull everything together to keep your stakeholders informed about what the plan is.

Like I said, irritating.

So why not just merge the two backlogs together?

Oh Right, The Poison

Well, it depends on where you've stored your backlog(s).

I've used a few different mechanisms, but the one I have had the most success with recently is Jira Product Discovery (JPD), which is basically just Jira with a lot of the painful stuff removed and with the added ability to easily and quickly create views for slicing and dicing your projects.

In this specific case, the project backlog that I was maintaining for my department was in JPD, and so was the other backlog, so it was a simple matter to just use the handy dandy "merge backlogs" feature built into JPD.

Job done.

...

Ha! No.

In reality, there is no handy dandy merge backlogs feature, at least not yet.

There are tools that can help though.

For example, Jira has a lovely feature to bulk move tickets from one Jira project to another, and because JPD projects are just Jira projects behind the scenes, this functionality still sort of works.

I say sort of, because all of the fields in a JPD project are not quite the same as Jira fields, so if you've put any effort at all into customising your backlog (like say, adding fields to describe the owning team or the target quarter) all of that data is lost when you move a ticket from one JPD project to another, even if you have matching fields.

So, that's pretty annoying, but moving tickets does give you redirection, so it's still worthwhile to go down that path. When I say redirection, I mean if you have a JPD project with a key KUZCO and move KUZCO-235, KUZCO-347 to the JPD project with key YZMA, resulting in YZMA-1, YZMA-2, the system will remember that KUZCO-235 is actually YZMA-1 and redirect appropriately.

There is also the import/export feature, which lets you export everything from the old JPD project to a CSV file and then re-import it into the new JPD project, but that doesn't do redirection (which is useful for continuity) and also doesn't really work all that well for the links between tickets (i.e. X depends on Y).

There may be other mechanisms as well, but I didn't run across them in the research that I did, so they probably don't exist.

So, really the only option is a bulk move, followed by manual data entry.

Got You Covered

Of course, if you do the move first and then try to open the old JPD ticket to get the field values, you're going to be sorely disappointed.

So rather than a bulk move followed by some manual data entry, you need to take a snapshot of the data beforehand, so that you have a source of truth that you can restore from after the move.

There are other limitations that need to be accounted for as well, but rather than spend the next several thousand words explaining them in detail, let me show you the final process:

1. Lock down the original JPD projects so no-one can edit
2. Export all of the data from both JPD projects to CSV files
3. Loading all of that data into a Google Sheet
4. Take a named snapshot of the Google Sheet
5. Go through the snapshot and fix the data that didn't export properly :(
6. Move all of the tickets from both JPD projects to the new project
7. Go through every ticket in the snapshot and restore the data that was lost
8. Cry a little bit

One thing to be careful of in Step 2; make sure you consciously choose what you're going to move and what you're going to leave behind. If you've been using the project backlog for a while, you probably have a bunch of historical stuff and that can significantly blow out the amount of data you need to manually copy. I recommend just moving the stuff that isn't done.

Pay particular attention to Step 5, because doing a CSV export from JPD doesn't actually export all the fields properly. The good news is that the only important thing missing seems to be the ATLAS ticket links. There are other fields that don't export well (Delivery progress), but they are covered by the data that is included in the Jira bulk move.

For Step 6, you can't actually execute the move functionality in bulk from any JPD board, so you need to do a raw JQL issue search and do it from there. Make sure whatever search you've created to drive the move contains exactly the same set of tickets that you exported the data for in Step 2, or you're going to have a bad time. Also, sometimes you might run into an issue where you can only move X tickets in a single bulk operation. There is, as far as I can tell, nothing you can do about this, so I hope for your sake X is a large enough number.

For Step 7, I heartily recommend rallying a bunch of people together to divide and conquer the manual data entry required, or you will probably go mad. Also, it will take ages to do it alone, and that would leave the backlog unusable by anyone else until you're done.

Step 8 is optional, but cathartic.

This Is Going To Be Delicious

This is one of those rare cases where I have actually done the thing that I'm writing about, instead of just sharing my plans.

It was pretty much just as painful as this blog indicates, and I am lightly mentally scarred. Only lightly though, because really, we only had a few hundred projects to migrate, and I roped in a bunch of other people to make it happen over a few days.

Given that we've only just finished, I don't know if it was worth it yet.

It's nice having everything in one place, but honestly, it's not that much different than having everything in two places. Once we start creating views across the entire department it will probably be more useful.

I suppose everything is a bit more consistent now as well, which is good.

Rather than just migrate everything as is, I used the opportunity to consolidate the fields we were using and to remove any that were useless, aligning the department (10+ teams, ~150 people) on the same general flow and field usage.

Weirdly enough, on reflection, I think I actually enjoyed the work.

It's nice to do something where there is an obvious end and where you can immediately see the fruits of your effort.

I don't get that a lot.