The anatomy of a good ticket

Defining a good ticket is more than just writing a helpful description. A ticket represents a piece of work someone will focus on in the next few hours/days. A well-defined structure helps any engineer on the team deliver high-quality results, build great products, and reduce cycle time.

Type

The type of ticket represents the output of the work. Specifying the correct type helps measure where the team is spending their efforts.

Here is the list of the common ticket types:

• Story: A story represents a unit of functionality or feature that delivers value from the user’s perspective. It typically includes requirements and acceptance criteria and is generally small enough to be completed within a sprint.
• Task: A task is a smaller unit of work that is often technical and operational, unrelated to specific user outcomes or business value directly.
• Bug: A bug refers to an error, defect, or unexpected behaviour in the system that negatively impacts the functionality or user experience.
• Spike: A spike is a discovery or exploratory task conducted to gain knowledge or answer specific questions on a topic. It often results in a document to guide future development work, typically when there is uncertainty in technical implementation or product requirements.
• Epic: An epic is a significant work that spans multiple stories. It represents a broad initiative, project, or objective that can be broken down into smaller, manageable pieces and usually takes more than one sprint to complete.

Labels

When creating a ticket, we should add labels describing the work category. It gives a granular and more meaningful context. In addition, we can use tools like Swarmia or Jira to get insights to support answering questions about the team’s work, such as:

• What is the percentage of planned vs unplanned work?
• What is the ratio of product vs bugs?
• What is the work percentage that contributes to company OKRs?

Having such metrics can help detect anomalies in team productivity. For example, a high number of unplanned work can be a symptom of poor prioritisation.

The following labels must be mandatory when creating or refining tickets:

• Company OKR: **The following example labels should match the company OKRs the ticket contributes to.
  • scaling_revenue
  • expanding_new_markets
  • operations_improvements

  ---

• unplanned_work - When the ticket sneaks into the sprint without being part of the plan.
• proactive_maintenance - Tickets that are not part of the company OKRs but contribute to improving the systems.
• tech_debt - Tech debt refers to areas of code or systems that need improvement or refactoring due to previous suboptimal design choices, rushed workarounds, or outdated implementations.
• external_deadline - Tickets with an external deadline. e.g.third party API changes.
• Service: The label for the respective services involved during the work’s execution. This label helps us understand the effort required to maintain each service. All services must be prefixed by service_.
  • service_products_api
  • service_users-api
• Risk: The risk of the changes causing issues/incidents (This could also be a field). All risk must be prefixed by risk_.
  • risk_n/a - Not Applicable
  • risk_low - Low risk
  • risk_medium - Medium Risk
  • risk_high - High Risk

The content

What should be the minimum amount of information a ticket should have to provide enough context to complete it successfully?

The content must be clear and include the following sections:

• Title: The ticket’s title must be concise and correctly describe what the ticket is about.
• Context: Why are we doing this ticket? It should capture the context, the problem we are trying to solve, and possibly the impact, which is why solving this problem is essential.
• Approach: What work needs to be done? This section must briefly describe the solution that needs to be implemented. It is recommended that links be included for technical briefs or spikes.
• Acceptance Criteria: What is the expected outcome after the work is done? This should be written from the user’s perspective using the following formula:
  • As a user, when I do X, then Y happens.
  • As a user, when I revoke a mandate, then I shouldn't be able to execute a new payment.

Estimation

In a simplified manner, estimating a ticket consists of assigning a number representing the effort to complete it. For example, if the team estimates a “3” to ticket MRT-123 and a “1” to ticket MRT-134, then the latest should require less effort. It seems a simple process, but predicting the effort is challenging since people have different experience levels and whether they have done something similar.

When estimating a ticket, engineers must consider complexity and time (see matrix below). It is also recommended that the Fibonacci sequence be used to ensure the estimations have a gap. This is a good practice to avoid disagreement between small and large efforts. It also generates healthy discussions between engineers when their estimations are not aligned. If that happens, then, as a team, it’s the perfect moment to review the requirements and ensure everyone has the same context.

Estimating tickets is necessary for capacity planning (understanding how much work the team can commit to). In the agile world, the term velocity is the amount of work a team delivers on average per sprint. So, if the team, on average, completes 22 points, then there is no point in planning 28 points, knowing that it’s unlikely the team can’t finish the work. It’s important to set ambitious and achievable goals (not impossible) to avoid damaging the team’s motivation and overloading them.

PS: On average, teams take three months to find their velocity. This metric MUST not be used to compare teams since each team estimates effort differently.

Definition of Done

How does the team know when the ticket is complete? Defining the definition of done (DoD) as a team is essential to ensure everyone is aligned. Otherwise, the output of a ticket will be completely different depending on who works on it.

A typical DoD consist of the following tasks:

• All the acceptance criteria are complete
• Unit, Integration and E2E tests
• Code reviewed
• Static Analysis
• Write or update the documentation
• Communicate changes to stakeholders
• Deploy and monitor production after deployments
• Run E2E tests after deployment

Template Example

Type: Story

Title: Propagate Payment References in Direct Debits UK

Labels: scaling-revenue risk_low service_connector_bacs_dd

Epic: Link the story to a respective epic.

Context

When a PSU makes a payment, the merchant wants to generate a dynamic reference to identify it, which must be shown in the PSU bank statement. The merchant support team uses this reference to help customers during troubleshooting issues.

Link: Product brief if it exists.

Approach

To propagate the E2E payment reference, we need to update the BACS direct debit contracts to include a new property payment_reference, which the PayIn team populates when creating a new direct debit payment. In the connector-bacs-dd, we need to update the SmarterPay HTTP client to push the new payment_reference field to the SmarterPay system.

Acceptance Criteria

• As a PSU, when I execute a payment, then a unique reference is shown in my bank statement.