Writing successful development tickets requires more than just understanding the problem to explain it simply in a very concise manner. Examine the sample ticket above for we will be referring back to aspects of this ticket throughout the discussion. While the easiest of these to draft are malfunction tickets, meaning something is broken and needs to be investigated then likely fixed as soon as possible it takes time to consider how to articulate this from your personal perspective to your intended audience’s point of view. The following are some simple rules to keep in mind while you draft your own tickets.
- Keep your title brief but descriptive without slashes, quotation marks and extraneous characters
- The summary is your chance to explain the problem in two to three brief sentences necessary to define the goal(s)
- AVOID superfluous language
- Seriously consider avoiding the classic agile example: “As a [user] would like to [do something] to [achieve some benefit].”
- Place ALL screen shots, links and supporting information in the References section
- Focus on the desired outcome
- The requirements should immediately follow the summary
- Each requirement should be brief, direct, actionable and applicable to the team completing the work
- Expect the engineering team to rework you ticket possibly even breaking it into multiple achievable tickets
- Double check for spelling errors
The engineering team is responsible for completing the Definition of Done and the Test Plan sections. In addition although you are required to enter a story point estimate the team will adjust during backlog grooming to ensure that the level of effort is properly aligned with the requirements.
During backlog groom the team will review the requirements and request clarification as needed to ensure that the scope of the ticket is achievable. It may be necessary to break the ticket into two or more related tickets to ensure that the work is the smallest achievable effort aligned with the scope. For instance if we must connect a site/system to a new API then a developer must at a minimum review the API documentation, conduct a POC to investigate the API and then build the final product. Those are three differently scoped items each deserving of their own ticket and the main project should be elevated to an EPIC. See How to draft an EPIC in Jira.
Let’s take a deeper look at the sample ticket. Observe that the title: Investigate why the coffee maker is not making coffee is very direct and specific. It includes enough information to identify this ticket form other in a listing or Jira query results page. It contains enough key words to make it searchable in the future.
The summary expands on the title explaining why it is important to investigate this issue. Remember your summary should never contain links, images or statements that can be misconstrued as additional requirements. If it is a requirement then it MUST be stated in the requirements section if it is not then it is OUT OF SCOPE!
The summary is immediately followed by the requirements which is the MOST important block for the developer. This details the steps that must be completed to move the ticket on to QA. The following are a set of investigation requirements that generally fit most investigative circumstances.
The requirements establish the scope of the ticket and once the work has begin should NEVER be altered except to add clarity to already established instructions. If a ticket’s requirements change mid development the correct action is to draft a followup ticket and link it to the current one. That new ticket will have a scope unique to it’s requirements. In addition this change order may impact already agreed upon delivery dates and this must be addressed in the new ticket.
As with every rule there are exceptions. If the engineering team agrees that the change is truly minor and requested early enough in a sprint to not adversely affect the overall scope then they may alter the requirements to include the change.
This change should be recorded in a manner that demonstrate it is an after thought.
As previously mention the engineering team will determine the Definition of Done from the scope of work outlined in the requirements. It is important that the developer know when to pass the work on to QA so that they may return to the backlog queue to pick up their next ticket. Additionally it is the engineering team’s responsibility, by way of the developer, to draft the test plan for the QA team to validate the work.
The following are some additional fields that may appear below the References section. They are in actuality rarely used on standard work tickets and tend to only appear on EPIC and Project Abstracts.
Acceptance Criteria
This should be covered in the Acceptance Criteria field. What will be considered a success by the product owner or business stakeholder? This field is used for QA verification.
QA Requirements
Definition of QA resource requirements necessary for approval:
- Peer Review only (true/false)
- QA Team over site (true/false)
UAT Requirements
Definition of UAT requirements necessary for final approval:
- Peer Review only (true/false)
- Product owner review (true/false)
- Submitter/Stakeholder review (true/false)
Out of scope
Want to deliver MVP needed to create value. Specify out of scope items so they don’t divert the team’s focus from delivering the value proposition. Items noted in the requirements may be promoted to out of scope during backlog grooming or sprint planning by the engineering team.
Something to keep in mind that as a reporter on a particular ticket you will be assign to conduct and/or facilitate UAT. It is your responsibility to ensure that the UAT stage is completed quickly and thoroughly. UAT is marked complete when the ticket is moved into the Release Ready status and is reassigned back to the engineer who completed the work.
Finally when a ticket is release ready the developer will pick the ticket up to merge the approved merge request into the appropriate stage to release the code and update the release notes. At this point the engineer should log any final time and mark the ticket as complete/closed.
