If you are an SEO professional, at some point in your career, you have to deal with an engineering team.
Whether it is for implementing Hreflang as part of your international SEO strategy, building your latest cool feature powered by machine learning, or simply removing a no-index tag, most of the time, you probably have no choice than to reach out to your engineering team.
In those and many other technical SEO projects you have in your roadmap, the success of your SEO campaigns is closely linked to how strong is the synergy with your developers.
In this post, I’m going to show you why user stories are the most important tool you have to make the communication between your SEO team and engineers smoother, and how they can help you save a ton of time (and release disasters).
What is a User Story?
Before walking you through why you should care about writing compelling user stories, let’s define what user stories actually are.
A user story is a tool used in Agile frameworks like Scrum and Kanban to provide a simple and informal description of a feature, primarily written from a user perspective. I say primarily because, in the context of SEO, our end-user is not exclusively site visitors but also search engines who crawl your pages and make them visible to the user through the indexing process.
User stories are generally written by product managers (or Product Owners in Scrum) as part of their product backlog. They are then added into a cycle of development slots called ‘sprints’ and completed over the duration of usually 1 to 4 weeks (most commonly 2).
I should also mention that, in theory, user stories are not the only way to describe a feature. There are many alternatives to user stories such as initiatives, job stories, problem stories, improvement stories, and feature-driven development features (if you are interested in understanding more about any of those, here‘s a great article about this topic).
Nonetheless, for SEOs, user stories are the most effective solution at communicating exactly what requirements are needed to build a certain SEO feature, because they include all the information in a simple and compact format.
Traditionally, user stories are supposed to be written on sticky notes or index cards, then stored in a box and finally arranged on walls to facilitate planning and discussion around those. This is because what’s important is the actual discussion about the requirements more than whatever is written on the notes.
However, this same process in large enterprises is nowadays scaled with the use of issue and project-tracking software which, among other uses, help to keep track of all the stories on a unique digital platform. In my experience, the most commonly used in big enterprises is Jira by Atlassian but there are certainly many alternatives in the market.
Why do User Stories matter to SEO
Although we’ve just mentioned that user stories for SEO are usually written by product owners, in the case of SEO features, it is often the case that is practically SEO managers who end up writing those stories. For this reason, it’s really important to be introduced to the concept of user stories and be ready when those are required to be written in order to progress backlogs in Agile teams.
But this is not the only reason why user stories matter for SEO professionals. Whether the development resources in your company are shared among multiple teams or you have been assigned a dedicated SEO engineering team, user stories are the most efficient way to help bridging communication gaps with your devs.
By looking at user stories, the engineering team is in fact able to know exactly:
– who the actual end-user is
– what the end-user will use the feature for
– the final goal of the end-user via the use of that feature
– what the requirements to build that feature are
– what the definition of ‘done’ is in relation to that user story
– how to test that feature to satisfy the intent of the requirement
What’s the typical structure of a User Story
During the past decade, many contributors to Agile software development frameworks have applied different approaches to user story writing. If you want to get deeper into the history of user stories, I suggest you have a look at this article which explains in detail the origins of user stories and who have been the major contributors to their popularity.
In this paragraph, instead, I’m only going to talk about the format most commonly used in Agile SEO, especially in relation to teams who use Scrum frameworks. So, let’s get started.
At its most quintessential level, user stories follow a simple template:
As a < end-user type >
I want (or need or can) < achieve a goal >
so that < some reason >.
To add more detail to this short sentence, which is often defined as ‘value statement’, user stories can be expanded with the addition of attachments, user flows, prototypes, additional resources, and, above all, ‘acceptance criteria’ (AC). The latter are also often referred as to ‘condition of acceptance’ (CO) or ‘condition of satisfaction’ (CS).
Those are probably one of the most important parts of a user story, as they:
– initiate (and often facilitate) the discussion with your engineering team
– draw the boundaries on which that feature should be built on
– define when a story can be considered completed and when the story is working as intended
– delineate the testing and QA process
User Stories vs Epics
In my experience, something that often creates confusion is the difference between user stories and epics.
Epics are top-level features that need to be broken down into smaller units (stories) as they can’t be completed in a development cycle or sprint.
To put it simply, you can think of an epic as a big functionality (parent) from which smaller stories will need to be created (children) in order to complete it.
To give you a common example in the context of SEO, an epic might be improving your site speed and the user stories might be tactics such as minifying JS and CSS, enabling GZIP compression, deferring third-party JS resources, and so on.
I have my user story and acceptance criteria. Now what?
Now that we’ve clarified what user stories are, why they matter to SEO and how they differ from epics, let’s dive into the process you might usually go through after you’ve got your user stories ready.
Once you, as the SEO Product Owner are happy with the value statement and the acceptance criteria that you’ve just delineated, we get to that fundamental stage that we’ve previously mentioned in this post: the discussion.
This is when your user stories will need to be carefully reviewed and discussed with both a Developer or Technical Product Owner (TPO) and a Tester. This discussion in Agile is called ‘3 Amigos’ session (I know, funny name, right? I promise that it is how it’s called!)
Although it’s referred to as the 3 amigos session, this discussion group can actually be extended to other members of the team such as a designer and/or a producer, based on the nature of the feature. Sometimes even other stakeholders might need to be included if necessary.
In this session, the TPO and the Tester challenge the acceptance criteria and anticipates what questions might be asked by the engineering team in relation to development, QA, and testing. If you can answer those questions, you are halfway through the process and you can make sure you have tackled the most common questions beforehand.
Once the 3 (or more) Amigos agree on the AC, the user story can be brought into the backlog grooming session, which is another important stage of the Agile process.
This is where you and other product owners from different teams discuss your user stories with the engineering team to have a chance to get them included in the next sprint. Unless you have your own SEO engineering resources, of course: in that case, you might go through a different process.
Generally speaking, the grooming session is when engineers ask you as many questions as they need to estimate the effort required to complete the story. So you better have done your homework with your TPO and tester beforehand, otherwise, your user story might be rejected and sent back for additional review. Or, even worse, devs might take it into a sprint and release the feature with bugs, which I can ensure, it’s not that pleasant. In all those instances, you might experience delays in your SEO roadmap and, believe me, you don’t want that to be happening!
If you want to prevent that, have a look at this article I have written about the 5 things you need to take into consideration when writing user stories. This will hopefully save you a lot of time and disasters after the sprint release.
Conclusion
We have clarified what a user story is, what elements make up a user story and why it matters to SEO, so let’s make the most out of this amazing tool we have to communicate correctly with the dev team. And don’t forget to let me know in the comments what your experiences are with user stories!
