Writing Effective Engineering Tickets

Efficient and accurate implementation is the key to getting your feature out there as soon as possible and come closer to your desired outcome for the customers.

Pain points for developers and possible solutions

Pain points	Solutions
As a Developer..	As a Product Manager, I can
... I am not a fan of changes well into the sprint when I am already done with my implementation, and not sure why those changes are suddenly creeping up.	Include engineers in the grooming sessions in the product development phase to ensure optimized solutions. While sometimes changes are inevitable, communicate them effectively and make sure the developers understands the reason behind them. Developers are problem solvers and they should know the problem statement very well. Make MVPs for new features so that you can constantly iterate over the feature till you know what exactly works for you.
... I do not want to refer multiple documents at different places (which contradict sometimes by the way) to understand the requirements. Lack of single source of truth for requirements is tedious.	Make sure the ticket is the single source of the 'to-dos' and design is a support pillar to it which carries the information of the components like CSS, placement, padding etc.
.. I want to get to coding as quickly as possible so reading through huge tickets becomes very time consuming and not to mention, boring!	Write concise tickets with module wise implementation requirements. Break large stories into smaller sub-tasks with each sub-task accounting to maximum 1-2 story points. Avoid leaving edge cases to the Engineers and be prepared with those before hand-off

Translating Product Requirements and Design into implementation guide for Developers

Ambiguous guides lead to incorrect implementation and lots of bugs, thus consuming our precious time to release. All this can be minimized, and even avoided by following a template for all your feature tickets. A well written ticket has all of the following information presented in a well structured, easy-to-read manner.

Problem Statement

• What: Precise issue that is going to be addressed in this ticket.

• Why: To make sure everyone understands issue that we intend to solve. This also helps when too many changes creep in and scoping of the ticket becomes a problem.

Impact and Outcome

• What: Explain how this ticket will solve the issue mentioned in Problem Statement and what is the desired outcome for the user. You can also include expected success metrics in here.

• Why: Aids developers, logical creatures, to cultivate subjective mindset for the desired outcome.

Background and Scope

• What: This is additional information that can be useful during implementation and testing. Also mention which modules or touch points of the feature are not scoped in the ticket. Linking product documentation, of modules/ user flows that are going to be affected, in here is always a good practice.

• Why: Avoid confusion and unwanted story bugs that are out of scope.

User Flow

• What: Steps describing the actions that the user would be doing and expected outcome. Try to includes as many edge cases as possible that are under the scope.

• Why: Clear picture of what is to be achieved helps in quicker implementation and fewer bugs.

Functional Specifications

• What: In detail description of component wise specification. This includes expected copy, links to design details (color, font etc)

• Why: It's the source of truth for expected visual specification for developers, thus avoiding unwanted implementation due to ambiguity.

Acceptance Criteria / Scenarios

• What: Modern test cases for teams who move fast and deploy weekly or bi-weekly. This is what we expect the feature to do once it is pushed to production.

• Why: Helps to log bugs and ensure everything is working as intended.

Thank you for reading :) You can reach out to me via LinkedIn or drop an email on [e-mail]