Public documentation

h1. Working with tickets in Taskman

{{>toc}}

h2. Workflow overview

!taskman_ticket_workflow.png!

Things that we want to have done are added to the backlog as tickets by the product owner, the EEA/ETC stakeholders, or by our contracted developers. These tickets have no target version and no assignee, clearly indicating they have not been analysed, prioritised and planned yet. It is the responsibility of the product owner to review the tickets in the backlog, and when a ticket is reviewed it is either invalidated or placed in the queue with a prioritisation set and the requirements properly explained.

When a ticket is placed in the queue it means that we want the developers to start working on the ticket. There will be one queue per team of developers that work for us (a delivery team), making it possible to prioritise among tickets to do among our different products. To avoid that the queue will become another large backlog, it will have a limit of tickets that is set to match the resources in the delivery team, and the focus should only be tickets relevant for the next 1-4 weeks. From the queue, the developers pull the ticket with the highest priority matching their own skills to work on when having capacity available, the ticket will then be moved from the queue to work in progress (WIP). Developers can only pull, or be assigned tickets up to a set limit in order to maximise the flow of work completed.

While developers are working on tickets, they often need clarifications and here the product owner is responsible for quickly clarifying any questions from the developers. We generally want to reduce the length of feedback loops to keep the momentum. Each developer will do a local testing of the work done, this include also checking against continuous integration tests. Bug fixes and simple work may not require extra testing. After the testing is completed the ticket is passed into feedback (aka user acceptance) where the product owner will give feedback and/or accept the work done. In order to facilitate good feedback, the developer must include instructions on where and how to review the implemented functionality. Likewise, the product owner should give feedback as soon as possible before the developer start working on the next task. To avoid a large number of feedback tickets, there is also a set limit on that. When this limit is reached the developer need to contact the product owner to be able to proceed. The product owner is responsible for determining when the work is complete, preferably by stating a definition of done in the ticket. This includes making sure that the delivered functionality is tested before deciding to close the ticket.

h2. Workflow policy

* WIP-limit: A ticket started must be finished before a new ticket is set in progress, reducing costly task-switching. To optimise throughput and lead times, we use max 2 tickets with status "in progress" for each developer. 

* The project member who creates the ticket sets both the target version and assignee to <blank>, and the category to the correct product. This means the ticket will be placed in the backlog. 

* The product owner reviews the ticket, and after clarifying any questions, sets the priority, the target version to the queue for the delivery team, only if the Queue has space for it (each Queue has a limit depending on the resources allocated).

* When a developer from the delivery team has capacity to take on a new ticket (below WIP-limits = has finished one of the previous assigned ticket), the developer assigns the ticket to herself/himself, sets state to "In progress", and the "target version" to be the "work in progress" for the delivery team.

* When working on the ticket, the developer updates the indication of percent done and time reporting on appropriate intervals.

* If clarifications are needed, the developer assigns the ticket to the product owner or stakeholder and sets the state of the ticket to "Needs clarifications". After inputting the required feedback, the product owner or stakeholder re-assigns the ticket back to the developer. As soon as the developer takes up the work on the ticket, she/he sets the status to "In progress". It is important to give feedback as soon as possible, otherwise many tickets accumulate into an "un-finished state" and become a bottleneck for working on future tickets.

* When the developer has completed the ticket, he/she updates the ticket with instructions how to verify the work done, sets the status to "Acceptance/Demo" and assigns it to the product owner.

* If the product owner is satisfied the ticket she/he sets the status to "Closed", the queue to the respective projects "Done"-queue, and the assignee back to the developer (to indicate who has done the work on the ticket). If the product owner is not satisfied with the implementation of the ticket, she/he comments on the ticket and re-assigns it to the developer again, just like the clarification feedback chain described above.

h2. Ticket workflow detailed

!Ticket-workflow.png!

Backlog: 

* target version = none

* status = new/needs clarifications

Queue: 

* target version = Queue

* status = new (accepted/triage)/needs clarifications

Work in progress: 

* target version = Work In Progress

* status = in progress/acceptance/needs clarifications

Done: 

* status= closed

* target version = Release # / Done Q1,Q2,Q3,Q4 ...

h2. Roles

* *Product Owner* (aka Delivery Team Manager): Represents the stakeholders (internal EEA product owners) towards the developers and make sure the WIP-limits and workflow policies are respected.

* *Manager*: This is a senior developer, that supports the Product Owner and further co-ordinate the queue and work in progress, also known as Scrum Master.

* *Developer*: This role is given to the resources that are implementing the tickets, it is mostly consultants and EEA IT-staff. 

* *Reporter*: This is given to all stakeholders and EEA internal product owners that are allowed to suggest new tickets.