🎒 Backlog Management for SEOs
🎒 Backlog Management for SEOs
How to encourage SEO and developer collaboration with task management
The SEO Sprint is a fortnightly newsletter that provides tips, guidance and advice on Product and Agile Thinking for SEOs who work with developers.
Many years ago when I was a junior SEO, I always believed that getting developers to do things was just a simple case of adding a list of tickets to Jira.
A small “gap” between the SEO to-do list and the developer backlog.
After years of experience working in a product and engineering team, I’ve realised that in reality the gap is wider than many realise.
In fact, any task list needs to navigate through complex internal procedures before it reaches the development backlog.
It’s easy for SEtickets to be forgotten, lost or ignored in the chaos.
Over the years as a product manager and product owner, I learned how to manage both a product and development backlog using simple techniques.
A lot of what I learned is very applicable to SEO specialists who work with development and product teams.
In this newsletter I wanted to answer the following questions:
What is backlog management?
How do product teams manage a backlog?
How can SEOs use backlog management to get things done?
Note: I hope this newsletter sparks ideas on how to tweak your own approach to working with developers and getting your SEO recommendations implemented.
👾What is backlog management?
A backlog is just an agile word for a prioritised list of tasks.
In product and engineering, this is usually the list of tickets in a task management system like Jira, Azure, Trello, etc.
Backlog management is a process that adds, adjusts, and refactors these tasks to make sure the most valuable items are being worked on by the technical team.
Although one person usually oversees the management of the task list (product owner role in a Scrum team), it’s important to note that this process is a team effort.
A product owner or individual is responsible for making sure business and development teams are constantly refactoring the backlog.
📈Why is backlog management important?
Backlog management is an art of collaboration that helps bridge the gap between strategy and execution by breaking down tasks into prioritised tickets ready for the next sprint.
How a development backlog is managed can impact how frequently and consistently a development team make code releases.
I’ve seen what happens when backlog management is taken seriously on a development team. For example, it can:
Reduce bugs and defects: Both business and development teams working together as a team to define tickets means when code is released meets the definition of done (DoD).
Increase efficiency and productivity: Business and development teams are happier working together in an agreed collaborative process and so items are delivered faster.
Solving problems: Teams are focused on solving business and customer problems which are part of a wider strategy (not just focused on outputs).
Happier teams: The consistent process helps bridge the communication gap and get business and development teams working together as a team.
🐙How do product teams manage a backlog?
Product teams don’t manage one backlog but in fact segment a backlog into three parts.
These three parts are:
Opportunity backlog
Product backlog
Developer backlog
Segmenting a development backlog into three parts helps to keep product and engineering teams focused and keeps the iterations engine moving.
Let’s get a better understanding of each backlog.
💡Opportunity backlog
The opportunity backlog is just a wish list of ideas and tasks from different sources.
It is the first “backlog” that all ideas go and are stored.
If you work in-house or in a fast-paced environment you’ll notice that ideas, come through thick and fast from a variety of different stakeholders, including:
Higher management
Developers
Marketers
UX and design
Customer feedback, etc.
It is from this mega list of undefined “opportunities” that teams review trends and spot what needs to be pulled into the product backlog.
You can actually see opportunity backlogs in action in SEO tool providers, for example, Sitebulb has a feature list of 195 requests where users vote on ideas…
…but I’m guessing these 195 requests are not in the development backlog.
That would be a waste of both time, resources and effort writing and managing those tickets. Also, it isn’t a simple case of writing “user stories” there will be a lot of discovery around these projects.
Instead, they create an opportunity backlog to store and hold those tasks and ideas that might be of use in the future.
🚀Product backlog
The product backlog or more accurately the product roadmap is the agreed high-value initiatives the business wants to implement to drive growth and satisfy customers.
When product teams create a strategy with prioritised initiatives (which have tasks underneath them) this will make up the product outcome-driven roadmap.
Also, product backlog can also pull tasks or ideas from an opportunity backlog that align with the business and product strategy.
However, a product backlog isn’t just about pulling tasks from a to-list.
In fact, the product backlog is used as a tool for communicating, estimating and collaborating with developers.
How do product teams do this?
They use a simple Now, Next and Later roadmap format which moves tasks and initiatives across the board.
This format allows product teams to create 3 columns in a Kanban like board which highlight:
Now: What the team is currently working on in the dev backlog.
Next: What the team is working on to be discovered ready for the dev backlog.
Later: The tasks which are less of a priority but will be worked on in the future.
This Now, Next and Later roadmap format are used by product teams to be the bridge between the opportunity backlog and the dev backlog. A process to collaborate with developers and give the team a sense of direction on what high-value tickets should be worked on next.
This format places emphasis on the order and priority of tasks that need to be completed to give development teams a sense of direction (instead of a giant list of tasks).
Instead of moving tasks up and down one column, now you can quickly move tasks from Next and Later columns based on new requirements or priority.
I also found this technique to be useful to manage the tasks in the Next column.
It highlights to the development team (and to you) which tickets need to be discovered and negotiated so they can be pulled into the development backlog.
🎫Developer backlog and bringing it together
The development backlog now is not a repository of ideas but instead is a place where tasks have been defined, understood and estimated by the development team.
It is this process that helps product and engineering teams make sure that tickets in the dev backlog are the right size for Sprints. This helps keep the agile iterations engine moving.
The process of splitting backlog management into three parts and making sure high-value items are being worked on is called Product Ownership. It is what the product owner's role is designed to do.
It is important to note that the Product Owner is a role (although it can be a job in some teams). This means that there isn’t always a project manager or product person to manage this delivery gap for SEOs.
SEO specialists (especially in-house) might need to work on this process themselves to “get things done”.
📊How can SEOs use backlog management to get things done?
Now, let’s apply what we’ve learned and how backlog management can be used in SEO.
🚧Take backlog management seriously
If you work in-house as an SEO specialist, I will always recommend you take backlog management seriously.
A company or team that doesn’t take backlog management seriously will:
Bloated dev backlogs: Tickets are just added to an ever-growing to-do list without any prioritization or value as every department submits tickets.
Increase bugs and defects: Poorly defined and misunderstood tickets mean releasing code that will not the expectation of those who created the task.
Slow down productivity: The team and business inconsistency reduce productivity as developers need to spend more time fixing bugs and defects because of poorly defined tickets.
Create unhappy teams: The chaos of throwing undefined tickets at developers can cause tension between the business stakeholders and developers, resulting in unhappy teams.
Increase risk and time to release: All of this lack of productivity and happy teams results in large, big bank releases which can increase the risk to the business.
Don’t forget shipping code releases are the “heart-beat” of any online company.
To avoid situations like this, successful product teams use backlog management techniques to ensure tasks are carefully managed and give the team a sense of direction.
🛣️Now, Next and Later Roadmap
The Now, Next and Later roadmap format can be used to manage both tasks and SEO initiatives when working directly with client development teams.
I use a Tech SEO Backlog board to manage SEO dev tickets or tasks, moving them across the board as discuss and negotiate the requirements with developers.
A tool like Notion, Trello or Asana can be used to quickly create this format and share it with development teams as part of the backlog management process.
You can also use these systems to store the Opportunity backlog (which for the client is the Later column).
It is here you can throw any ideas or feedback to improve SEO performance into a list, so you don’t forget it (and you don’t fill the dev backlog with undefined tickets).
Also, I use the Now, Next and Later format to communicate the state of the SEO initiatives to client teams and the progress/direction of projects. These initiatives are connected to tasks in the Tech SEO Backlog.
Finally, and most importantly, the Notion, Trello and Asana boards can be shared with client teams to be fully transparent about the progress of the tickets.
This means the backlog is now split into three easy to digest and accessible parts. A source of truth and a sense of direction for both developer and business stakeholders.
📏Make discovery a habit
Developers do not need to know what is at the bottom of the Opportunity backlog, but they will need to focus on the tickets in the Next column in the SEO Backlog.
The Now, Next and Later product format make this both easy to communicate to developers and helps you quickly identify exactly what you need to discuss with them.
However, just like backlog management, making a recurring weekly event to discuss the requirements of tickets and getting developers to estimate them is critical.
It doesn’t need to be a long event, in fact, agile delivery frameworks are full of time-boxed events.
So, I use this same time principle with these “events”.
I do 30-minute time-boxed meetings with developers to discuss tickets in the Next column. The tickets requirements are discussed and defined with the developer who will be implementing the changes.
The number of these events can depend on the velocity of the tickets being released but I usually aim for no more than 2-3 a week.
This means that tickets are pulled into the development backlog, rather than pushed.
🧾Format tickets for the Dev Backlog
When you create tickets in your three-part backlog make sure they are in the right are format as they move from Later > Next > Now columns.
A task added to the Later column could be very vague and undefined (just an idea for now)…
…but a task in the Next Column needs to be formatted so that it be copied and pasted (or pushed) into a developer ticketing system. It needs to meet agreed-upon criteria so developers and you understand when the ticket is done (this is called the Definition of Done (DoD)).
A very common format that product and engineering teams use is the User Story ticket.
The way a ticket is formatted can completely depend on the product and engineering team. There are hundreds of ways to write a ticket and product teams I have talked to have a different way of doing it.
I’ll write more on SEO tickets in the future because I feel like I could write an entire series on it.
🏗️Make refactoring a habit
Finally, make sure you are part of the conversations when development teams are refactoring tickets in the development backlog.
Refactoring is the process of making sure that tickets in the development backlog need to be updated or changed based on new information or recent code releases.
This is important because any changes can bother to affect the list of tasks in the dev backlog…
…and the tasks in your Product and Opportunity backlogs.
You would be surprised at how quickly a task or requirements can become out of date even a week or 2 weeks after being agreed upon (especially if you’re validating or testing your code releases).
So, make sure that you sit down with your development or product team to refactor tasks as frequently as possible.
📌Summary: Backlog management
Backlog and task management is a process that if taken seriously can be one of the best ways to collaborate with development teams.
A few simple changes to the usual to-do lists can change how you both communicate roadmaps and tasks with development teams.
The key to backlog management is:
Prioritise tickets: Always make sure your tickets and tasks are prioritised based on your strategy – remember priorities change so should the order of your tickets.
Three Backlogs: Don’t try and chuck every little SEO task into the dev backlog – instead split your tasks into Opportunity, Product and Dev backlogs to manage the “state” of tasks.
Now, Next and Later backlogs: In your product backlog don’t just have a flat list but instead give it direction using three simple columns.
Collaboration: Backlog management is nothing without teamwork, make sure you work with developers and other business stakeholders on a frequent basis.
🔗Further Reading
Why "Now, Next, Later" roadmaps are better for OKRs – A quick introduction as to why using this roadmap format helped product teams manage expectations.
Introduction to Product Ownership – A great 15-minute video on product ownership and the process of breaking down ideas and turning them into tickets that get added to dev backlogs.
Refactoring your Product Backlog – A quick introduction to how product teams refactor a development backlog.
What is an SEO product manager - I have written a detailed newsletter on the job of an SEO PM.