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 (used for Scrum Master)

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 (manage the Agile board).

# Expedite work management. Makes sure that tickets which are in priority "Immediate" are assigned to proper developer and treated within the day.

# Does NOT put tickets in Queue from backlog (this is PO/EEA's task)

# Helps identifying LARGE tickets (aka Epics) in the Queue and helps splitting them into smaller tickets (max 3 days of work)

# Assure the tickets _Definition of done_ is clear for the developers

# Makes sure tickets are properly distributed among developers. 

  # Identify knowledge-constraints within the team according to demand. 

  # Avoid single-developer dependency on certain technology by actively facilitate IT-knowledge sharing.

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

# Makes sure WIP-limits are respected for developers. Currently max two tickets in progress per developer.

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

# Release management support (software packaging and deployments)

# Set up retrospectives, sprint reviews / planning sessions

# Shield the team from interruptions and scope creep during the sprint:

  # makes sure only tickets from Accepted in Queue are pulled

  # makes sure _scope creep_ does not occur within tickets. We must keep tickets focused, lean and small.

# Remove obstacles that affect the team (and treat the on-hold/blocking issues). 

  # Monitor the WIP-debt and resolve blockers

  # facilitate and speed-ups feedback loops (needs clarifications and acceptance/demo). Aim for feedback resolved within same day.

  # send reminder for those tickets that are in "needs clarification" and "acceptance/demo" for too long (> 1 week). If still issues escalate to EEA Delivery Team Manager.

  # clarify and resolves On-Hold tickets

# Discuss with the EEA re: planning, performance, issues. These includes review of agile metrics like lead-times, cycle-times, velocity, burn-down rates and other measurements and decide on work practices refinements.

# Encourage collaboration between the Team and the EEA when traction is lost

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.

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. Process these tickets while they are "hot" otherwise the more you wait the more unlikely the work will be completed since the development team would be busy with something else.