Does it ever feel like your SEO recommendations and projects get lost in the shuffle or deprioritized by other teams?
If you work in-house, you’ve likely experienced the “fear of missing out” (FOMO) when it comes to getting your optimization work properly resourced and implemented.
The good news is that a project management methodology called “Agile” can help cross-functional teams self-organize and collaborate more effectively.
By understanding the agile ceremonies (meetings) and processes, you can better integrate with and influence the development cycles to ensure your SEO requirements don’t get overlooked.
In this article, we’ll cover the key aspects of the agile methodology, map out the various agile meetings you should aim to participate in and provide tips on how to write effective tickets and acceptance criteria so your SEO changes get prioritized and launched.
Say goodbye to FOMO and start getting your SEO work done through the power of agile processes.
How agile project management stops FOMO
An agile approach makes you part of the process with the teams that get things done.
AI may be trending, but I believe the agile framework is enduring. Unlike AI, which depends on artificial or software intelligence, agile relies on how teams naturally organize to accomplish tasks.
It prioritizes tangible features and improvements. Increasingly, major technology teams are embracing agile for its ability to enhance business value and efficiency in managing complex projects.
A quick overview of the agile methodology
Agile project management is a method of managing your project work in small, incremental segments that can be easily assigned, easily managed and completed within a short period of time called an iteration or sprint.
Traditionally, project management followed a waterfall-style approach. In this method, all the work is completed upfront and customer feedback is gathered afterward.
The process can take months to complete, which is not always ideal, especially when you want to release a product MVP to the market ahead of your competitor. (Sound familiar?)
The agile style is more iterative because work is designed to be completed in short cycles (sprints), where feedback and improvements (to both the product itself and the teams involved) are built into the process.
Agile has its roots in the software development world. The key elements are:
- Plan
- Deliver
- Learn
For context, this is the manifesto for agile software development:
Agile is founded on 12 principles:
My favorite ones are:
- Business people and developers must work together daily throughout the project.
- Continuous attention to technical excellence and good design enhances agility.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
See that? When teams use agile, everyone along the way becomes part of the team that works on the actual work. Together, everyone accomplishes big things.
Agile principles are inherently about collaboration and continuous improvement. Any organization can use this approach to lean thinking and operating to deliver value to their customers.
In previous articles, I’ve referenced the agile methodology and how it’s executed using a scrum framework.
A scrum-based process is great for handling big or intricate solutions because it’s iterative and allows quick market entry. It enables teams to learn from customer feedback and incorporate on-the-go improvements.
On the other hand, Kanban and waterfall methodologies usually take a more linear approach.
A core agile team typically consists of:
- A product manager.
- A project/program manager.
- Leads from supporting teams like engineering, user experience, QA and SMEs like SEO.
Within this structure, daily and weekly ceremonies (or meetings) help everyone align on the work and move things forward.
The work is designed to be completed in a time-boxed sprint, usually 1-2 weeks. All tickets in a given sprint should be finished in that time for the team to achieve their desired velocity.
Dig deeper: SEO product management: Key framework and fundamentals
It’s a continuous cycle. Incremental improvements are thus achieved using what’s called an Agile Release Train.
For ecommerce sites, these teams improve aspects like product detail pages, the on-site search functionality or the checkout process.
Get the daily newsletter search marketers rely on.
How to integrate with an agile team
Conceptually, this is about understanding the workflow of cross-functional teams using agile. Now, fellow SEO professional Aleyda Solis wrote:
In addition to knowing the sprint duration, understanding when and where to join key meetings is crucial. Business stakeholders participate at different points in the sprint. As such, grasping the broader agile scrum process will provide even more context.
Not taking the time to learn and familiarize yourself with the meeting rituals of teams using agile scrum can perpetuate the feeling of chaos. You don’t know where to be, what to do or how to get other teams to help you get work done.
The key is to spot the pattern.
I’ll guide you in recognizing this pattern so you can figure out who to collaborate with, when meetings happen and what you need to prepare.
Let’s begin with the individuals involved in the agile process.
Find the conductors
First, find the product manager.
If you’re a business stakeholder, you are largely outside of this daily process. This person is your touchpoint to helping you navigate the agile team’s meeting cadence and can advise you on where and how to submit a ticket.
Business owners are primarily brought in at the beginning (to define “the ask” to the team) and at the end (to validate the output).
The second person to find is the release train engineer (basically the lead engineer).
This person facilitates the agile release train execution, managing risks and dependencies along the way. This person will largely be able to guide the technical nuances of how your request gets implemented so that it can be successfully launched.
Tangentially, you’d do well also to identify the project manager. (This role can have different names from scrum master to delivery manager.)
Functionally, they support the product manager in terms of organizing the team’s current sprint and backlog (the lineup of tickets to be worked on) and they typically report to the broader organization as to the ongoing status of the work.
Once you identify these roles in your organization, they can help direct you to the various meetings to attend.
Agile project management ceremonies (meetings)
The second step is knowing what meetings to attend and how you help move the team forward.
In this section, I’ll map out where you as a business stakeholder need to plan to be, the meeting types, when they occur and who will be there. As an SEO product manager, I operate as both a partner in terms of being a subject matter expert and a business stakeholder.
Participating in these meetings that support the agile project management methodology helps me be in the know while partnering with cross-functional teams to get work done.
Since agile allows for teams to self-organize, below is an overview of general meeting terms and types one would see as part of this process.
Stand-up
This is often daily or every other day in a given week. These are typically 15-minute meetings where the agenda is a roundtable of team updates and/or any areas where they’re blocked with their work.
Business stakeholders don’t typically attend stand-ups but it can be helpful to attend a few, especially if it’s been brought to your attention that the team has questions about a ticket they’re working on for your team.
As a business stakeholder, the daily stand-ups are what you want to get invited to. It’s a forum to hear what everyone is working on, where they’re blocked, or if they have questions related to your ticket(s) you can help answer.
Note that standups are not the place to introduce new work. An appropriate time for that is sprint planning.
Grooming
This is typically an hour-long, bi-weekly or weekly meeting, depending upon the sprint cadence. This is where the product manager and project manager talk with the teams (engineering, design/user experience, etc.) about the work and the level of effort involved with each ticket before adding it into a sprint.
Once there’s a sense of the size and scope of each ticket, it gets added to the sprint.
This is a key meeting for business stakeholders to attend because they pitch their ticket to the team working on it, answer questions and provide any additional context like priority or severity. It’s important to come prepared, be brief, helpful and thorough.
In preparation for grooming, create your ticket by identifying the type of ticket you’re bringing to the team. In most cases, it’s either an issue or an enhancement and can be classified as the following:
- A bug (i.e., something that worked once but doesn’t work now).
- A new feature or functionality.
- A regression (i.e., a previous functionality is no longer working as expected).
I cover this in more detail in terms of how SEO teams can write an effective ticket, which you can use as a guide to adapt to integrate your own team’s specifications.
Tip: Use quantitative metrics in your acceptance criteria and provide the source for where the work is to be viewed and approved as complete. (For SEO, it’s often the source code. For other teams, it can be “customer experience will be X”)
As a business owner, when your request and pitch are crystal clear in your ticket, you’re more likely to get work done.
Refinement
These can be hour-long meetings and happen as needed because they can apply to the set of current tickets for a sprint or the tickets in the backlog.
Ongoing refinement meetings aim to bring the team together to align on requirements, adjust ticket level of effort (LOE), QA input, etc.
We all know technology changes quickly. This part of the agile process helps teams plan requirements and adapt based on existing market conditions.
Sprint planning
This is where the team plans the work that will be included in the upcoming sprint. Each sprint is usually time-boxed for 1-2 weeks, during which all tickets (slated work) are completed.
Effective sprint planning results in the entire team scoping the level of effort of each ticket and completing it in the sprint. Ideally, their KPI output of velocity trends up and to the right.
Being present during the sprint planning meeting will help you get a view of what the team will be working on and delivering in the short term.
Having that predictability factor of planned work allows the team to focus on chipping away at either tech debt or growth-related initiatives. Offering a nice balance of an offensive and defensive strategy towards holistic improvement.
Backlog refinement
This meeting can occur as needed when the team needs to organize and/or prioritize the backlog of tickets they have queued up. Typically, this meeting involves the product manager, project manager and an engineering lead.
A big part of the agile scrum methodology is always having a “healthy, groomed” backlog of work for teammates to pick up as capacity allows.
While business stakeholders don’t usually attend this meeting, it can be helpful to ask the project manager about the team backlog to better understand where there are needs or opportunities for the team to take on more work or large projects that can be broken down.
The operative words here are “broken down.” In agile, big projects are always broken down into individual tickets.
Demo/showcase
Occurs when the feature is functional and ready to demonstrate to stakeholders before going into production or a live environment.
The project manager schedules it when the engineering team is ready to share and showcase their progress to a wider audience. Stakeholder attendance is key here as this is a touchpoint where the team validates what is built meets expectations.
As mentioned above, if you did a thorough job of including quantifiable Acceptance Criteria in your ticket, by this point in the development process, it’ll be easy to confirm the ticket is done.
Retrospective (retro)
This meeting is organized by the project manager and occurs after the sprint is completed. Here, the entire team comes together to talk about what went well/what didn’t in the recent sprint and how they can improve for the future.
External stakeholders need to participate in this meeting, especially when their work was part of the sprint, because it’s a time to build camaraderie and help everyone improve.
A great way to do this is to come prepared with 1-2 tickets as examples and the tangible good or bad things that took place. Stick to the facts and highlight how things can be improved. Your feedback should come from a place of collective growth and improvement operating as a team.
The big takeaways here are: when you’re coming to an agile team with an ask for their time and effort, stakeholders should provide clear, concise information in the ticket regarding “what” is needed (not “how,” that’s for the agile team to determine). Be succinct in your replies to help the team decide so they can move forward in architecting a solution.
The FOMO is subsiding, yes? Because you’re becoming part of the solution.
No. More. Fear.
How can I get asked to work with the agile team again?
It’s kind of addictive, you know? Getting things done.
Once you get something implemented, you want more. The FOMO starts actually to subside because you’re collaborating.
You have all the calendar invites of the team’s meeting cadence. You know your POCs that facilitate interlocks and communication and when your ticket is ready to be reviewed and signed off on.
If you play your cards right, you might even get invited to their internal Slack channel!
The best way to ensure you get to work with these teams again is to help the team complete the work they’ve collectively committed to completing in the time-boxed sprint (alliteration is fun). You do this by being engaged and prepared.
How to not let your requirements get missed
Write this down: Make them quantifiable!
At the outset, define the ask in simple terms: here are some examples of effective (and ineffective) tickets and the user story prompt to help you crystalize the issue and the ask.
Again, to quote Solis:
Yes! And you do this by defining clear and quantifiable acceptance criteria (AC) in your ticket.
As a business owner, you can provide the AC to stipulate your expectation of how something functions and/or the desired customer experience.
The more quantifiable you can make it, the easier it is to validate and give the team the thumbs up that the work is done.
A quantifiable output is preferable to a qualitative one because the latter is subjective, and you may not get exactly what you’re looking for.
For example, as an SEO product manager, one of my frequent SEO-related ACs for links is that they are formatted as:
- The <a href> must be in view:source.
- The <a href> must be without parameters.
That criterion is an easy yes/no response when you see that in the code. It’s either there, in that format, or it’s not. Pass/fail QA.
So, the takeaway is to include quantifiable AC in the ticket. This will allow you to align with the team on the DoD (definition of done) and easily spot-check and verify its completion.
How do I know if my organization is using agile?
Literally, ask. Find someone with the title of product manager and ask them, “Hey, quick question: Are we using the agile method for project management? If so, can I get invited to the daily stand-up meetings to get up to speed with what the team has planned in the current sprint?”
When you get that invite. Show up on time (literally, because these meetings are short). Listen. Take notes. The more you attend the team’s ceremonial meetings, the more it will sink in.
That’s how you get things done
You now have the best-kept secret of how to get things done. I know this is a lot. It might be new or foreign to you. And it’s all in addition to your day-to-day goings on. But finding these teams is worth it. Plugging into the agile process is how you get things done with broader teams.
If you don’t believe me that this works, just continue operating as you have. Don’t engage; just watch as all your tickets get relegated to some team’s backlog. However, if you want to get big projects launched and create change, try it. Implement what I’ve outlined here, take ownership and operate this way. I promise you’ll get results. Agile is designed for output.
As an in-house SEO product manager, I can say firsthand that learning about and operating within the agile framework (and doing so at different companies) has taken a few years to acclimate to. And if I’m being honest, I’m still learning. But, like anything, the more you do it and engage and communicate with your teammates, the easier it gets.
Contributing authors are invited to create content for Search Engine Land and are chosen for their expertise and contribution to the search community. Our contributors work under the oversight of the editorial staff and contributions are checked for quality and relevance to our readers. The opinions they express are their own.
