Public documentation

h1. Roles instructions

h2. Product Owner / Delivery Team Manager

* Represents the stakeholders (internal EEA product owners) towards the developers

* Accept tickets into the Queue

* Makes sure the WIP-limits and workflow policies are respected

* Protects the developer team from interruptions and distractions

h2. Manager

This is a senior developer within the developers team, also known as _Scrum Master_. There should be only one Scrum Master per team with a fall-back.

* Supports the Product Owner and further co-ordinate the queue and work in progress

* Does NOT put tickets in Queue from backlog (Product Owner's task)

* Breaks LARGE tickets (aka Epics) into smaller tickets when needed

* Makes sure tickets are properly distributed among developers

* Monitor the WIP-Queue and resolve blockers

* Makes sure pull policy from Queue is respected (FIFO order)

* Makes sure QA and testing is properly done before any deployment

* Release management support (software packaging and deployments)

h2. Developer

A developer is part of only one delivery team and responsible for the implementation of tickets for specific applications managed by the team.

Each developer has a WIP-limit of 2 tickets. Meaning only two tickets can be "in progress" at the same time. We discourage heavy multi-tasking which slows down the entire flow of work.

If an immediate ticket is assigned to the developer, the WIP-limit is not applied, and the developer must stop the other task and switch urgently to the new ticket. The immediate tickets are decided only by the Delivery Team Manager, which uses this method with care.

When a developer has capacity (is below is WIP limit, meaning has finished one ticket), he/she may pulls a new ticket from the Delivery Team Queue (there is only one queue per Delivery Team) and only from the Queue, not the backlog (that belongs to the Delivery Team  Manager)!. When the developer pulls a ticket from the queue, in practice he/she changes the assignee to himself/herself, status to "in progress", target version "In progress". 

The pull policy is FIFO, meaning the oldest ticket in the Queue is pulled when capacity is available. This gives the shortest lead times for all tickets that enter the queue. Since each developer belongs to only one team, there is only one queue to pull from.

If a Ticket is not clear, the developer puts it in "needs for clarification" and assign it back to the reporter/delivery team manager. 

If a ticket is awaiting for other tickets, than a relation "Blocked by" is used. If a ticket is awaiting for an external event (outside of our control) we use "On Hold" explaining why.

Once a ticket is completed the developer puts into Acceptance/Demo and assigned back to the Delivery Team Manager or in some cases directly to the Reporter (Author of the ticket), this depends on the nature of the ticket. The Delivery Team Manager is anyway the coordinator and will decide if a ticket needs more feedback or when it is actually going to be finally closed, this to avoid tickets that are stuck and tickets that consume too much resources.

h2. Reporter

h3. Creating new tickets

Navigate to your project and select “New issue” from the menu. If you do not know which project, ask your IDM contact. 

Consider the following options:

* *Tracker*: Use “Feature” (default), unless it’s a defect in the existing functionality, if so then use “Bug”.

* *Subject*: Try to capture the essence of what the ticket is about here, as most of the time people will look at the tickets in list format without the full description visible.

* *Description*: describe the goal of your request (not the “how” to be implemented). If possible use the "user story template":https://www.mountaingoatsoftware.com/agile/user-stories: _As a <type of user>, I want <some goal> so that <some reason>._    

* *Priority*: Select your subjective priority in relation to the other tickets for the same product.

* *Assignee*: Don’t select an assignee, instead the ticket will be picked-up by the first available developer for the project.

* *Category*: Choose the most suitable area of work in the list.

Lastly before finalising the ticket, add the people who should participate or needs to be informed as watchers (if not found, ask user to login once in Taskman). 

h3. Giving feedback

Make sure you monitor the progress of "your tickets":https://taskman.eionet.europa.eu/issues?assigned_to_id=me&set_filter=1&sort=priority%3Adesc%2Cupdated_on%3Adesc (the system will send you notifications when there is an update). Usually the ticket is assigned to you with a status indicating whether clarifications- or a review of the implementation is requested. In order to respond, just input your comments, and the developer (or manager) will re-assign the ticket again.