At Heady, we have managed dozens of products and hundreds of releases, creating value both for users and for our clients. It is not easy to coordinate these efforts, but diligence and clear communication allow us to deliver timely and valuable software consistently. One of our key tactics is robust ticket writing.
How does thoughtful and strategic ticket writing help our team at Heady stay on top of fast-moving projects? Let’s get into it.
It is easy to find articles about strategic product management skills, how to define product roadmaps,how to set your north star, storytelling, etc. Setting the strategic direction of a product is about 10% of the job; 90% of the job is delivering on that strategy. To effectively deliver on that strategy, you need to coordinate a product team by giving a clear direction.
To keep our projects moving at the speed of our clients and users, a Heady Product Manager must master the foundational skills of effective ticket writing, because it is the smallest unit of what a Product Manager needs to ultimately scale.
Let’s strip away the notion that ticket writing is filling out a template, and take a deep dive into the difference between a mediocre ticket and a rockstar ticket. By internalizing essential rules, you will be able to lean into your strengths as Product Manager. You can break the rules, once you master them.
So let’s start mastering ticket writing.
The first step is understanding what makes an effective ticket or user story. At Heady, we use agile INVEST principles.
In an ideal world, agile tickets should be:
With these principles in mind, let’s see how they translate into a new signup feature for our fictitious product.
The best way to cover the INVEST principles is actually a bit out of order so that each one can build on the one before. I will be starting with V=VALUE.
To begin, let’s look at the basic user story outline.
As a <user>
I want to <function/unit of work>
So that <value>
This simple outline states the user value (V from our INVEST principles). Of course, there is more to the job than filling out the user value template
It is important to distinguish between what we expect the user to do and what the user actually wants to do. It sounds simple but this is where Product Managers oftentimes miss the mark.
An easy example is:
As a user, I want to sign up so that I can log in.
This difference may seem insignificant, but it becomes significant when prioritizing stories with multiple stakeholders. By being specific and clear about feature value, we will guide stakeholders more effectively and prioritize faster. Efficiency gained.
But we can do better…
It is easy to default to the generic “user,” however, most products do have different target audiences and personas. And our user story will be stronger if it focuses on a specific type of user, rather than a generic one. Again, this may not seem like much, but these tweaks can help save time and hone in on the most valuable stories and features.
So let's drill down a little further and see if we can be more specific.
As a repeat shopper, I want to sign up so that I can make my purchase more quickly
We have now clarified that we are creating value for a repeat shopper, the kind of user for whom a business definitely wants to provide a great experience.
Product managers are asked to add business value by adding product value. If we are able to add value with every single prioritized user story, then product value becomes inherent in our process—and business ROI will always be positive. Our clients will be happy, our users will be happy, and the product will grow.
When identifying the user in a user story, it is important to…
When identifying the value of a unit of work in a user story, it is important to…
Next on our INVEST principles journey is S=SMALL.
What does small really mean? Companies may have different definitions of small, so I will give you Heady’s definition.
We consider small as something that can be completed within a two-week sprint. Anything that will take longer than two weeks will most likely have unknowns and be broken into additional steps. This is not a hard-fast rule, but a helpful guideline for keeping tickets manageable and not taking on too much at once.
We can also test small with Acceptance Criteria (more detail on this later) and should ideally keep the ticket’s Acceptance Criteria below 8. We can break this rule in some cases, but 8 is a good, quick litmus test.
Let’s return to our example from the user value post, and build on it:
As a repeat shopper, I want to sign up so that I can make my purchase more quickly
Everyone reading this has experienced many different signup flows, including here on Medium. Signup flows vary. Therefore, it is hard to say definitively whether this user story is small. As with most things in life, it depends.
Extra Credit: As a Product Manager, you should have some basic understanding of how data flows. More often than not it is via APIs . However, if you are just starting out, look at a design, and think about the user action at each stage. Discuss assumptions with your engineer team until you get more comfortable with the lingo.
So let’s look at two different signup screens:
Even someone with minimal tech knowledge can easily see one screen requires many more inputs than the other.
The right screen is probably small enough to be one user story. The left screen, on the other hand, probably needs to be broken up into multiple user stories to keep the tasks small and manageable. Examples of additional user stories we may create for the left signup screen are:
As a shopper, I want to add my address so that check out faster
As a shopper, I want to add my credit card information so that I can check out faster
As a shopper, I want to include preferences so that I can get product recommendations
Keeping user stories small is helpful to product development in many ways. Small user stories make it easier to track your team's work, avoid additional back and forth because of multiple unknowns, and address delays (if any) more quickly.
Next in INVEST is I = Independent and N=Negotiable.
Keeping tickets small makes them more manageable. Manageable tickets are also independent, meaning they can be worked and shipped independently of any other ticket.
Why? If tickets are small in scope but they have multiple dependencies, then they’ll suffer from the same downsides as big tickets: blocked engineers, increased back and forth, and decreased visibility to what is completed and can be shipped.
Always creating tickets that are both small and independent may seem unrealistic. But when engineers are challenged to break out the work into small, independent tasks, they tend to find implementation solutions that work for everyone. Once everyone on the team is aware that all tickets need to be independent, a joint effort can help flag if there are dependencies and the team can work to uncouple where possible.
I decided to group I=Independent and N=Negotiable together because both rely on getting signoff and feedback from your engineers.
Because they allow for input from team members with different perspectives, tickets that are negotiable tend to lead to better outcomes. That said, there are some best practices to follow in collaborating with engineers.
It is important to remember that engineering can be both subjective and creative. There can be multiple ways to approach a problem and some engineers default to either how they have done it in the past or challenging themselves with something completely new. In both cases, it can be valuable to facilitate a ”pros and cons” conversation about different implementations.
For example, implementing signups with one framework may lead to a speedier delivery, but the maintenance of that code may be more time-consuming in the long term.
Encouraging engineers to get a second opinion will help surface tradeoffs that may not be clear from the outset. However, a Product Manager should be pragmatic with his or her time. Trying to spark a conversation for every single ticket is not feasible for most; it’s best to focus extra attention on features that use new technology, are time-sensitive, or are high-priority for the client.
Product Managers should be fluent in enough tech to spark relevant conversations with their engineers so they can maintain independent and negotiable ticket structures.
So far, we have explored business goals, defined a valuable user story, and laid out best practices for getting input from engineers. Now, we’ll see how to determine whether a ticket is feasible. This is where we put rubber to the road with the definition of done.
Last on our INVEST principles list are E=Estimable and T=Testable.
A ticket is only estimable if you have provided enough information and included Acceptance Criteria.
Acceptance Criteria help us create a definition of done. It is a way for the product manager to clearly state what they expect to see on the user side once a ticket is complete.
If Acceptance Criteria are not met, the user story has not passed and should be kicked back to development.
If Acceptance Criteria are met and the end result is not as expected, the user story should be kicked back to business analysis.
A ticket can have multiple Acceptance Criteria. Each will have three parts:
The precondition is the condition the app is in before the action takes place. When creating the acceptance criteria:
The When specifies the exact user action the product manager will be testing. Example: Adding an item to the cart is a user action.
The result is what the product manager is expecting to happen when the user action takes place.
BONUS: Including this information in a ticket provides engineers with enough detail to estimate the unit of work, while also addressing how it will be tested.
That leads us to another one of our INVEST principles, TESTABLE.
To explore what a testable ticket looks like, we’ll return to our example user journey:
As a shopper, I want to add an address to the signup process so that I can make my next purchase more quickly.
We have defined what the user wants to accomplish. The acceptance criteria below are examples of steps in the user journey that can be tested, making it clear to the entire team the definition of done for this ticket.
NEED TO ADD A DESIGN
Acceptance Criteria # 1
Acceptance Criteria # 2
Acceptance Criteria # 3
Acceptance Criteria # 4
And that’s how to complete a ticket using INVEST principles!
Practice makes perfect, so if you are looking for additional challenges, here’s something you can try. Screenshot your favorite app and start to break out that feature into a user story with Acceptance Criteria. It may seem daunting at first, but practice trains the Product Management muscle.