We will explore the concept of tickets, their role in agile project delivery, how they contribute to a successful (or horrific) development process. It is so easy to bungle this and most organisations mess this up. Let's talk about how we can fix that.

What are tickets, and why do they exist?

In agile project delivery, tickets serve as valuable tools for capturing, tracking, and managing individual tasks within the development process. They act as a means of communication, documentation, prioritization, and progress tracking. By utilizing tickets, teams can ensure that work is organized, transparent, and effectively executed.

Exploring the possible types of tickets

Tickets come in various forms, each serving a specific purpose within the development process. Let's take a closer look at some common types of tickets:

User Story: User stories capture the requirements from a user's perspective and describe the desired functionality or feature.

Bug/Defect: Bug or defect tickets are used to report and track issues, problems, or unexpected behaviors in the software that need to be addressed and resolved.

Task: Task tickets represent specific non-user-facing tasks or activities that need to be completed, such as code refactoring, documentation updates, or research.

Improvement/Enhancement: Improvement or enhancement tickets focus on making enhancements to existing features or functionality to improve user experience, performance, or efficiency.

Epic: Epics represent large, high-level initiatives or features that require breaking down into smaller, manageable tasks or user stories. They provide an overarching structure for related tickets.

Technical Debt: Technical debt tickets address areas where the codebase or technical implementation needs improvement or refactoring to maintain code quality or address technical issues.

Documentation: Documentation tickets involve creating, updating, or improving documentation related to the software, including user manuals, API documentation, or internal knowledge base articles.

Research/Spike: Research or spike tickets are used to explore new technologies, investigate feasibility, or gather information before committing to implementing a specific feature or solution.

Support/Incident: Support or incident tickets are related to customer or user support, capturing requests, issues, or inquiries that need to be addressed by the support team.

Release/Deployment: Release or deployment tickets involve the tasks and activities required to prepare, package, and deploy a new version of the software, including release notes, versioning, and deployment plans.

It's important to note that the specific types of tickets used can vary depending on the development methodology (such as Agile or Scrum) and the preferences of the team or organisation. Some people disagree with certain types of ticket even existing. The purpose of this list isn't to tell you what tickets to make, it's to let you know that there are more than one type of ticket and that you should pick the one that suits your needs.

Creating Effective Tickets

Tickets are an island - The anatomy of a strong ticket

To make tickets an "island" of information, it means that the ticket should be self-contained and comprehensive, containing all the necessary information for the development team to understand and execute the task without relying on external sources.

Clear and concise title

The ticket's title should succinctly describe the task or feature to be implemented, allowing team members to quickly understand its purpose.

User story format

Structure the ticket using the user story format, including the role, goal, and benefit. This format provides context and helps the team understand the user's perspective and the intended outcome. This is because tickets are written from the perspective of a user.

Detailed description

Provide a thorough description of the task, explaining its purpose, requirements, and expected behavior. Include any relevant information, such as business rules, dependencies, or technical considerations.

Acceptance criteria

Clearly define the acceptance criteria within the ticket. These criteria serve as measurable guidelines for determining when the task is considered complete and meets the desired quality standards. Include specific scenarios or conditions that must be satisfied.

Visual aids

If applicable, attach visual aids such as wireframes, mockups, or design specifications directly to the ticket. Visual representations provide clarity and eliminate ambiguity, enabling the team to understand the desired end result more easily.

Relevant links or references

Include links or references to related documents, design guidelines, style guides, or any additional resources that are relevant to the task. This ensures that the team has access to all the necessary supporting materials within the ticket itself.

Tags and labels

Use tags or labels to categorize and classify tickets based on their type, priority, or any other relevant criteria. This helps in organizing and searching for tickets when needed.

History and updates

Maintain a clear history of updates, changes, and discussions within the ticket. Document decisions, feedback, and any modifications made during the development process. This historical information provides valuable context and prevents misunderstandings.

Comments and collaboration

Encourage team members to add comments, ask questions, and provide feedback within the ticket. This promotes collaboration and ensures that all relevant discussions and information are centralized within the ticket.

By ensuring that tickets are self-contained islands of information, you reduce the dependency on external sources and provide the development team with all the necessary details and context required to execute the task effectively. This leads to increased efficiency, improved understanding, and higher-quality outcomes.

Estimates

Do not provide estimates or story points. It is not worth the effort. Instead, make the ticket as small as possible and measure the amount of tickets done in an iteration to measure velocity. If a ticket is too heavy, break it down. Sound like a hill you might die on? Read this next section on INVEST.

INVEST in tickets

The acronym INVEST is often used to describe the characteristics that make tickets or user stories effective and valuable for the development process. It stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. This concept emphasizes the importance of creating well-defined tickets that are valuable and actionable. Here's a breakdown of each aspect:

Independent

Tickets should be independent of one another, meaning they can be worked on and completed in isolation. Each ticket should represent a discrete unit of work, allowing for parallel development and reducing dependencies between different tasks.

Negotiable

Tickets should be open to negotiation and discussion between the development team and stakeholders. This flexibility ensures that the ticket can be refined, adjusted, or reprioritized based on changing requirements, feedback, or technical constraints.

Valuable

Tickets should deliver value to the end-users or stakeholders. They should focus on meeting user needs, achieving business goals, or improving the overall product. Prioritizing valuable tickets helps ensure that the development effort is aligned with the most impactful features or requirements.

Estimable

Tickets should be estimable, meaning the development team can reasonably estimate the effort required to complete them. This estimation is crucial for planning, resource allocation, and prioritization. Well-structured tickets with clear requirements and acceptance criteria make it easier to estimate accurately.

Small

Tickets should be small and manageable. Breaking down larger tasks or features into smaller, more digestible tickets allows for better planning, tracking, and execution. Small tickets also promote a sense of progress and achievement, as they can be completed within a reasonable timeframe.

Remember earlier when I said something shocking about estimates? If yout tickets are all small, then we don't need to estimate them. Feel outraged? Shaking your head? Try it, your organisation is agile, right?

Testable

Tickets should be testable, meaning that the desired outcomes and acceptance criteria can be objectively validated. Clear and specific acceptance criteria allow for effective testing, quality assurance, and verification of the implemented functionality.

The INVEST framework was coined by Bill Wake in his book 'Xtreme Programming'. Adhering to these principles ensures that tickets are well-defined, valuable, and actionable. They encourage collaboration, flexibility, and a focus on delivering high-quality outcomes. By considering these aspects when creating and refining tickets, you can enhance the effectiveness and efficiency of your development process.

Regular Feedback from Triage

I'm betting you have a huge backlog of tickets that have not been updated for ages. A huge backlog can mean only one thing: You are not correctly looking back over these tickets to see if they are still correct, or that you are developing features you no longer need.

In an agile organisation, you need to keep the backlog to only the things we will do. It is not a dream state of things we might do in the future.

Delete your backlog.

Regular triage of tickets is essential to maintain a well-organized and efficient development process. It allows you to reassess and prioritize tickets based on changing needs, business goals, and market demands. Here are a few reasons why tickets need regular triage:

Prioritization

Regular triage ensures that high-priority tickets are addressed promptly, keeping the development team focused on the most important tasks. This helps ensure that the development effort is aligned with the most impactful features or requirements.

Resource allocation

Triage helps allocate development resources effectively. By evaluating and categorizing tickets, you can identify resource requirements and allocate the right team members or skill sets to each ticket. This prevents bottlenecks, optimizes resource utilization, and improves overall productivity.

Clarity and understanding

Triage sessions provide an opportunity to review and clarify tickets. It allows stakeholders and the development team to ask questions, seek additional information, or resolve any ambiguities within the tickets. This helps ensure a shared understanding of the requirements and expectations for each ticket.

Risk assessment

Triage helps identify potential risks associated with tickets. By reviewing and assessing the complexity, dependencies, and impact of each ticket, you can proactively address risks and plan mitigation strategies. This helps reduce project delays, quality issues, or unexpected challenges.

Maintenance and cleanup

Regular triage allows you to clean up and manage the ticket backlog effectively. It helps identify and remove obsolete or low-priority tickets, preventing them from cluttering the backlog and diverting attention from more important tasks. This streamlines the development process and improves team focus.

Triage sessions provide an opportunity to refine and improve tickets iteratively. Based on feedback, learnings, and changing requirements, you can update and refine tickets to incorporate new information or changes. This ensures that tickets remain up-to-date, relevant, and actionable.

Transparency and communication

Triage promotes transparency and effective communication among stakeholders and the development team. It provides a platform to discuss and share insights, priorities, and updates related to tickets. This collaborative approach fosters trust, alignment, and facilitates a smoother development process.

Tickets need strong collaboration

Collaborating with stakeholders is crucial for gathering insights, aligning expectations, and ensuring that story tickets accurately reflect the needs and goals of the product. Here are some actions you can take to enhance collaboration with stakeholders:

Hold regular meetings

Schedule meetings with stakeholders to discuss upcoming features, requirements, and priorities. These meetings can be in the form of weekly check-ins, sprint planning sessions, or dedicated workshops.

This is the only time you will hear me say 'hold meetings'. When it comes to collaboration over contract negotiation, you will find stakeholders (read: clients) respond better to face meetings with demos and sane questions about where they might like to take their product next.

We prefer async collaboration to meetings internally, because I'm sure you are already sick of meetings about setting the agenda for later meetings, right?

Involve stakeholders early

Engage stakeholders from the beginning of the product development process. By involving them in the ideation and requirements gathering phase, you can capture their perspectives and insights, ensuring their needs are considered from the start.

Conduct workshops or brainstorming sessions

Organize workshops or brainstorming sessions with stakeholders to generate ideas, clarify requirements, and explore potential solutions together. This collaborative approach encourages active participation and fosters a sense of ownership among stakeholders.

Use collaborative tools

Leverage collaboration tools that enable stakeholders to provide feedback, comment on story tickets, and track progress. Project management tools like Jira, Trello, or Asana often have features that facilitate stakeholder collaboration.

Seek clarification and feedback

Actively seek clarification from stakeholders when requirements are unclear or incomplete. Encourage them to provide feedback on story tickets, acceptance criteria, and any other relevant documentation. This iterative feedback process helps refine the tickets and ensures alignment.

Document decisions and agreements

Maintain clear documentation of decisions made during stakeholder meetings or discussions. This includes capturing requirements, priorities, and any changes to the scope. Having a record of these agreements helps avoid misunderstandings and provides a point of reference throughout the development process.

Regularly communicate progress updates with stakeholders. This can be in the form of progress reports, demos, or status updates. Transparent communication builds trust, keeps stakeholders informed, and allows for early identification of potential issues.

Foster a collaborative culture

Create an environment that encourages collaboration, open communication, and constructive feedback. Foster a culture where stakeholders feel comfortable sharing their perspectives, raising concerns, and actively participating in the development process.

Involve stakeholders in testing and validation

Engage stakeholders in the testing and validation phases to gather their feedback and ensure that the developed features align with their expectations. This involvement helps identify any gaps or areas for improvement before the final release.

Remember that effective collaboration is an ongoing process. Regularly assess and refine your collaboration practices based on feedback and the evolving needs of your stakeholders.

Ticket Graveyards

There are so many systems for working with tickets. Let's start with the simplest one we can and work upwards.

Single State

We can have these states:

Does not exist
To-do

[TO_DO]

Let's assume that our tickets are created just before we work on them, and then we delete them after the work is done. I know this sounds wild but bear with me.

This basic list where work that is to complete exists has this feature: Ability to buffer. We can front load work ahead of time and execute that work at a different speed.

This means the tickets have a single state: 'To do' that they are born in, and they are killed off when the task is complete. Think of this like a to-do list where when you check off an item, it is simply removed. This system can be used to eprform rudimentary work, and if you were disciplined, then you would be able to build quite complex things with just this simple single state.

We get a cool feature for free here, since we can order these tickets in any order we please, we get the Ability to prioritize the tickets by whatever mechanism we desire.

Think of the tickets of features we might make as a deck of cards. As we come up with more ideas and add in our plans, we increase the size of the deck. The deck is a stack, able to buffer up lots of ideas for later exectiuon, effectively, it is our memory of ideas.

Two State

[TO_DO] <-> [IN_PROGRESS]

Let's add in another state. We can now have these states:

Does not exist
To-do
Doing

This one lets us track work that is currently being worked on. Two states dramatically increases the clarity for teams of people all working on the same thing. Multiple team members working on multiple tickets, it's now possible to see what others are working on, and we see our first upgrade: WIP Tracking.

Tickets can now be moved between two states, they can be taken out of progress and put back into 'To-do'. This gives us our second upgrade: Quality Control

You might have noticed that we added a state and a few intersting things are added to our armoury.

Three States

[TO_DO] <-> [DOING] <-> [DONE]

Let's add in another state. We can now have these states:

Does not exist
To-do
Doing
Done

Done is a state of ticket whereby we do not delete the ticket afterwards, we remember it and place it in plain sight. This gives us another upgrade: Reflection, or the ability to know if something has been done before.

The typical Kanban board has three columns: To Do, Doing, and Done. Invented by Toyota to improve manufacturing efficiency, this very simple style of board allows tickets to exist in one of three columns (Or not to exist at all). In kanban, problem areas are highlighted by measuring lead time and cycle time of the full process and process steps.

What we are saying where is that flow is more important than velocity.

A goal of the kanban system is to limit the buildup of excess inventory at any point in production. Limits on the number of items waiting at supply points are established and then reduced as inefficiencies are identified and removed. Whenever a limit is exceeded, this points to an inefficiency that should be addressed.

Schonberger, R.J. (2001). Let's Fix It! Overcoming the Crisis in Manufacturing. New York: Free Press. pp. 70–71.

When using a Kanban system with three columns labeled "To Do," "Doing," and "Done," there are several bottlenecks that you might encounter. Here are a few common bottlenecks:

Overloaded "Doing" column

If the "Doing" column becomes overloaded with too many tasks in progress, it can slow down the entire team's progress. It indicates that the team is taking on more work than they can handle simultaneously, leading to multitasking and reduced efficiency. You can see this manifesting itself visually in something called a cumulative flow diagram. Ask your local Jira buff.

A nice rulf of thumb is that a single person should only do one thing at a time, they need to focus on a single task. If there are more things in progress than you have people working in the problems, then people are double sipping. If you have less things in progress than you have people working, then somebody is either not moving tickets, or not doing tickets.

If you find a situation where it cannot be helped, because one ticket is dependant on another, then the tickets themslves are written incorrectly. The correct course of action is to stop and fix the tickets, not to work on both. tickets need to be independent of one another.

Accumulation in "To Do" column

If the "To Do" column continuously accumulates a large number of tasks, it suggests a bottleneck in the initial stages of the workflow. It could be due to various reasons, such as a lack of clear priorities, insufficient resources, or dependencies on external teams.

With a truly agile organisation, it makes absolurely no sense to build a backlog of issues. Every ticket we write may be discarded at any time, in favour of a different way of doing things. I've seen a single idea in architecture to optimise for cost, wipe out 30+ tickets.

With welcoming constantly changing requirements, we welcome stripping out the backlog as no longer the way to build something. Tickets are not a strict list of things we must do, they are a guide to give us a direction for right now, not for six months. Hopefully you see that a big backlog is a waterfall trait. Do everything you can to strip the backlog to zero as often as possible and rebuild.

Prolonged tasks in "Doing" column

If tasks tend to remain in the "Doing" column for an extended period, it indicates a bottleneck in the execution phase. It could be a result of dependencies, lack of clarity or understanding of the task, or unforeseen obstacles.

The most common cause of tickets lingering in the 'doing' column is in fact large ticket sizes. Remember INVEST? Think of the 'small' part. If every ticket was small, then they would move from one column to the next in the shortest time.

Engineer skill also plays a big part in the amount of time a ticket spends in the doing column. For this, tickets with higher cognitive complexity are better of being mobbed by engineers from several walks of production, to get the best of all of them.

We won't talk here about mobbing, but lets just say that my opinion is that it is critical to the success of an organisation, the culture, and it's product

If tasks are frequently getting delayed or stuck in the "Doing" column, it signifies a bottleneck in the final stages of the workflow. It could be due to issues with quality assurance, testing, or deployment processes.

Define what 'done' looks like for your organisation and stick to it.

Bottlenecks caused by dependencies

Dependencies between tasks can create bottlenecks. If a task in the "Doing" column relies on another task in the "To Do" column, it can cause delays and affect the overall flow. It is important to identify and manage dependencies effectively to prevent bottlenecks.

The 'Independent' part of INVEST makes tickets less likely to encounter a bottleneck. As mentioned previously, each ticket should be an island. If you find your tickets are getting clogged up and this ticket needs that ticket, then it will screw up your flow. Decouple the tickets and releive this bottleneck.

Uneven distribution of work

If there is an uneven distribution of tasks among team members, it can lead to bottlenecks. Some team members might be overwhelmed with work, while others have less to do. This imbalance can result in delays and hinder the team's overall progress.

Sometimes a team might have one engineer that outshines the rest, they may know all about the system they are working in and be able to blast through tickets. This is very bad. Unfortunately, bad coluture rewards this behaviour. It also has the toxic trait of making others feel like less skilled people. You'll have heard the terms to describe this, 10x engineer, rockstar etc.

The solution is to have the skilled person train the less skilled people.

Actions

OK, that was a heavy topic, but here are the key takeaways

Work in the correct direction adds value, tickets describe work.
Tickets have more than one type.
We need to make the units of work as small as possble.
Tickets should be able to stand alone and need no other tickets to allow the value to be delivered.
Tickets should be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Once a ticket has been created, it needs regular updates. Do not be afraid to update a ticket.
Ticket creation is the responsibility of the stakeholder, quality assurance and also production.
Maintain the backlog.
Keep work in the backlog for only the next immidiate business problem. Delete everything else.

Understanding Tickets in Agile Project Delivery