Bloated Backlogs, Clear Docs, Brainless Scrum
Edition #19- Monday 3-2-1
Hello 👋,
Welcome to the Monday morning ideas newsletter ☕️.
Every Monday morning, receive 3 ideas on how to work more effectively in product and dev teams.
To receive articles like this, please subscribe to The SEO Sprint 👇.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
#1 - How Bloated Backlogs Impact on SEO
Do you find your SEO recommendations are rejected by the dev and product team? Even when you get buy-in from management?
The problem might be a bloated backlog.
When you submit a ticket to a development team, it's added to a dev backlog (a very long to-do list for developers). The dev team usually uses a ticketing system such as Jira, Asana or Azure DevOps.
The thing is, someone needs to manage this backlog. Usually, it is the Product Owner or Product Manager.
At Lumar (DeepCrawl), it was my responsibility to manage the development backlog. Every week. I booked time in my calendar to do the following activities:
🔧 Updating tasks - Review and update the requirements in the tickets.
🔨 Reducing task complexity - Split tasks into smaller to-do items.
🚦 Prioritising items - Changing the priority of tickets based on the roadmap.
💥 Deleting items - Delete redundant tasks within the to-do list.
This collection of activities is called backlog management.
Backlog management has one goal. Breaking down tickets into smaller releasable to-do items and getting them ready for developers to work on them. But there is a common problem with dev backlogs.
The problem is they can become 📢 BLOATED 📢.
Why does this happen?
Well, different business teams want to “add” their own requests to the backlog. The team’s requests are added in the form of tickets (bug, user story or Epic) to a ticketing system. Over time this list of to-dos gets longer and longer. Before you know it, the team needs to manage hundreds of tickets.
This phenomenon is called a bloated backlog.
The more tickets there are in the backlog, the more time is needed to sort them out. It means backlog management takes even longer. Taking away focus and time from talking about current planned releases.
OK, but why should an SEO care about a bloated backlog?
The more complex your dev team's backlog, the harder you need to work to get SEO tickets prioritised. You’ll be fighting in a mosh pit of requests 🤘.
Even when you add tickets to the backlog, you’ll need to be present in planning meetings to make sure other requests stay prioritised.
I’ve seen devs deprioritised tickets. Just because they were unsure of the contents or priority of the ticket. After a few meetings, those tickets get pushed and pushed further from the top of the dev backlog.
The lower the backlog a ticket is, the less likely it is to be implemented.
How can SEOs get things done when a dev team has a bloated backlog?
Any development and product team with a bloated backlog are going to have their shields up. They’ll reject a lot of requests, including SEO recommendations.
This means you need to be more strategic in how you submit your SEO requests.
If you’re finding yourself in this situation, then I recommend:
🚦 Ruthlessly prioritise SEO tasks - Always make sure you are constantly prioritising your SEO requests and you are giving the team high-impact requests (you’ll need to have a compelling WHY? ).
👣 Dual track backlogs - Rather than keeping tasks in a Google sheet, try to get your SEO tickets ready by using a Trello or Asana Kanban board before moving them to Jira.
📅 Join Planning Meetings - Join meetings that decide the fate of your SEO tickets and make sure you focus on attending the right meetings (hint: stand-ups are the wrong place to talk about future tickets).
I want you to bookmark and read the following newsletter for further ideas and details:
#2 - Why Clear Documentation Matters
In 2022 I interviewed 15 in-house SEOs. They all worked with product and dev teams to get things done.
One of the key lessons that stood is was that they all understood the importance of technical briefs.
A product brief helps devs and designers better understand the what and why behind the idea. Then they can help to come up with the how. A solution to help solve the problem and meet the brief.
From the conversations, three key elements stood out when creating technical briefs:
📈 Outlined the opportunity: Explain why the requested feature is important. For example, ROI analysis, forecast model or user experience data.
⚙️ Technical requirements: A specification that outlines the success criteria that devs must meet. For example, building out page templates, internal linking modules, etc.
🖌️ Examples: A website design or gathered examples of what the output should look like. For example, schema.org markup JSON-LTD code, etc.
I’ve spent years creating product briefs and technical requirement documentation. Also known as a product requirement document (PRD). It’s a key first step in getting developer and designer feedback on a project.
In my experience, these product briefs are a living document. In organisations I’ve worked in, they worked on by the product manager, developer and designer. With input from relevant specialists who are key to the project.
Any technical brief is a living document. Moulded by input from the team until it is polished. That is the true power of any product brief or PRD. It sparks conversation and thinking through a problem. In fact, now I always share a rough draft with a developer and designer I trust to get feedback ASAP.
It never fails to help prioritise the requirements or polish the idea.
In other words, technical briefs helped build a shared understanding between SEOs and dev teams. Not by themselves. But by allowing teammates to follow up and share thoughts in a living document. The SEO then takes away and improves on the idea (or, in some cases, kills an idea).
OK, wonderful, so how do I use this to work better with dev and product teams?
Writing product briefs and PRDs requires work. And practice. Lots of practice.
I’d recommend two resources to get you started:
📖 Read Specification by Example and SEO and try out the simple method
🎙️ Listen to Gus Pelogia and Abby Gleason talk about using PRDs
#3 - Scrum is a Brainless Process
I’ve been part of hundreds of meetings using the Scrum framework. And one thing I know for sure is that the Scrum framework does not have a brain.
What does that mean? Well, the official Scrum Guide says it best:
“Scrum is built upon by the collective intelligence of the people using it” The Scrum Guide
In other words: The Scrum framework is only as smart as the team that uses it.
Scrum is a framework made up of roles, ceremonies and artifacts which can help teams break down complex ideas.
But that’s it.
Why does this matter?
Well, Scrum still requires the team to create a product backlog, goals and a clear strategy to actually drive value. Otherwise, that systematic process will create a lot of motion but not a lot of progress.
As an SEO it’s critical to create a strategy and set clear goals before working with teams using the Scrum framework.
If you don’t create a clear strategy, roadmap or goals you’ll end up wondering why “doing agile” isn’t working.
Alright but how can I use this to work better with devs and product teams?
When you’re working in any team that uses Scrum I want you to do the following to make sure the process has a brain:
🥅 Goals - Set clear SEO goals using input and output metrics that can be used to track success.
🚦 Prioritise - Always prioritise initiatives so the team knows what they are working on next.
🌀 Strategy - Make sure you outline a clear strategy and roadmap to achieve your goals.
You can find more information in the following The SEO Strategy Stack newsletter 👇
How did I do this week?
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.