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.

Structure

• Director
  • Product Owner / Management
  • Analysis
  • Engineering
    • Cirrus Search
    • Maps
    • Wikidata Query Service
  • User Experience: Wikipedia.org Portal page
• Embedded Agile Coach from Team Practices
• Embedded Community Liason representative
• Operations liaison

Communication

• Mailing lists
  • https://lists.wikimedia.org/mailman/listinfo/discovery
    • The normal list for all discussion related to search features, team, process, etc.
  • https://lists.wikimedia.org/mailman/listinfo/discovery-private
    • Only for team email that needs to be private, such as vacation/sick information
• IRC
  • #wikimedia-discovery ^connect
  • IRC norms:
    • Everyone on the team probably should have a bouncer (or IRCCloud, which has given us free accounts)
    • You should watch for (and 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

Recurring Meetings

Meeting Name	Frequency	Duration	Purpose	Attendees
Full Team Check-in	Weekly (Tues)	25 minutes	Team-building and information sharing	Entire team vertical
Standup - Search	Twice-weekly (Tues/Thurs)	15 minutes	Detailed status; team-building	Developers and product manager(s) working on search; analyst(s) working with the search team; CL optional
Sprint Planning - Search	Weekly (Tues)	25 minutes	Adding ready tasks to sprint board	Tech lead and product manager(s) working on search; analyst(s) working with the search team; Other search developers and Eng Mgr and vertical head optional
Backlog grooming - Search	Weekly (Thurs)	25 minutes	Triage and prep of product backlog tasks	Tech lead and product manager(s) working on search; CL and analyst(s) working with the search team and vertical head optional
Analysis Backlog Grooming + Sprint Planning	Weekly (Tues/Thurs)	25 minutes	Adding ready tasks to sprint board	Analysts and product manager(s); CL and vertical head optional
Discovery Team Leads	Weekly (Wed)	25 minutes	High-level coordination and planning	Katie, Dan, Erik, Deb, Erika, Kevin
Team Retrospectives	Every 4 wks	50 minutes	Reflect, and plan for improvement	Each team meets roughly monthly for a retrospective
Vertical Retrospective	Quarterly	50 minutes	Reflect, and plan for improvement	The entire vertical meets roughly quarterly for a retrospective
CREDIT showcase	Monthly	50 minutes	Demonstrate cool new stuff	Entire vertical (optional), along with other verticals and interested people

Purpose of meetings

Leads

• Safe space for sensitive (e.g. staff/HR) issues
• Sounding board for general leadership questions
• Place for Discovery managers/leads to gather and have interactive discussions
• Pre-announcement heads-up (e.g. input, getting aligned)
• Inform department head about what's going on (not a big part of it right now)
• In some cases, department head might ask managers to take issues to staff

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" or not operating as designed.
• Feature: Tasks which defines a new, non-trivial user-facing piece of functionality.
• Story: Often a synonym for Task.
  • This may or may not be an actual task, but basically it is 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 that is relatively ambiguous.

Product Backlog

All tasks that the Discovery team vertical is working on, or might work on, are tracked in the main 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. This 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 into 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
• Portal UX

The standard columns on each sub-team sprint board are as follows (but are subject to renaming and/or rearranging per Product Owner):

• 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)

Story Points

The Analysis and Portal teams have started estimating stories using points; the Portal team uses the following estimation guidelines:

• 1 is ultra small. e.g: changing a color, a button size, limited to a few lines of code that are ok to be changed. Very rare actually.
• 2 is small: good, but in practice still hard to be this fast (latency due to code reviews cycle, testing cycle, merging...)
• 3 is a SMALL change. 
• 5 is a MEDIUM change. It is a good compromise between fast developers (estimating 3) and less comfortable ones (estimating 8). It is a MEDIUM change that is *quick* to make, or a SMALL change that is *slow* to make.
• 8 is a BIG change. It should be a pretty big feature already.
• 13 is a bit big. It's always better to break it down, but sometimes it doesn't make sense. At least we know this is big and should be every one's concern.
• 20 is too big. We also had 40 and 100. if you get there, you have a problem.

The Analysis team uses the following estimation guidelines:

• 1 is about half a day's work
• 2 is about a full day's work
• and so on…

Tasks with high point estimates are probably "epics", and are too large to be a sprint task. The team lead and/or product owner should re-evaluate such tasks, and should consider splitting them 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.

Product Owner Sign Off / Completion

Ultimately, sign off is the product owner checking that the work that was done satisfies the acceptance criteria, ideally:

• Check to see if there's a patch linked to the task.
  • Check that it's merged; if it's not, it's doubtful the issue is resolved.
  • Read the description of the patch to make sure that it could plausible solve the issue described in the task (this will involve some guesswork since as PO you are not an engineer, but that's fine, it's just a safeguard)
• Try to make sure the task has sufficient context that it could be understood if anyone (namely, the PO) looked back at it later. Normally if the task doesn't have enough clarity, the PO will either tweak the description or add a comment, depending on what the state of the task is.
• Make sure the task is assigned to the engineer that worked on it, so that the PO knows who to ask questions of later if there are any issues or if additional information is needed.
• (Optional) If the priority is "Needs triage", the PO will investigate it and upon understanding of the task, set it to a different status.

If you're unsure, ping the relevant engineer on the task and ask them if they consider the matter resolved.

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 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 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 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.