Working with tickets in Taskman (Flow) » History » Revision 26
Revision 25 (Antonio De Marinis, 2015-06-17 13:50) → Revision 26/49 (Michael Noren, 2015-10-05 14:13)
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 delivery manager together with together with the product owner to review these tickets at regular basis in the backlog, and when a ticket is reviewed it is either invalidated or placed in the queue with the requirements properly explained.
The action of moving the ticket from Backlog to the Queue is the actual prioritisation intent and a full commitment from the team to work on the ticket. The action of moving a ticket from the Backlog into the Queue represents the actual prioritisation intent from Product Owner and Delivery Team Manager (just-in-time prioritisation). It also the moment when the developers (the delivery team) accepts the work item and and commit to work on it. 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. If the Queue is already full, and we want to add a ticket, than we must swap it with another ticket, meaning that we remove another ticket from the queue and put it back in the backlog.
From the queue, the developers pull the ticket according to the pull policies set by the delivery manager (FIFO see Note 1 below) 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
Generic policies:
# 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 at some point in time.
# Don't create new tickets if you have pending tickets assigned to you for clarifications or acceptance.
Typical flow:
# The project member who creates the ticket sets both the target version (see Note 2) 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
The state diagram below shows how a ticket status changes when going through the flow of work from the left (new) to the right (closed).
!Ticket-workflow.png!
h2. How to identify the main flow steps
In order to identify the different flow steps (Backlog, Queue, Work in progress, Done) in taskman you can use a combination of status and target version. With the information below you can create shortcuts and custom queries for each team (see for example the "frontpage of IDM2 project":https://taskman.eionet.europa.eu/projects/netpub):
*Backlog:*
* target version = none (see Note 2)
* status = new/needs clarifications
*Queue:*
* target version = <TEAM_NAME> - Queue
* status = new (accepted/triage)/needs clarifications
*Work in progress:*
* target version = <TEAM_NAME> - Work In Progress
* status = in progress/acceptance/needs clarifications
*Done:*
* status= closed
* target version = <TEAM_NAME> - Release # / <TEAM_NAME> - Done <YEAR> Q1,Q2,Q3,Q4 ... / none
h2. Roles
* *Product Owner / 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. Notes
Note 1: FIFO: First-In-First-Out queue is preferred as much as possible to avoid some tickets ageing indefinitely in the queue. This is done also to keep our commitment high for what goes in the queue. Everything that is added to the Queue will have to be done within a predictable time-frame, see "pull policies comparisons":http://chronologist.com/blog/2015-03-18/actionable-agile-metrics-review-part-9/
Note 2: The generic rule is to use target version = None for Backlog tickets. However in some cases the Delivery Team Managers may decide to use target version for differentiating different Team Backlogs within the same project.
h2. 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
Go to top