Ticket creation and definition of ready

Creating new tickets

User stories

When creating new tickets you should follow the template provided:

As a X I want Y so that Z

Related issues: #I, #J

Optional extra information text goes here

Acceptance criteria:

  • A

  • B

  • C

You should fill in the first sentence, explaining the functionality required and who will use it. Make sure you link to any related work, especially prerequisites. You can add more detailed descriptions and fill in the acceptance criteria to describe what tasks need to be completed and what testing might be needed.

A good reference for understanding what a user story is is here: http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/

Labelling issues

A number of labels are available for helping the categorise the available issues. Existing labels are:

Type

  • Administrative: The issue involves general administrative tasks, such as, arranging meetings.

  • Bug: The functionality is not behaving as expected.

  • Documentation: The addition and/or improvement of documentation, either within the code, or in terms of writing documents and reports.

  • Enhancement: An enhancement to existing functionality.

  • Feature: New functionality that does not yet exist in the project.

  • Investigative: A more open-ended investigation, into a technical or scientific development, which may or may not lead to future work to implement the results of the investigation.

  • Maintenance: Improvements to the design, structuring and/or behaviour of a function. Can be viewed as the removal of minor technical debt to improve the supportability and maintainability.

  • Optimisation: An optimisation task mostly focussed on improving the timeliness of processing.

  • Review: A review of the current status of a piece of functionality is required, ahead of starting more work.

  • Technical Debt: Previous issues have resulted in the accumulation of technical debt. These issues do the groundwork to remove the technical debt.

Inactive:

  • Duplicate: A duplicate issue exists, or is already in progress to deal with the features described in this issue. Invalid: The basis of this issue is invalid, so it is not actually required.

  • Invalid: For technical, scientific, administrative or other reasons, the premise of this issue is invalid, so can not be completed.

  • Won’t fix: For technical, scientific, administrative or other reasons, it is not possible to fix the problem described in this issue, or we are acknowledging that we won’t fix this issue as it’s low priority, and alternative solutions may need to be investigated.

  • On Hold: Work started on this issue, however, the priority of this issue decreased, and is now On Hold, potentially until a firmer requirement can be established.

Problem:

  • Blocked: Progress on the issue is blocked. This may require input from others to resolve this issue, or progress of this issue is blocked until other issues have been resolved.

  • Discussion: This issue is in progress but a broader discussion is required to continue making progress, in order to better understand the requirements, or obtain input into potential solutions to the problem.

  • Help Wanted: Assistance is required, potentially in terms of an informal code review, or a dialogue to help make decisions regarding e.g. structuring, style preferences, etc.

Ready to discuss

Tickets are ready for discussion if as much information as possible has been added to the ticket by the person raising the issue. We will discuss the work to ensure that the acceptance criteria are clear and everyone understands what is involved. The splitting up of the ticket into reasonable sized chunks also needs to be considered at this stage, to aid reviewing and to ensure that the simplest and highest priority functionality is implemented first.

Tickets should:

  • Be independent

  • Be estimate-able

  • Be testable

  • Have acceptance criteria.

We also should make an effort to:

  • Make it clear how we show the product owner it is done.

  • Use the description box to provide more information as appropriate.

  • Focus on requirements (necessary outputs, processes etc.) not solutions. Put suggested solutions in the comments on the tickets for discussion when the ticket is started.

  • Use user story format ‘As … I want … so that …’.

  • Be clear enough so there is a shared understanding of the ticket.

  • List all dependencies and related work on the ticket.