Roles instructions » History » Revision 25
Revision 24 (Antonio De Marinis, 2019-03-06 12:13) → Revision 25/25 (Antonio De Marinis, 2019-03-06 12:15)
h1. Roles instructions h2. EEA Product Owner / Delivery Team Manager * EEA IT Staff that represents the stakeholders (internal EEA product owners) towards the developers / contractor * Accept tickets into the Queue (manage project scope and allocated budget) * Makes sure the WIP-limits and workflow policies are respected * Protects the developer team from interruptions and distractions * Final QA and acceptance of all deliveries. h2. Manager (used for Scrum Master) This is usually an experienced a senior developer at within the contractor developers side, 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". 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" and explaining the reason of it in the ticket. 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 at EEA and the Scrum Master will work in tandem and 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 as a "Kanban board":https://taskman.eionet.europa.eu/agile/board?query_id=546 or as a "list":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. h2. Other roles There are other roles which are present on each project which are assigned by Taskman Administrator and are not necesserly involved in the tickets workflow. h3. EEA Staff This is a basic role given to all EEA Staff (users with the "eea-staff ldap role":https://www.eionet.europa.eu/ldap-roles/?role_id=eea-staff). This role gives same permissions as the Reporter role and it is added by default on all projects in Taskman. EEA Staff is by default a trusted group and have permission to read all projects and report issues. h3. Contractor Finance Dept This role is given to one or more people from the consultancy company that is responsible for generating time reports/sheets as a basis for monthly invoces sent to EEA. This role has only permission to read/correct/generate time reports.Go to top