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 according to the pull policies set by the delivery manager (First-In-First-Out queue is preferred, see "pull policies comparisons":http://chronologist.com/blog/2015-03-18/actionable-agile-metrics-review-part-9/) 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.

h3. Commitments and service level expectation 

Commitment to work increases as the ticket flows towards the queuing system. Tickets in the Backlog are treated as “possible candidates for Queue” and until we have analysed them we cannot give any lead time approximations (time of delivery). Some tickets are not feasible, do not fit the IT-strategy, are too large and require more budget to be allocated. Once a ticket is been accepted and pulled into the Queue, we are much more committed to deliver the task and the team will do all it can to push it through the system. Once the item is started (work in progress) than we have a 100% commitment that the item will be completed. It is our policy to not stop something that has started. Only in very rare cases, we cancel a started task. Once we commit to an item (we pulled it into the queue) we are able to give an estimation of the delivery date, a so called service level expectation which is usually expressed in days and a probability in percentage. For example: "there is a 75% probability that the ticket X will be completed in 15 days from now".

h3. Feedback loop: Clarifications and acceptance

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 user acceptance/demo 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. 

# Tickets in backlog and queue do not get started. Only when a ticket is pulled from the queue the status is changed to "in progress".

# Status "in progress" really means "in progress right now", not just that work was started. 

# The project member who creates the ticket sets both the target version and assignee to <blank>, and the category to the correct product. This indicates that the ticket is 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 ticket needs to be passed to another developer/sysadmin, the ticket status is changed either to "new" or "needs clarifications" and ticket is reassigned to the developer, leaving it in the work in progress.

# 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" and percentage done to 100℅, 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. 

# Some tickets may not reach the 100℅ done and stay in a lower level like 70% due to technical issues or external blockets, in these rare cases the product owner may decide to partially accept the work done and close the tickey by leaving the partial percentage.

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.

h2. Further reading and references

# "Pull policies summary and comparison":http://chronologist.com/blog/2015-03-18/actionable-agile-metrics-review-part-9/

# "Time to abandon Scrum sprints? 14+7 arguments for your next steps towards agility":http://www.ontheagilepath.net/2015/05/time-to-abandon-scrum-sprints-147.html

# "Kanban and Scrum - making the most of both ebook from InfoQ":http://www.infoq.com/minibooks/kanban-scrum-minibook

# "Actionable Agile Metrics for Predictability":https://www.actionableagile.com/predictability-book/ Book, See "key points summary":https://docs.google.com/document/d/1zdnWAsgFYkna_ijAxuhS6qFlzWOKcU4s6vIcNiL9LbM/mobilebasic