Wikimedia Discovery/Process

Overview
The vertical has several sub-teams, all of which are currently using a Kanban-style agile process. A Product Owner manages the priorities of all the tasks across all the sub-teams, using a whole-team workboard with columns for categories of work. Each sub-team has a "sprint" workboard, with typical Kanban workflow columns: Backlog, In Progress, Needs Review, and Done. There are no fixed-length iterations; work continuously flows in and through each sprint workboard. Each sprint workboard exists indefinitely, unlike a typical Scrum workboard which is archived at the end of the timeboxed iteration.

Current Structure

 * VP
 * Product Management
 * User Experience
 * Research and Data
 * Engineering
 * Cirrus Search
 * OpenStreetMap
 * Wikidata Query Service
 * (Embedded Agile Coach from Team Practices)

Proposed Future Structure

 * VP
 * Product Management
 * User Experience
 * (including front-end engineers)
 * (unnamed)
 * Engineering
 * (unnamed)
 * Relevance
 * Services
 * Language
 * (unnamed)
 * Research
 * Data
 * QA
 * Operations
 * (Embedded Agile Coach from Team Practices)

Communication

 * Phabricator
 * Product Backlog: https://phabricator.wikimedia.org/tag/search-team/
 * Sub-team Sprint boards:
 * https://phabricator.wikimedia.org/tag/search-and-discovery-cirrus-sprint/
 * https://phabricator.wikimedia.org/tag/search-and-discovery-openstreetmap-sprint/
 * https://phabricator.wikimedia.org/tag/search-and-discovery-wikidata-query-service-sprint/
 * https://phabricator.wikimedia.org/tag/search-and-discovery-research-and-data-sprint/
 * https://phabricator.wikimedia.org/tag/search-and-discovery-ux-sprint/
 * Legacy boards (which will probably be cleared and archived)
 * CirrusSearch
 * Wikidata-Query-Service
 * ElasticSearch
 * Wikimedia-Search
 * Mediawiki-Search
 * Freezer
 * Mailing lists
 * https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
 * The normal list for all discussion related to search features, team, process, etc.
 * https://lists.wikimedia.org/mailman/listinfo/wikimedia-search-private
 * Only for team email that needs to be private, such as vacation/sick information
 * IRC

Product Backlog
All tasks that the Search & Discovery vertical is working on, or might work on, are tracked in the main Search-Team workboard.

"Backlog" column
This is where new issues will typically start. These could be issues created by team members, or issues created by users or members of other teams.

"On Sprint Board" column
This column contains all the tasks which have been added to any of the sub-team sprint workboards. These tasks might be in the short-term backlog for a sub-team, or may be in progress (being worked on), or may have recently been completed.

''Question: Will this column be sorted by priority? I'm guessing not.''

''Question: Will tasks that have been resolved periodically be removed from this column? If so, will they go to a hidden Archive column or just get removed from the Search-Team project entirely?''

Per sub-team columns
Each sub-team will be represented by a column in the product backlog workboard. These columns represent the entire backlog of future work in that area, and the tasks within each column will be sorted from highest priority at the top, to lowest at the bottom (when viewed in "Natural Order").

Sub-team Sprint backlogs
Each sub-team will have a workboard containing tasks they are working on, along with tasks they might work on within the next week or two, and tasks they have completed within the past week or two. Since the sub-teams do not use fixed-length iterations, each sprint workboard will persist for months, if not forever.

Sub-teams are not expected to use the Story Points field yet. If anyone does want to use it to enter estimates for tasks, they should use the following guidelines for consistency within the foundation:
 * 1 point = Simple task, taking one person not more than a few hours
 * 8 points = Medium task, likely to take 1-3 person-days
 * 40 points = Large task, likely to take 1-3 person-weeks

Anything above 40 points is probably an "epic", and is too large to be a sprint task. The team lead and/or product owner should re-evaluate the task, and should consider splitting it into smaller tasks which would be added to any sprint boards.

"Backlog" column
When issues are added to a sub-team sprint workboard, they will initially be in the Backlog column. Tasks in the backlog column are sorted by priority (highest priority at the top), and are believed to be ready for work. The description should include enough detail, including acceptance criteria, that a developer (or other information worker) can start work.

When developers are ready to take on a new task, they should choose a task from the backlog column, move it to the In Progress column, and assign it to themselves. Generally, they should choose a task near the top of the column, but only when doing so makes sense. Reasons to choose a lower-priority task might include: Not starting a large task when limited time is available; Leaving tasks for others who are much more qualified; Sequencing differently for technical reasons such as dependencies or efficiency.

"In Progress" column
This column contains issues that are being worked on. The sequence of tasks in this column is meaningless. Tasks are not expected to have excruciating details about requirements. Developers are expected to have conversations with the Product Owner, designer, or other stakeholders as necessary to complete the work.

When the work has been completed, the task should be moved to the Needs Review column. If review is required by one specific person, the task can be assigned to that person for clarity. Otherwise, the task should remain assigned to whoever did the main work. With mutual agreement, a task may be reassigned to a different developer.

Developers should try to have as few tasks in this column as reasonably possible. Context switching is expensive, so when possible it is best to take on a task, and complete it, before taking on another. Obviously in the real world this is not always possible or practical. However, minimizing work-in-progress remains a worthwhile goal.

"Needs Review" column
Tasks in this column are waiting for some form of review. They might be assigned to the person who needs to perform the review, or they might be assigned to whoever did the work. Generally this column is not sorted, but in some cases it might help to move a very high priority task to the top of the column, to draw attention to it. Any task in this column should have clear comments describing what review is needed.

When a task has been reviewed, there are three possible outcomes:
 * 1) . The task might need rework. If the work is non-trivial, the task should be moved back to In Progress (and assigned to whoever is doing the rework). If the work is trivial, the task could remain in Needs Review for the brief time that work is being done.
 * 2) . The task might need further review. It should stay in this column, and if necessary should be re-assigned.
 * 3) . The task might be approved. When all necessary review is complete, the task should be moved into the Done column. As a best practice, tasks should always be moved to the Done column first, before being marked Resolved (see below).

''Question: Do we need different types of review? Code review, UX review, PO review?''

''Question: Who should move issues to Done?

"Done" column
Completed tasks are in the Done column, which is not sorted. When the Product Owner agrees that the task is indeed done, and if the task is not active on any other workboards, and does not need any further tracking (such as through deployment), then he or she will change the task status to Resolved.

''Question: Will tasks that have been resolved periodically be removed from this column? If so, will they go to a hidden Archive column or just get removed from the sprint project entirely?''