Fundraising/Team processes/How we use Phabricator

Quick Links

Phabricator is our task and bug tracking system.

We have instructions on how to write bugs or tasks here: https://office.wikimedia.org/wiki/Fundraising/Engineering

For ease of use, any stakeholder can use this link to quickly make a task: https://phabricator.wikimedia.org/maniphest/task/create/?projects=fundraising-backlog

If someone wanted to write a spec for an epic sized feature this is a specially formatted task.

Or if you go through the regular task creation flow, just make sure the tag #fundraising-backlog is on the task and it will appear in our triage column.

We have a set of production phases for new payments systems that are reflected in phabricator tasks and planning structures. Fr-tech campaign readiness checklist

Managing the backlog and sprints

We follow a methodology very similar to scrum. We have one, large, prioritized backlog. Every 2 weeks we have a sprint planning meeting where we select the tasks for the next 2 weeks. This block of work is added to a second board (the sprint board). We do our best to complete as much of the sprint as possible. At the end of the sprint, we assess what needs to stay in and what can be pulled out.

The backlog

Organization of the backlog is similar to an agile backlog. The "top" of the backlog should usually be filled with actionable tasks, ready to go into a sprint. As one moves further "down" the backlog, the less defined the work becomes. To accomplish this in phabricator, we have used several columns, moving from left to right. The further right a task is, the further "down" it is in the agile sense.

New tasks are automatically added to the triage column. The product manager scans this column daily. In Q1, Q3 and Q4 the team sorts and clears out this column once a week in a backlog refinement meeting.

The Current Sprint column only changes during sprint planning or when an emergency happens and we need to bring something new in.

Sprint +1, +2 and +3 are hypothetical sprints. If we knew the team velocity, the product manager would try to fit work into these sprints so that the total story points did not exceed the average velocity.

There are many more columns further back but they represent larger blocks on time and lower priority.

Sprints

The sprint board is similar to a scrum sprint board. All unclaimed tasks start on the left side in the "Backlog" column. As a team member claims a task, they move it into the "doing" column. When it is ready for review (usually a code review) it moves to the "Review" column. When it passes code review it moves to the "Pending Deployment" column. When it is in production, it is put in the "Done" column. When the product manager or a stakeholder decides it can be closed, the task is set to "resolved".

Sprint switch-over process

Every 2 weeks on Tuesday during the "Sprint planning" meeting.

Sprint planning prep

Before the sprint planning meeting, the Product Owner should create the new sprint so that it is ready to accept new tasks.

Name it something temporary until the team picks a real name. Usually it is designated by the letter for the sprint i.e. "fundraising sprint O 2021". Also mark the dates of the beginning and ending of the sprint for future reference.

Import the columns used in a previous sprint:

Sprint Planning Meeting

During sprint planning the Product Owner describes the environment the team is facing. What campaigns are running or about to go live? What major bugs have shown up recently? What is the big feature everyone should be working on? The setting established, the team pulls in tasks relevant to addressing the current issues/projects. The tasks are pulled into the "Current Sprint" column. Tasks are estimated as needed.

When the sprint is declared full and the team accepts the scope of tasks, they are bulk edited to add the name of the new sprint.

In the new page, select "add project" and the new sprint name.

As the team is voting on the new name, make sure the dashboard link points to the new sprint.

Go to this dashboard: https://phabricator.wikimedia.org/dashboard/view/129/

Edit the first text dashlet so that the new sprint is identified on the dashboard

Writing the sprint report email

Refer to older emails and click on the links to the listed tasks under the old and new sprints. You can reverse engineer the search details if the following description is not clear. For the old sprint, search for tasks in it but not in the new sprint with any closed status.

Selecting closed tasks with the previous sprint tag but not with the current sprint tag.

For the new sprint, just look up anything listed in the new sprint.

Select all tasks with the current sprint tag

Refer to older emails for formatting. Be sure to give a little context to the decisions made in sprint planning and general highlights for the new sprint.

Updating future sprint columns

Once the email is out, go back to the fundraising backlog workboard and shift the names and dates for the future sprint columns:

Future sprint columns with updated names and dates.

Tools / Processes to make things easier

There are a set of tools that Dwisehaupt (talk) uses to make working with Phabricator easier for sprint work. These are documented in the fundraising_system_documentation repo at phabricator/README.md. The general tools are:

phab_sprint_estimation_dump.py - Used for pulling tasks that can be estimated by group with Poinz.
sprint_point_report.py - Used for getting task point values at sprint completion. Values are then added to the FrTech Sprint Points google sheet to help estimate the current velocity (yes, we don't like that term).
task_assign_points.py - Assign an Estimated story point value to a task.
task_resolve.py - Resolve a task and optionally assign a Final story point value.