Foundations of Agile Ticket Writing: Estimable and Testable

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

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.

VALUE Part 1 of 4

SMALL Part 2 of 4

INDEPENDENT & NEGOTIABLE 3 of 4