Skip to main content

Great Technical Ticket Writing

Note: The video covers material not in the guide below — please watch in full.

Action Step

Complete this before moving on.

Open a recent task you created in Teamwork (or one you are about to create) and rewrite it using the structure from this training: tool, object or module, record-level details, linked resources, and your specific request with expected outcome. If you are early in onboarding and have not created tasks yet, pick a task already on the board and evaluate whether it follows the do's or falls into the don'ts. Reach out to the team if you want access to a text expander or hot key setup for the ticket structure.

Why Ticket Quality Matters​

By this point in the architect training, you have covered sprint cadences, how to manage a weekly sprint, and how to run sprint calls with the customer. Now the focus moves to the most granular level of project management: tasks. These tasks live in Teamwork, and they contain the full scope of what you need engineers to execute on.

If you give engineers everything they need to go execute, they do not have to wait for you to pull something forward. They can start pulling tasks on their own and keep moving. The alternative is that you become the bottleneck — engineers sit idle because a task is not scoped, or they burn time chasing context that should have already been in the ticket.

Task Creation Requirements​

Every task in Teamwork needs to land in the correct project and the correct task list. The title should make it simple to understand exactly what is being done. Cam highlights that Teamwork automations often push delivered tasks into the customer's shared Slack channel, so a clear title is your chance to light up the scoreboard for their stakeholders.

Beyond the title, make sure each task has a description with scope, an owner assigned (an engineering resource or teammate), and an estimated time. Estimated time is especially critical — it does not show up on the workload view in Teamwork if it is missing. Even a rough forecast helps with capacity planning and sprint building.

Additional fields to consider: a start date and end date, a priority flag (low, medium, or high), tags for visibility (such as flagging something as ad hoc or unplanned), and a type label (advisory, technical, reporting, etc.).

The Do's of Technical Ticket Writing​

Consistency is the single biggest advantage. When your tickets follow the same format every time, engineers pick up tasks quickly with minimal time lost in translation. Here is what consistency looks like in practice:

  • Action-oriented titles. Make it clear what is happening. This is the first thing the engineer sees and the first thing the customer sees in Slack.
  • Expected outcomes. Explain the why — what is the end product you are moving toward? When engineers understand the goal, they can flag things you might have missed or offer technical suggestions you had not considered.
  • Over-explain. If you feel like you are doing too much hand-holding, you are probably not. More detail means fewer questions and faster delivery.
  • Provide examples. When a customer flags a bug or a fix, ask them for the specific record, field, or automation that needs to be debugged. Attach that to the ticket so the engineer has full frame of reference to triage.
  • Include resources for context. Link to Slack conversations, working docs, sprint meeting recordings, and previous related tickets. A screenshot or Slack link alone is not enough — but as a supplement to a well-scoped description, linked resources go a long way.

The Don'ts​

The don'ts are the flip side of everything above. Unclear task names, missing descriptions, and items that sit in on-deck without scope are a major problem. If a task is in the sprint, it needs to be scoped — whether it was planned at the beginning of the week or came in ad hoc.

Slack screenshots as the only context is a specific pattern Cam calls a major no-no. A link to a Slack conversation or a screenshot can supplement a ticket, but it should never be the ticket itself.

Tasks without estimated time on the board hurt your sprint planning. They will not appear on the workload view, so you lose visibility into capacity. Even for items sitting in grooming for a future sprint, start building out estimated times so they land on the workload view when you are planning ahead.

Cam shares a structure that has worked well for him and that many other architects have adopted:

  1. Tool — What system are you working in? Salesforce, HubSpot, Clay, etc.
  2. Object or module — What specific feature, function, or area of the system? Call this out so the engineer knows exactly where to go.
  3. Record-level details — Record types, field names, field types, picklist values, help text, logic requirements. Get as specific as you can.
  4. Resources — Links to related tickets, Slack threads, sprint meeting recordings, working docs. Drive the engineer right back to the relevant context so they do not have to hunt for it.
  5. Request and expected outcome — What exactly are you asking for, and what should the end result look like? Include the why.

If a task is environment-specific — sandbox versus production — call that out. LeanScale engineering methodology often leans toward building in production, but if you need something built in sandbox first for a demo or review, make that explicit.

Breaking Up Large Tasks​

If a task feels chunky — Cam's rule of thumb is anything over four hours — break it into smaller, individual tickets. Large tasks create problems on the workload planning view. A six-hour task on a single day makes it very hard for engineers to operate across multiple customers.

Find natural buckets within the work and split them into bite-sized pieces. Each ticket can still reference the others, but having them as separate items gives you better visibility and gives engineers a clearer path to execution.

Using AI to Speed Things Up​

For ad hoc tasks that come in during the week, Cam recommends using Whisper Flow to talk your scope into the ticket rather than typing everything out. You can also use text expanders with hot keys that pull up the ticket structure automatically. If you want access to a text expander setup, reach out to the team.

For larger project-level task creation, lean on AI tools like Claude Code to generate Teamwork tasks from scope. But for quick, one-off ad hoc tickets, going directly into Teamwork and writing them yourself is often the faster path.