In other news, I am cracking on creating the SEO Product course content (name to be determined).
I’m not sure when it is coming out but I am putting my head down and cracking on with it as much as possible. It will include templates and examples to help anyone work more effectively with product and development teams.
Literally, the framework I’ve been using to release enterprise product features, and platform migrations and have client teams tell me I am a “super product manager”.
Again, thanks to those beta testers in the summer gave me a lot to think about!
Stay safe.
Adam
A dev backlog can quickly become cursed 🎃.
A product and engineering team can quickly become overwhelmed by the number of tickets in their ticketing system for a feature, product or initiative. This is known as a noisy or bloated backlog.
As an ex-PM, I’ve witnessed and experienced the impact of noisy and bloated backlogs on getting things done. It’s a problem that SEOs might not see but it directly impacts their ability to get things done.
What you thought bloat was a problem for Google’s index?
Think again.
In this week's newsletter we’re going to cover:
📋 What is a dev backlog?
🗂️ What is backlog management?
💀 The curse of dev backlogs
🤷 Why should SEOs care about noisy dev backlogs?
🚿 How SEOs can lift the curse and cut through the noise
📋 What is a dev backlog?
A backlog is a to-do list for development and product teams that is found in Jira, Azure and Trello.
A backlog is usually made up of three components:
🎬 Prioritised WIP - A set of work-in-progress prioritised items
🎟️ A to-do list - A to-do list of items (known as tickets)
🚦 List of prioritises - A clear priority to the items
🗂️ What is backlog management?
The process of prioritising the development to-do list is called backlog management.
The process of backlog management is done by the product manager/owner and engineering team. The process is usually a meeting with people sat around a screen doing the following:
🔧 Updating tasks - Review and update the requirements in the tickets.
🚦 Prioritising items - Changing the priority of tickets based on the roadmap.
💥 Deleting items - Delete redundant tasks within the to-do list.
The goal of backlog management is to break down tickets into smaller chunks and get them ready for the developers to work on.
💀 The curse of dev backlogs
The problem with development backlogs is THEY GET NOISY 📢👻.
I’ve had first hand experience of this as an ex-PM who was accountable for the product and development backlog at DeepCrawl (now Lumar).
The problem occurs because teams keep adding and adding dev tickets to the development backlog ticketing system (we used Jira like most).
Before you know it you’ve got hundreds of tickets creating a bloated and noisy backlog.
The problem is compounded by different teams (marketing, sales, design, etc.) just wanting to “add” their own requests into the backlog.
Very quickly the team realises they’ve been cursed with a bloated and noisy backlog. Full of tickets that quickly go out of date or are sometimes just a title with no context.
Why does this matter?
A noisy and bloated backlog slows down the release of features.
As the team needs to spend a tonne of time during the backlog management process sorting through hundreds of tickets in the backlog. It adds extra time to each meeting and conversation.
🤷 Why should SEOs care about noisy dev backlogs?
It can impact an SEO team's ability to get technical recommendations implemented.
If you think that it doesn’t impact your work, well it is quite a common problem product managers need to deal with inheriting noisy backlogs.
The other issue is that we as SEOs don’t help the situation.
No matter what organisation you work in, SEO requests will add more noise and bloat to a dev team's backlog.
The direct impact of adding even more noise to the development backlog is:
🗓️ Planning tickets takes longer
📃 Gathering and reviewing requirements takes longer
📳 Dependency on other teams increases (which adds even more time)
The indirect impact of adding more noise (tickets) to a dev backlog is that:
😖 Teams are uncertain about what to release in the large to-do list
🧹 Fewer priority tickets are forgotten as they are pushed down the backlog
🚮 Tickets are deleted in the confusion as teams try to reduce the noise
🚿 How SEOs can lift the curse and cut through the noise
So, how do we lift the curse of bloated backlogs?
As SEOs we need to cut through the noise of requests by doing the following:
🚦 Ruthlessly prioritise
🛤️ Dual track backlogs
❌ Delete bloat
🚦 Ruthlessly Prioritise
One of the most important actions to help cut through the noise is to make sure that you are ruthlessly prioritising your SEO recommendations.
One of the biggest mistakes I see SEOs making is trying to fill the backlog with endless tasks based on SEO tools (the things I’ve seen with enterprise crawling tools as a PM/SEO).
The problem is that these opportunities are not in line with the business, product or development goals. So, the result is that the recommendations are never implemented.
Again, you’d be surprised at how many tickets and tasks are rejected by-product and development teams in an effort to reduce the noise. It’s quite common and cutting through the noise is all about being able to answer the question: “Why? What is the impact of the work once it is implemented?”.
Instead, SEOs should be ruthlessly prioritising and connecting initiatives/tasks to value by understanding the business strategy.
Recommendations:
Understand the wider business strategy and goals.
Understand the product and development roadmaps.
Create an SEO strategy that helps drive business or product strategy
Create forecasts or model the value of your SEO strategy and roadmap
Create a roadmap with 3-5 initiatives (bets) that will help achieve the SEO strategy
🛤️ Dual track backlogs
Another key step in helping to cut through the noise is to make sure you have a place to store rawSEO tickets that isn’t in the development backlog.
One of the biggest lessons I learned as a PM was that Jira is the literal worst place to keep raw user story tickets (I don’t hate Jira but I’ve come close many times).
One solution to keep unready tickets was to create a separate product backlog to the development backlog.
The process was quite simple:
The product roadmap stored all the big bets and ideas to achieve our product goal.
The product backlog was the space where the initiatives were broken down into tickets.
Tickets were discussed and rules were rewritten until everyone was happy with them.
The tickets were marked as ready and moved across to the dev backlog when needed.
This simple but powerful change reduced the noise in the backlog considerably. The dev backlog no longer became bloated but instead had ready tickets which were easy to review.
As SEOs, we make the same mistake I learned to avoid at DeepCrawl. We create Excel documents with “action lists” in them and then throw them into the dev backlog.
This not only adds to the noise and size of a backlog but also means that tickets in that list might still be “raw” or unready. The ticket is written but it could be too big to fit into an Agile iteration.
Simply by adding an SEO product backlog you can help to reduce the noise by creating a new process that forces SEOs and development teams to work together to get tickets ready.
Recommendations:
Create an SEO Product Backlog to manage the SEO tickets.
Migrate tickets from the dev backlog into the SEO product backlog.
Work with your dev and product team to make tickets ready.
Move tickets when they are ready to be worked on by your development team.
❌ Delete bloat
Finally, an important ritual to get used to is deleting tickets in the dev backlog that are not helping you accomplish your goal.
One of the biggest problems with dev backlogs is that everyone can’t let go of tickets that are there to “help them remember the one task”. The issue is that if you write a vague ticket with only a title, a few weeks later you will not remember why you wrote it.
Tickets like these add to the noise and actually take brain power away from the team.
So instead, product and engineering teams go through Jira to make sure their tickets are adding value to the backlog. If not, they ask around to see if the ticket is important and needs to be kept. If not, it is deleted.
So, teams should ALWAYS make sure that tickets NEED to be deleted.
This is also why having an SEO product backlog is helpful. If the ticket is deleted then it can just be quickly copied and pasted with no fuss.
As SEOs, we should be working with our product and engineering teams to help cut the index ticket bloat and help reduce the noise in their backlogs.
Not only does this build trust but it also helps get priority tickets implemented faster because you’ve created clear signals about which ticket is important to implement.
Recommendations
Review weekly the tickets in your SEO product and dev backlog
Archive or delete irrelevant tickets that add no value in achieving your goals
ALWAYS make sure you double, triple check before you delete anything from Jira.
📌 Summary
The key things to take away from cursed noisy backlogs are:
Backlogs are to-do lists - A development backlog is a to-do list for dev teams.
Backlog management - This is the process of prioritising the tickets in the dev backlog.
Cursed backlogs – Backlogs can become noisy & bloated from years of adding tickets to them.
Impact of noisy backlogs - Teams can forget, delete or prioritise tickets very easily.
Managing noisy backlogs - SEOs need to focus on prioritising, creating dual backlogs and learning to delete the cruff from their to-do lists to cut through the noise.
Newsletter of the Week: Don't miss the latest news in SEO - Subscribe to #SEOFOMO.
Not only that but the newsletter also includes:
SEO tools to check out every week
A new list of SEO & Digital marketers to follow every week
SEO & Digital remote jobs
#SEOFOMO giveaway to win prizes
If you’re an SEO or digital specialist and want to avoid FOMO every week, this is the newsletter for you!
Read: Outcome-driven roadmaps - My own newsletter that takes you through the steps of creating an outcome-driven roadmap that can help cut through the noise.
Read: Inheriting a Product Backlog- Another old medium article but again useful to understand how product teams handle noisy bloated backlogs.
Read: Backlog management – My own newsletter that talks about how SEOs can manage their own backlogs.
