<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=490755098261949&amp;ev=PageView&amp;noscript=1">
Heady Logo White
Heady Logo Purple
Big ideas for small screens.
Don’t miss the future.

Nah, I'm good.

By subscribing you agree to our Privacy Policy.

Foundations of Agile Ticket Writing: A 4-Part Series

Katarina Borg

Author Katarina Borg
Published On Aug 26, 2020

This is a multipart series covering the importance of ticket writing with examples using INVEST principles.

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.

This includes:

  • 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

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:

 

  • 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

With these principles in mind, let’s see how they translate into a new signup feature for our fictitious product.

01

Value

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.

Why the details matter

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.


Takeaway

When identifying the user in a user story, it is 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 is 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 when 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.
02

Small

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:

ins9_2image2X-1

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


Takeaway

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.
NOTE:

 

  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
03

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? 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.

Takeaway

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

04

Estimable and Testable

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.

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

  • 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!

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.

ins9_1image2X

Interested in a career at Heady?

Excellent! We are always looking for great talent.

app-clips_1
app-clips_2

Interested in a career at Heady?

Excellent! We are always looking for great talent.

LET'S TALK IT OUT.

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

Or drop us a line.

hello@heady.io