<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=490755098261949&amp;ev=PageView&amp;noscript=1">

:tada:2024 WEBBY WINNER: The Crate & Barrel mobile app won a Webby Award!

Agile Ticketing 101: Writing Better Tickets With INVEST

Katarina Borg
Author Katarina Borg
Published On Jul 12, 2023

At Heady, our experience managing dozens of products and hundreds of releases has taught us the value of robust ticket writing.

This sometimes overlooked skill is critical to the successful and timely delivery of software. How does thoughtful and strategic ticket writing help our team at Heady stay on top of fast-moving projects? This blog explores the essential skill of how to write agile tickets and best practices that every product manager should know.

Product management involves not just strategic planning but also delivering on those strategies, which accounts for a substantial portion of the job — about 90%, in fact. Clear direction and coordination are vital for effectively delivering on a strategy.

A Heady Product Manager must master the foundational skills of effective ticket writing in order to achieve all the other tasks and goals that are central to success in their role, including:

  • Defining product value
  • Stating clear goals
  • Getting implementation feedback from engineers
  • Giving the team boundaries and success metrics
  • Understanding and breaking down roadmaps into manageable pieces of work
  • Shipping relevant software consistently

It's time to debunk the misconception that ticket writing is merely filling out a template. Here we'll dive into the nuances that separate a mediocre ticket from a rock star ticket. By learning and embracing these guidelines, you’ll build your strengths as a product manager — and once you’ve mastered the rules, you’ll be able to strategically break them as needed.

The first step in mastering ticket writing 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:

  • Independent — of other tickets
  • Negotiable — not a specific contract for features; engineers should provide input
  • Valuable — provide user and business value
  • Estimable — include enough information to estimate
  • Small — manageable enough unit of work
  • Testable — a QA or PM can test the end result

Now let's see how these principles translate into a new signup feature for our imaginary product.



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.

Why the Details Matter

Product managers are asked to add business value by adding product value. If we're 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.

Key Takeaways

When identifying the user in a user story, it's important to:

  • Keep personas in mind: Is this feature relevant for all of them?
  • Be as specific as possible: Dig deeper and ask, “Who is the target audience for this feature?” For example, adding a billing address is only relevant for repeat users purchasing with a credit card online.

When identifying the value of a unit of work in a user story, it's important to:

  1. Understand the why of a feature or user story. If the value of a story is not clear, this typically signifies a flaw in the design or feature overall.
  2. Challenge your own assumptions whenever possible.
  3. Add data to support the validity of your proposed value.
  4. Remember that adding value with every ticket will always lead to a positive ROI.


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:


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 I can check out faster.

As a shopper, I want to add my credit card information so I can check out faster.

As a shopper, I want to provide my preferences so I can get relevant product recommendations.

Key Takeaways

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.

A few important notes to keep in mind:

  1. In an ideal world, the design will always be signed off on before starting ticket work.
  2. Final designs should be attached to the ticket to keep all the information in one place.
  3. Breaking down the design is the best way to identify INVEST-able units of work.

Independent and Negotiable

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.

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. But keep in mind that 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, so you'll want to focus extra attention on features that use new technology, are time-sensitive, or are high-priority for the client.

Key Takeaways

Product managers should be fluent enough in tech to spark relevant conversations with their engineers so they can maintain independent and negotiable ticket structures.


Estimable and Testable

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.

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 during the signup process so I can make my next purchase more quickly.

Here we've 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.

Acceptance Criteria # 1

  • Given a user has not entered numbers into the zipcode
  • When they click to sign up
  • Then they are auto-scrolled up to the zip code field and shown an error message stating “you must enter valid zip code”


Acceptance Criteria # 2

  • Given a user has entered a complete address
  • When they click to sign up
  • Then the address is validated


Acceptance Criteria # 3

  • Given a complete, but the incorrect address
  • When the address is validated
  • Then the user is shown an error message stating that “address does not exist”


Acceptance Criteria # 4

  • Given a complete, correct address
  • When the address is validated
  • Then the user is taken to their account page


And that’s how to complete a ticket using INVEST principles!

Summing It Up

Effective ticket writing is a cornerstone of agile product management. It enables a team to break down complex projects into manageable, valuable pieces of work that can be independently developed, easily estimated, and thoroughly tested.

By following the INVEST principles and putting effort into crafting clear and comprehensive user stories, you can help your team deliver high-quality software consistently and efficiently.

Remember, a well-written ticket is more than just a task: It's a conversation starter that encourages collaboration and leads to superior outcomes. 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 in the beginning, but as you grow in your product management role, you should always be striving to refine your ticket-writing skills. Your team, your clients, and your users will thank you for it.


Interested in joining the Heady team?

We're always looking for great talent.


Interested in joining the Heady team?

We're always looking for great talent.


Figuring out your next step? We're here for you.

Or drop us a line.