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.

Incoming
Tasks are sweeped in via the reading web dashboard. The dashboard should be manageable by all team members of #Reading-Web-Backlog. Click manage panel on any panel to edit it (and if you can't see manage it - ask someone in the team for that privilege!). Click customization to see the complex query that powers the dashboard. This query is dictated by Reading/Component responsibility.

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.

"Incoming" is the default destination for new cards. Tasks are expected to move from this column in the following manner:


 * Anything judged to be important by anyone (i.e. needs to be dealt with in a timely manner) is moved to "needs prioritisation" for the product owner with a comment explaining why to discuss and prioritise. The product owner should move tasks that need analysis/working on into upcoming, with the expectation they will move to the sprint board within a 2 week period.
 * Anything that is not timely can be moved by the product owner to "triaged but future". Please comment why!
 * Anything that is not the responsibility of the team can be moved to "tracking". Please ensure the right teams are tagged with the task and the expectation is set that the team is not going to work on this.
 * Anything that needs design input should move to the design backlog with directions to the designer on what is needed.
 * Anything that needs a product owner to coordinate with others or to make a decision should move to product owner backlog. Add a comment explaining what is needed.

Upcoming
Upcoming has tasks which should enter into the sprint board within 2 weeks. If they do not, they should move to triaged but future or needs prioritisation. Tasks from upcoming can move to the sprint board when needed. Tasks without estimates should move into Needs analysis. Tasks with estimates should move to "Todo".

Design/Product owner milestones
The product owner or designer will make sure the task is ready for development. When it is it should move to "Needs prioritisation".

Triaged but future
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 during quiet periods.

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

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.

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.

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

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.

Needs analysis
Needs analysis in the sprint board is where analysis of tasks take place. Analysis should take at most 1 hour. During standup, any tasks that are ready for estimation, should have an estimation scheduled or performed if necessary.

Analysis can:


 * deem a task not ready to be worked on,: spikes should be created to make it ready and the task should move back to "needs prioritsation"/"product owner backlog"
 * deem a task unimportant: task should be dropped in priority and put in "triaged but future in backlog" e.g. "This bug only impacts 1 person! Why is this important?" OR "This task is huge - in fact it's an epic. It needs to be broken down."
 * in the case of a task being incredibly easy result in a patch to fix it. In standup flag that it needs an estimation.
 * make a task estimable - when the task has an estimate on it, it can be moved to todo.

Things to think about when analysing:
Spend at most one hour looking at a task.
 * If it's a bug, can you reproduce it? Can you explain to somebody else how to reproduce it? If it's not reproducible move to QA/needs reproduction
 * Is the task clear that you could explain it to somebody else? I.e. which context was missing when you started looking at it?
 * Is it more complicated than an hour? If so, should it be/does it need a spike?
 * If it is a bug, is the source of the bug known? Can you isolate it to a particular browser/module? Even better.. can you find a Minimal test case that fails?
 * If a feature, is how to do this clear? Can you write a strawman proposal?
 * Are any mocks needed?
 * Are there any developer notes that can be added to make a task more useful?

Developer Notes
Developer notes are added to tasks during analysis to share information with the rest of the team that is helpful 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.

Possible outcomes of analysis


 * You might find it's super easy and solve the issue. Post a patch and ping the tech lead to get it fast tracked
 * You might discover it's priority is wrong - for example if a bug impacts 0.001% of page views there's probably not so much urgency to fix it.
 * You might discover it's a bigger problem than we first thought. Bump the priority.
 * You'll make the task easier for whoever ends up working on it
 * You may determine the work is better suited to another team and should not be in our backlog.

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. Tasks will appear here from Upcoming in the backlog (see above).

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.