Foundations of Agile Ticket Writing: A 4-Part Series

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.

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:

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.

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:

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

Given (precondition)

The precondition is the condition the app is in before the action takes place. When creating the acceptance criteria:

• Keep info included in preconditions relevant to the story.
• Example: If we are 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

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.