Reading/Web/Phabricator

For project, workflow and task management the Reading Web Team uses Phabricator. Here you can find some documentation about how we use it, and which boards we're working with.

Projects/Boards

 * Team dashboard (For triaging and urgent tasks).
 * A board per software artifact (MobileFrontend, Gather, TextExtracts, etc. See dashboard for the list).
 * A general Reading Web backlog board for tasks or bugs that can't be classified in the other software projects.
 * A forever sprint board for work in progress

Workflow
We use project classification and setting the task's priority to organize our work (harnessing the power of Phabricator search). As a secondary method we use the project's boards to sub-classify tasks, but not on all boards, only in the biggest ones.

Tasks that need the team's attention to set a priority need to be on the Needs triage priority. Then the team will have a look and chime in, and assign a priority based on several factors (urgency, workload, need for discussion, etc). Priority should be set by people intending to work on the task or by product owners prioritizing for engineers to work on it.
 * Unbreak now! tasks will be moved to the current sprint and worked on as soon as engineers are available. This priority will also ping other teams (notably Release Engineering) to let them know that this bug may impact a deploy. If the task is not time sensitive, use "high".
 * High priority tasks will be reviewed when planning following sprints and will likely be tackled soon.
 * Normal priority tasks will be reviewed when the backlog of High priority tasks is low, and will be promoted to High if we're planning to work on them next.
 * Low priority tasks likely need to be discussed or are not an immediate priority for the team. They may be re-prioritised during quiet periods.
 * Lowest priority tasks most probably need to be fleshed out and discussed or are far from getting in to the teams work load in their current state.

High level overview
Inside our backlog there is a column "Epics/Goals". Epics that are currently being worked on are moved into the forever sprint board to signal that there is a commitment to complete them. Epics will have subtasks that live in either the backlog or the tracking column, providing easy access to related work. As we work on tasks they will be pulled into the sprint board with the view of being completed within a 2 week period.

Triaging new tasks
For triaging we use the backlog. Cards that come from outside our workflow are picked up as part of a shared chore list. The backlog by default only shows cards that are priority normal or higher.

"To triage" is the default destination for new cards. Here they are assigned a priority and then moved to "needs analysis" for technical review or "tracking" if they are not priorities for the given time.

Needs analysis is primarily used by the tech lead who's job is to keep it empty. The tech lead is responsible for ensuring tasks leaving this column are well defined, scoped and ready to work on. The tech lead (possibly with help of others) will carry out a brief investigation of any tasks here that are priority normal or higher, ideally to understand which parts of the stack the task touches and if a bug whether the route cause of the problem can be identified. If tasks are low they will defer that analysis for a future date when they are not.

Developer notes are added to tasks to share information with the rest of the team that is necessary for them to discuss and estimate the task. When this has been done the task is moved to "Triaged but future". If a task needs input from the design lead, it will be moved into the design milestone.

Design (milestone) is used by the designer to track tasks that need their input. When the input has been completed the designer will pass to the tech lead via need analysis

Triaged but future is used by the product owner to choose work that should be worked on next, based on current priorities will move tasks that will be worked on soon to upcoming to signal an estimation is needed.

Upcoming is used during estimation meetings to ensure tasks are well defined, identify missing acceptance criteria and ultimate estimate. The tasks here can be used to populate the sprint board's todo column. The team strives to have all tasks in triaged but future and upcoming well defined and estimated, but will focus on the priorities in upcoming.

Current sprint (milestone): When tasks are moved into the sprint board which is archived periodically, with the aim to show what has been worked on in any given quarter. Generally, unless the tasks is an epic, the expectation is that adding a task to the current sprint means that it will be resolved within a 2 week window.

Needs Reproduction column is seldom used, but can be used when during technical review an issue cannot be replicated and is therefore not actionable. It might also be used for general QA.

Product Owner column is used by the product owner. It is a place for tasks that need product analysis or may depend on future product decisions. Sometimes, the technical lead will move tasks here when input or guidance is sought from the product owner, in particular where estimation/analysis will be quite expensive.

Tracking (milestone) is used for tasks that are of interest to the readers web team but are not being worked on by them. It will also be used to track work that will not be worked on in the near time future and reduce noise in the backlog. Tasks in tracking may move into needs analysis pipeline at any time based on team/community needs. Note the tech lead might use a user board tag e.g. User-Jdlrobson to track work relating to upcoming epics/projects.

Sprint
The sprint (kanbanan) board is a milestone of the backlog. It has its own columns and process. The sprint board is the single source of truth for what the team is currently collaborating on.

Cards that enter the sprint board are expected to move along the sprint board to the right hand side quickly and then disappear. The sprint board is not the place for things which do not concern at least 3 members of the team or long term work.

For instance, if a developer is working on a side project that makes an alarm go off every time a wiki page gets edited, but she's not seeking review, design input, QA or analysis from any of her colleagues that does not belong on the board. If a designer is working on some mocks to prepare for the next quarter, but only requires input sporadically from a developer and product person that also does not go on the board.

Columns
Epics - this reflects the current commitments of the team. An epic is big chunk of work that encompasses many smaller chunks of work, and often takes more than a couple of dev cycles (2 weeks) to finish. It might consists of multiple steps and/or have multiple sub tasks. For example an epic might involve running an A/B test, and that epic may have several subtasks such as "Start the A/B test", "End the A/B test" and "Analyse the A/B test results". Subtasking is encouraged because of the Two week rule. Generally, we should have at most 6 epics in flight at any given time because of the overhead of context switching.

Todo - a never ending surplus of tasks that people can pick up and work on. Generally tasks are picked from the top, but depending on estimations and time available, it is fine to pick from other smaller tasks.

Blocked on others - Someone from another team has blocked progress with the task some how. This is flagged during standups during which work on the task may be reconsidered/re-evaluated. It's encouraged for tasks to be removed from the sprint board if they remain blocked for long periods of time because of the Two week rule.

Doing - a task is being worked on but is not yet at a stage where others can participate. The assignee is the point person for the task and they may pull in others as needed, but that responsibility sits with them.

Design review - many tasks need input before we can even consider merging them and sending them to our users. This checkpoint allows a designer to have their say on in flight work. Note in some cases, tasks will move between code review and this column depending on the work.

Code review - the assignee is asking for feedback from others on something they have done. Usually this relates to code, but it can also relate to asking for feedback on a write up or a spike.

Needs QA - we want to check that code that has been written is bug free.

Sign off - when a task moves here someone (usually the product owner) signs off that everything has been done that has been asked for and that a certain level of quality has been achieved. The signer off will scrutinize the task and check that it matches the work done. New tasks can be created if necessary on the back of work. Some tasks have sign off steps which must be followed before resolving the task.

Sign off Criteria
The following guidelines apply for the successful completion of a single task:


 * 1) Review QA & QA screenshots - Does everything look okay?  Is there something odd/unexpected?
 * 2) Test on at least one browser and device
 * 3) Review description - make sure all the boxes are checked off in acceptance criteria, signoff criteria, etc
 * 4) Check for subtasks - if there's subtasks open, can we move them to a different task or are they a blocker for signoff?
 * 5) Check if follow-up tasks need to be created and create them if necessary
 * 6) Mark resolved

The 3-day guideline
If an in-progress task has not had any update in 3 days, and/or has not moved from a column in 3 days, the team will take this as a signal to investigate why. The team understands that there are valid reasons for this (vacation, illness, work is slightly harder than expected, etc), and simply wants to make sure the assignee of the ticket has what they need to proceed. If a task must remain static for longer than 3 days, the team may consider removing it from the board (and stop working on it), or else spin off followup tasks, etc.

The two week guideline
If a task has not been resolved within 2 weeks of entering the team's "in-progress" board (typically a Kanban board), or is lingering in a column for an extended period of time suggesting it will not be resolved within 2 weeks, the team interprets this as a red flag, and investigates. When noticing this is the case, any team member should raise the situation as a concern (ideally in the team standup - email or in person). There are various reasons a task may be blocked in another column or not resolved, and it's worth asking the following questions:


 * Has scope creeped?
 * It's possible the task was not well defined up front, and/or new information has emerged. This happens. However, it might indicate one of several things:
 * The task is not understood
 * New tasks need to be created, including spikes
 * Is another team not prioritising this task as highly as us?
 * In some cases, we will work with another team and it might be the case that they are not prioritising the work as highly as us. In this situation we might want to consider rescheduling the work or finding other ways to make progress that are not blocked on others.
 * We'll probably want to move the task out of the sprint board and pursue it separately in a way that doesn't distract the rest of the team.
 * Is the task actually an epic?
 * If various subtasks are being creating (or related tasks that are not associated with the task), this has probably happened. Label it as an epic and move it to the epics column (or backlog if the product owner doesn't thing this is something we should commit to).
 * Is there a misunderstanding of what done means for the task?
 * If a task lacks acceptance criteria, it's possible this has happened.
 * Understand the expectations/confusions in the task.
 * Consider splitting out into multiple tasks if different disciplines are expecting different things.
 * Example: A task is created to create a prototype, however the card has remained in design review for 3 weeks. An engineer may have expected "done" to mean "deploy the prototype" whereas the designer may be running some design research on the prototype and expect "done" to mean "run and finish the design research". In this case, we might amend current tasks/create two tasks "Deploy the prototype" and "Perform design research on the prototype" so it's clearer.