Create a New Ticket

The Create Issue screen will be displayed.

Writing an Effective Ticket

JIRA tickets are submitted and reviewed by many different sources, including developers and customers. Writing effective tickets helps us better manage our backlog, aids in reporting of our product baselines, and enables automation of release notes.

Guidance by Field

Issue Type Field

DDF generally uses the following issue types. Choose the Issue type that best suits the issue.

Issues	Description
Bug	A problem which impairs or prevents the functions of the product.
Epic	A significant body of work that encompasses many user stories.
New Feature	A new feature of the product.
Story	A unit of work adding capability to the product.
Task	A task that needs to be performed that does not impact the software baseline.
Improvement	An enhancement to an existing feature.
Documentation	A task involving software documentation.
Technical Debt	A task that results from poor design choices or incomplete work.
Spike	Used for design, investigation, and prototyping to determine feasibility of design strategies.

Issue type descriptions are also found at https://codice.atlassian.net/secure/ShowConstantsHelp.jspa?decorator=popup#IssueTypes.

Summary Field

The summary field is a high level description of the WHAT needs to be resolved. Consider your audience, the summary needs to clearly and succinctly detail the feature or issue from the user's perspective.

General guidelines for Summary

- Templates. If functionality change, use user story template (see below). If bug fix, use bug fix template (see below)
- Describes the issue from a behavioral perspective (i.e. no implementation details)
- Understandable for most audiences, e.g. customer, users, stakeholders
- Content should be professional in nature

User Story Template

As a <type of user>, I need <some goal>, so that <some reason>

- For features or new functionality, use the user story template for the summary
- User stories provide context to the person working the ticket
- User stories communicate the value of the ticket
- DDF generally uses the following roles: User; Administrator; Integrator

Bug Fix Template

<Symptom> due to <Cause> [, forcing user to <workaround>]

The summary appears automatically in the release notes and must follow this template
Do not write a bug against unreleased software, if the bug was introduced by another ticket that is not in a release, work the bug fix under that ticket number.
Use specific language to describe the bug (refer to the template above), do not use the word "bug" to describe the problem (i.e. "UI has a bug that stops it from loading")

Priority Field

Choose a priority based on the IMPACT of the issue, indicating the importance. Pay close attention to this field when creating Bug type issues.

Priority	Description
Blocker	Blocks development and/or testing work, production could not run.
Critical	Crashes, loss of data, severe memory leak.
Major	Major loss of function.
Minor	Minor loss of function, or other problem where easy workaround is present.
Trivial	Cosmetic problem like misspelt words or misaligned text.

Priority descriptions are also found at https://codice.atlassian.net/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels.

Affects Version/s Field

The Affects Version/s field indicates the version where the issues was observed or can be reproduced.
This is N/A for new epics, features, and user stories.
For bug fixes, select only a released version. For example, do not write a bug against 2.10.0 if it has not been released yet.
For bug fixes, only select a version if the bug actually manifests itself in that version; do not write a bug against 2.9.0 if the bug is not in 2.9.0.

Fix Version/s Field

The Fix Version/s field indicates the version in which the issue is resolved. For planning purposes, this field can indicate the version this issue is intended to be resolved by.

- This field is required when an issue is resolved.
- This field should not be populated for changes that can be observed in DIB versions. For example, spikes generally should not not have the Fix Version/s field populated.
- If ticket has been completed on both the bug fix branch and the master branch, the Fix Version/s field should include both versions (e.g. DDF-3363 - Getting issue details... STATUS ).

Description Field

The description field is a detailed, narrative description of the issue. General guidelines for the description field:

- Provide details!
- Describe the context, big picture
- Include how to reproduce the issue, log/error messages, and expected/actual behavior
- Include acceptance criteria, i.e. how we will know when this ticket is done
- Describe the impact; i.e. why this needs to be done, or what will happen if this issue is not resolved
- Content should be professional in nature

DDF

JIRA Primer | Best Practices