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

 * 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
 * IRC norms:
 * Everyone on the team probably should have a bouncer (or IRCCloud, which has given us free accounts)
 * You should watch for (get an alert when) someone mentions your nickname
 * But nobody is expected to read the scrollback from when they were away
 * IRC is great for transitory quick conversations and social chitchat
 * Anything substantive, especially related to decisions, should go on wiki or a mailing list
 * Anything substantive, especially related to decisions, should go on wiki or a mailing list

Recurring Meetings
[1] "Leads" means: Dan, Nik, Moiz, Oliver, and Kevin, with Tomasz and Wes optional.

Workflow and Phabricator
All non-trivial coding tasks or other product work should be tracked in Phabricator. This does not include "overhead" work like doing code reviews, attending meetings, or cleaning up phabricator itself. It does include 15-minute bug-fixes, enhancements to test suites, improvements to deployment scripts, etc.

Everything in phabricator is a "task". Other terms that team members might use:
 * Bug: Task where functionality is believed to be "incorrect".
 * Feature: Tasks which defines a new, non-trivial user-facing piece of functionality.
 * Story: Often a synonym for Task. May or may be an actual User story but basically some piece of work that a user would care about.
 * Engineering task: Task that a user doesn't realize they care about. Could be a subtask of a story or might be pure tech work such as refactoring, massive test automation, or switching database engines.
 * Epic: Task representing a large chunk of work. Typically more than a couple person-weeks of effort, and probably too complex to summarize in a single task description. Always contains "subtasks".
 * Sketch: A non-functional, non-pretty depiction of some screen or feature.
 * Mock-up: A pretty but probably non-functional depiction of some screen or feature.
 * Prototype: A roughly functional but probably non-pretty and certainly non-robust implementation of some screen or feature.
 * Wireframe: Something between a sketch, mock-up, and prototype. Relatively ambiguous.

Product Backlog
All tasks that the Search & Discovery vertical is working on, or might work on, are tracked in the main Search-and-Discovery 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. The column is not sorted.

Periodically, the product owner will move all of the resolved tasks from this column into a hidden archive column. If issues are later reopened, someone will need to move them back to a visible column.

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.

Note that these sprint boards are people-centric, not technology centric, so for example any work done by an engineer who mostly works on Cirrus will appear in the Cirrus sprint board, even if that work happens not to be directly related to Cirrus. This allows each person to focus on one workboard, and understand the priorities of all their possible work from just that one board.

The current sub-team sprint projects are:
 * Cirrus
 * This represents work by the Cirrus sub-team, and includes their non-Cirrus-specific work
 * Maps
 * Wikidata-Query-Service
 * Analysis
 * UX

The standard columns on each sub-team sprint board are:
 * Backlog - Work that is ready, but has not been started
 * In Progress - Work that has been started
 * Stalled/Waiting - Work that would be in progress, but is blocked by external factors
 * Needs Review - Work that has been finished, but needs review (see below)
 * Done - Work that has been finished AND reviewed (but not yet signed off by the Product Owner)

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
 * 5 points = Small task, taking about 1-2 person-days.
 * 20 points = Medium task, likely to take up to about 1 person-week.
 * 40 points = Large task, likely to take 2-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.

There should only be two ways that a task is added to the backlog column:
 * The product owner adds it during sprint prioritization, or the team lead adds it with permission/agreement from the product owner.
 * Someone on the sub-team discovers an urgent and nearly-trivial issue, which would take more time to explain and get permission to prioritize than it would to just fix.

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.

Since this team does not yet have any QA support, it is very important that all code go through the normal code review process, and also that it have automated tests. In rare cases that automated tests are not possible, the team lead should be aware of that situation, and the phabricator ticket should be commented to alert the product owner and others.

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.

"Stalled/Waiting" column
Tasks in this column are blocked by external factors. This could be waiting for budget approval, or for a meeting with someone who is unavailable. Note that tasks where the work has been finished but awaits review should go in the Needs Review column instead.

If a task is blocked but is not expected to be worked on soon, consider instead moving it to the Backlog column, or perhaps out of the sprint board entirely, and back to the product backlog board.

"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. Note that review by the product owner is not handled by this column. See the "Done" column instead.

For now, we will have a single "Needs Review" column. Over time, some sprint workboards might end up having multiple columns, representing the different relevant types of review (e.g. code, design, QA).

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. Tasks should not be marked as resolved at this point.

"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. Nobody else should mark tasks as resolved.

Periodically, the product owner will remove resolved tasks from this column. For now, we will remove them from the sprint project entirely. But a possible alternative would be to move them to a hidden archive column.

Feature-Specific Projects
In addition to the backlog and sprint projects, the Search and Discovery department will also track a number of feature-specific projects:
 * CirrusSearch
 * Wikidata-Query-Service
 * ElasticSearch
 * Mediawiki-Search
 * Maps

Whenever a task is added to any of these feature projects, Phabricator will automatically add it to the Search-and-Discovery project as well. That way, it will show up in the product backlog for triage. These feature projects exist for the benefit of the community at large, and not for the development team. The main advantages of having these projects are:
 * 1) . When creating a new task, a user can enter a project of (for example) "Cirrus", and Phabricator will propose the "CirrusSearch" project. This allows users to add tasks to the right project even if they don't realize that the Search and Discovery department will be responsible for them.
 * 2) . Users can view tasks in (for example) the Wikidata-Query-Service project, to see open issues in that area. However, that list might be incomplete, if tasks were added directly to the Search-and-Discovery project, but was not also manually added to the appropriate feature project.

These feature projects will not have a workboard, or if they do it will be unused. All categorization and workflow will be done in the product backlog and sub-team sprint workboards.