Dual Track Development, Bug Triage, Definition of Done
Edition #24 - Monday Ideas
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) Dual Track Development
There are two different tracks of work when executing projects:
⚒️ Development work: Focuses on executing predictable and quality projects.
🌀 Discovery work: Focuses on learning and validating ideas.
Although they are separate tracks of work, they are constantly feeding each other.
At DeepCrawl, we used dual-track development on a weekly basis to validate ideas. Then turned the idea into dev tickets. We validated ideas using user testing, customer interviews and surveys.
Discovery is all about thinking through, changing and killing ideas.
After release, we’d identify more ideas from building it or customer feedback. And the cycle would repeat. It was all about being agile and responding to customer feedback.
For big bets on the roadmap, we’d validate and test the opportunity a quarter before it needed to be built. While building the feature, we validated and tested it the quarter before.
It’s a constant dance of validating → planning → delivering.
Why is this important to getting SEO projects executed?
Your SEO actions will never get prioritised if the product team follows this way of working.
Product culture revolves around validating ideas before implementation. Dual-track development is how these teams action impactful work for the business. And decide which ideas get allocated resources and time.
As an SEO working in these teams, you’ll have to start playing the same game.
How can SEOs use dual-track development?
The default setting for many SEOs is to send an action list to the dev team. With no clear evidence about why the dev team should spend their valuable time on these actions.
Remember, companies never have enough dev resources.
SEOs need to play a different game. They need to by default provide a small prioritised list of actions that can be backed up by clear evidence. For example, evidence can be gathered by:
💥 Past Releases: Past releases or experiments that show positive results.
💽 Third-party data: Case studies from the web to support your hypothesis.
🗣️ Customer feedback: User testing that highlights there is a problem.
Validating ideas and providing evidence can help get SEO actions moved into the development track.
I’ve been using this way of working since I left DeepCrawl. Both as an SEO and Product Manager. It can help to get projects prioritised and executed by following a simple process:
✅ Validate: Provide evidence that SEO actions are worth implementing.
🗓️ Plan: Create and refine a product brief with clear specifications.
🚚 Delivery: Turn the specs into dev tickets that can be added to the backlog.
2) Why an SEO bug triage process matters
Bugs can make or break a company's SEO performance.
We’ve all been there. The devs push changes to the website that remove or break something that was already live on the website. This might include:
Pushing the staging robots.txt to the live website
Removing Hreflang tags from the product pages
Adding a noindex tag from staging to the homepage
Changing canonical tag URLs to staging URLs
Adding “window licker” to a job description (actually happened).
I’ve seen it all.
SEO teams use a combination of different web crawling and third-party tools to monitor for these bugs. We call it SEO quality assurance (QA) testing.
SEO QA testing is the process of identifying any errors on a website before or after launch. It’s critical that this practice is in place because the further out you go from that go-live date. The harder it becomes to fix any errors that occur.
Even with the right SEO QA tools in place. It won’t be enough.
Why?
Because the dev team need to prioritise fixing bug requests. A product and dev team is going to get bombarded with requests. It’s their job to filter out the noise. Especially SEO bugs detected by contextless third-party tools.
This is where the SEO needs to be part of the bug triage process.
A bug triage process is simple. Every week the product and dev team:
📅 Attend a meeting: The team attends a scheduled meeting to discuss bugs
🐞 Raise bugs: The team raises, discusses and accepts bugs.
🚦 Prioritise bugs: The team decides what bugs to fix in the next release.
I’ve been the product manager and the SEO professional in these meetings. Raising bugs and helping the team decide the order they should be fixed.
The trick to getting priority bugs or errors fixed is focusing on three key factors:
🤖 Requirement: Outline the steps to recreate the bug/what you expect to see.
🚦 Prioritisation: Help decide what should be fixed in the next release.
🤷 Why: Be clear about why the team needs to work on fixing each bug.
These three factors help product and dev teams fix bugs that drive business results.
How can you combine the bug triage process with SEO QA testing?
It isn’t enough to just schedule crawls and set up alerts on company websites.
You need to get into the habit of speaking to devs on a regular basis. There are a couple of ways I’ve found you can do this:
⏰ Schedule bug triage: Make it a routine to discuss SEO bugs with devs.
📅 Attend bug triage: Join the scheduled meetings to raise SEO bugs.
SEO errors aren’t going to be prioritised straight away. So you need to show up, time after time. And get ready to fight to get those bugs implemented.
A trick I use is to categorise the bugs into different levels of priority to build a common language:
P1 - Highest priority and must be fixed immediately.
P2 - High priority and must be fixed soon.
P3 - Medium priority and should be fixed.
P4 - Low priority and can be fixed later.
The P levels indicate what needs to be fixed ASAP vs. what can be fixed in the next few releases.
For example, a level P1 is RED ALERT.
If you raise a P1 bug, then they understand it needs fixing immediately. Otherwise, business performance is going to be impacted. Fast.
The trick is not to make every high-priority issue a P1. If everything is a priority then nothing becomes a priority.
Finally, keep a list of bugs that don’t get added to the dev backlog. Every company has a bug database. In a spreadsheet, written in a document or stored in the dev’s head.
3) Use Definition of Done (DoD) to Avoid Rework
Picture this.
You’ve managed to get a ticket worked on by the development team. Before you know it you’re told the ticket has been marked as “done”. And has been pushed to production (the live website).
You quickly check the public website. Your heart drops. The developers haven’t implemented the request correctly. The criteria in the ticket have not been met.
Sighing deeply you wonder if there is a way to avoid this.
Sound familiar?
Yeah me too. I’ve been there. This happens a lot in product and dev teams.
One technique that I’ve picked up from working in product and engineering teams is practice agreeing with the team on a Definition of Done (DoD).
The DoD is a list of criteria that is agreed on by a team that must be met before an increment (dev ticket) can be considered “done”.
For example, an SEO dev ticket can only be marked as done when the following have been completed:
Code reviewed
Unit tests passed
Acceptance criteria met
The designer reviews the user story
The Product Manager/Owner accepts the user story
Think of it as a “done checklist”, that sets expectations as part of the team’s release process.
Why is a DoD useful for getting SEO projects executed?
A DoD helps the team understand when a ticket is being worked on and can be marked as done. It means teams agree that the person who submitted the ticket (the SEO) needs to be the one who accepts the ticket.
This stops devs from marking tickets as “done” and pushing defects to production. The more defects are set live, the more teams need to stop and fix what they’ve already done.
This slows down the delivery process. As devs spend more time fixing, than building new stuff.
How can SEOs use DoD to get projects executed?
Speak to your development and product team. Book a meeting or call and ask them the following question:
Do they have a definition of done checklist for each ticket release?
If they do that’s great! You need to ask if you add an extra check to the list:
SEO professional accepts SEO dev tickets
Remember, this isn’t meant to be an all-singing and dancing checklist. You are making sure the team know that you need to accept any SEO tickets for them to be marked as “done”.
If the team do not have a DoD process in place. This can be trickier but doable.
You just need to ask that for any SEO tickets being worked, agree up front that they need to notify you when they have done a ticket. So you can check the ticket and give it the green light.
A couple of ways of doing this in practice (because they will forget and you will get upset):
✍️ Write DoD in the ticket: Add a small paragraph at the top of the acceptance criteria that the ticket needs to be reviewed by [NAME] and your email is X (so they can message you).
📩 Assign you the ticket: Most ticketing systems allow people to assign tickets to each other, so you need to ask the devs to assign you the ticket when ready to be reviewed.
🗣️ Add comments: Most ticketing systems have a comment section within each ticket and this allows developers to @ you when a ticket is ready to be reviewed.
However, be warned. Devs and product managers don’t like to be kept waiting. Especially, if they work in sprints. If you agree to this process you need to get ready to test and review tickets.
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.