Agile Ticketing 101: Writing Better Tickets With INVEST

The best way to cover the INVEST principles is actually to shuffle them around a bit. Let's start 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 structure enables us to articulate the user value (V from our INVEST principles). However, the task involves more than just filling out this user value template.

Differentiating between the intended user action and the actual user desire is crucial. It may seem straightforward, but this is where many product managers stumble.

A simple example is:

As a user, I want to sign up so that I can log in.

While the difference may seem minor, its significance becomes apparent when prioritizing stories with multiple stakeholders. By being specific and clear about feature value, we can guide stakeholders more effectively and prioritize faster, making our work more efficient overall.

But let's take it further.

It's easy to default to a generic “user,” but most products have various target audiences and personas. A user story becomes stronger if it emphasizes a specific type of user instead of a generic one. Again, while it may not seem like a big difference, these tweaks can help save time and hone in on the most valuable stories and features.

So let's drill down further and add more specificity to our story:

As a repeat shopper, I want to sign up so that I can make my purchase more quickly.

Now we've established that we're creating value for repeat shoppers, the kind of user for whom a business definitely wants to provide an exceptional shopping experience.

Next on our INVEST principles roadmap is S=Small.

The definition of 'small' may vary across organizations, so let's clarify what it means at Heady. We view 'small' as something achievable within a two-week sprint. Tasks expected to take longer than two weeks will likely have unknowns and be segmented into additional steps. While this isn’t a rigid rule, it serves as a handy guideline to keep tickets manageable without overwhelming the team.

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 previous Value section and build on it:

As a repeat shopper, I want to sign up for an account so I can make my purchase more quickly.

We've all experienced many different signup flows, and they vary — so it's 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's via APIs. But if you're just startng out, look at a design and think about the user action at each stage. Discuss assumptions with your engineering team until you get more comfortable with the lingo.

Now, let’s look at two different signup screens:

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 is this important? 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 into what's completed and can be shipped.

Ensuring all tickets are both small and independent may seem ambitious or even 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.

Here we're grouping I=Independent and N=Negotiable together because both rely on getting sign-off 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's 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've 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.

So far in our journey through the INVEST roadmap we've explored business goals, defined a valuable user story, and laid out best practices for getting input from engineers. Now we’ll tackle how to determine whether a ticket is feasible. This is where we put rubber to the road with the definition of 'done'.

Now let's move on to the next INVEST principles on our list, E=Estimable and T=Testable.

A ticket is only estimable if you've provided enough information and included Acceptance Criteria.

Acceptance Criteria help us define what 'done' is. It's 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 aren't 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:

• Given (precondition)
• When (user action)
• Then (user result)

Given (precondition)

The Given, or precondition, is the condition the app is in before the action takes place. When creating the acceptance criteria, here are some important things to keep in mind:

• Keep information included in preconditions relevant to the story.
• Example: If we're testing removing products from a cart, we can set a precondition that there must be products in the cart.
• Another example: If the app requires the user to be logged in to add items to cart, we don’t need to specify that the user is logged in.

When (user action)

The When specifies the exact user action the product manager will be testing. Example: Adding an item to the cart is a user action.

• Focus on one action per acceptance criteria.
• Use active actions like click, scroll, search.
• Passive actions such as view tend to be unnecessary, as they are likely covered by the design file.

Then (result)

The Result is what the product manager is expecting to happen when the user action takes place.

• Focus on one result per acceptance criteria.
• If there is more than one result, confirm that both consequences are clear to the user.

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 our final INVEST principle, T=Testable.