Ticket templates

BDD ticket template: Given / When / Then

Behavior-driven development describes a feature as concrete scenarios: the starting situation, what the user does, and what must happen. The same scenarios work as acceptance criteria for the team and as a starting point for automated tests.

Generate one from your idea →

The template

**Title**:
[Tag] Implement behavior for <feature>

**Feature**: <Feature name>

**Scenario 1**:
**Given** <context>
**When** <action>
**Then** <expected result>

**Scenario 2**:
**Given** ...
**When** ...
**Then** ...

### Technical Notes
- Edge cases to consider: ...
- API paths affected: ...

Example: from rough idea to ticket

What you type into KanBandit, and the ticket it turns into with this template.

Your input

apply a discount code at checkout, invalid or expired codes show an error, only one code per order

Generated ticket

[Checkout] Implement behavior for discount codes

Feature

Apply a discount code at checkout

Scenario 1: Valid code

Given a cart worth €80 and an active code SPRING20 for 20% off

When the customer applies SPRING20

Then the order total shows €64 and the discount appears as its own line item

Scenario 2: Expired code

Given a code SUMMER10 that expired yesterday

When the customer applies SUMMER10

Then the total is unchanged and the message "This code has expired" is shown

Scenario 3: Second code

Given an order that already has SPRING20 applied

When the customer applies another code

Then the second code is rejected with "Only one code per order" and SPRING20 stays applied

Technical Notes

Edge cases: codes are case-insensitive; trim surrounding spaces
Recalculate the discount when cart items change after the code was applied
API paths affected: POST /cart/discount, DELETE /cart/discount

Tips for better BDD scenarios

01One behavior per scenario
If a scenario needs "and then ... and then ...", it is testing two things. Split it so a failure points to one cause.
02Use concrete examples
"A cart worth €80 and a 20% code" is easier to build and test than "a cart and a discount". Real numbers make the expected result obvious.
03Describe behavior, not clicks
"When the customer applies the code" survives a redesign; "When they click the blue button in the sidebar" does not.
04Write the unhappy scenarios too
Invalid input, expired data and limits are scenarios in their own right. They are usually where the real rules of the feature live.

Other ticket templates

Turn your backlog notes into tickets like this

Write what you need in plain words. KanBandit fills in this template, including acceptance criteria, and syncs the ticket to Jira. Free to start.

Start free