Team Practices Group/Proposal for work categorization

Proposal

Anyone moving a task to Team-Practices-This-Week should ensure it has one of two tags: "TPG-FY2016Q3" or "TPG Essential Functions".
1. do one-time catch up on existing work on Team-Practices-This-Week (open, and closed this quarter)
2. Also keep the top few items in the Team-Practices-This-Week backlog categorized
When we close tasks, try to categorize them at a more detailed level using the Milestone Parent hack.
1. Can optionally categorize more, but not required
This information will be used:
1. by Kristen at all scanning the Work Boards at planning
2. in Phlogiston reports that we can review in, for example, retros

Additional Information

Ways to Categorize

Teams at WMF categorize their work in a variety of ways. The two most common logical ways to categorize are by feature (e.g., "Infrastructure monitoring", "Android UI") and by state of work ("In Design", "In Testing", etc). These approachs are realized in Phabricator with great diversity. This section describes the technical choices for implementing categorization:

By Project

Each task is assigned a project.

Pro: Only way to see two different categorizations at once in Phabricator UI. Typical use: One project holds all tasks, with each column on the workboard representing a state. Other projects designate each feature category, so that the project tags on the task cards show feature categorization.

Con: Assigning tasks to categories requires five actions (edit card, click in Project field, type part of category name, click on the match in the list, click save).

By Project Column

Each task is assigned to a column within a project.

Pro: changing category requires two actions (click, drag).

Con: This information is only visible on the project workboard. When the task is viewed in other contexts, category is not visible (on other boards, the project is visible in the card but not the column. In query results, neither is visible.

By Milestone Parent

Each task is marked as "Blocking" a task in the "Milestone" (or blocking a task that blocks a task etc etc until a Milestone is blocked.

Pro: Many teams already organize many tasks by this relationship, so little to no extra effort is required.

Con: Category is almost completely invisible in Phabricator, can only be visualized in derived (Phlogiston) reports. Overloads the "blocked by" relationship.

TPG case study in using sub-projects to sub-categorize

We identified several different ways we could use sub-projects to categorize TPG work. All options preserve the current practice of using "Team-Practices" as "Team-Practices-This-Week" as status boards, with columns representing different status choices; the new categories would be in addition.

As of 2 Mar 2016, Option 2a is recommended for consideration by the rest of the team.

Option 1: Subprojects, including Quarterly Goal

All work is tagged either "Team-Practices" or "Team-Practices-This-Week", and work that relates to the quarterly goals is also tagged "FY2016Q3".

 TPG
 - Team-Practices
 - Team-Practices-This-Week
 - FY2016Q3
 (untagged)

Treat everything untagged as "Essential Function" Con: can't tell the difference between "untriaged" and "triaged to Essential Function")

Option 2: Subprojects, including Tag Quarterly Goal vs other

All work is tagged either "Team-Practices" or "Team-Practices-This-Week", and all work is tagged either FY2016Q3 or "Essential Functions".

 TPG
 - Team-Practices
 - Team-Practices-This-Week
 - FY2016Q3
 - Essential Functions
 (untagged)

Pro: It's possible to search for "TPG" and get all tasks belonging to all sub-projects. Con: may be hard to undo sub-projects if we change our mind

Option 2a: Use Projects but not Sub-projects

All work is tagged either "Team-Practices" or "Team-Practices-This-Week", and all work is tagged either FY2016Q3 or "Essential Functions".

 - Team-Practices
 - Team-Practices-This-Week
 - FY2016Q3
 - Essential Functions
 (untagged)

Option 3

All work is tagged either "Team-Practices" or "Team-Practices-This-Week", and all work is tagged with one of the goal-specific tags.

TPG

 - Team-Practices
 - Team-Practices-This-Week
 - FY2016Q3
 - Core Fraction
 - TPG Strategy
 - CSAT
 - FY2016Q4
 - Core Fraction
 - TPG Strategy
 - etc...
 - Essential Functions
 - ... Practices ...
 - etc ...

Pro: Detailed categorization is performed at the same time as simple categorization; no need for Parent/Milestone categorization. Con: Extra cost to use and maintain all of the sub-projects

Use cases for work categorization

The proposal should satisfy use case 1, a little bit of 3/3a, and part of 5.

1) As a team work planner, I need to know how much work is not goal-related so that in crunch-time I can de-prioritize it.

Work planner could be manager or could be team member self-planning.

Work = active or planned work.

Goal could be quarterly goal or other work.

2) As a team manager, I need to make weekly reports so that I can meet managerial requirements.

3) As a team planner in a weekly planning meeting, I want to know how much capacity we have for new work in the next week and how close we are to deadlines so that I can defer non-deadline work.

3a) As a team manager responsible for team deadlines, I want to know if the team is currently on track to meet those deadlines so that if not I can take corrective action.

4) As a team member, I need to add work to the board other than at weekly triage & planning so that I can document new work without waiting until next Tuesday & Thursday to start it.

5) As a team planner, I need to oversee the implicit or explicit triage each task has received so that I can help team members balance their priorities.

Use Cases for work tracking more generally

Triage

As a Product Owner, I want to categorize and prioritize incoming tasks so that they can be worked on by the right people at the right time.

VE does this with a weekly triage meeting in which the Product Owner views all new tasks in the last week, in order of submission (or reversed), and triages one at a time. Specifically, the PO looks at tasks in the default column of the VisualEditor project, edits the Priority field, possibly adds a comment, and drags the task to a different column. In VE, the columns represent different [initiatives/ultra-milestones/goals/tranches/categories] (for example, "Rich Media" or "Language Support").

Overview (grooming)

As a Product Owner with new priorities, I want to alter the backlog for my project to reflect new priorities.

VE does this via the PO adding and renaming columns and moving tasks between columns on the work board. (All VE work is on a single workboard, which means it's all in one project.) We have also experimented with using the "Blocked By" relationship to identify a tree of related tasks, but this is not visible in Phabricator workboards (nor can ancestor Blocked-By be seen or sorted or filtered on) and can only be seen in Phlogiston reports.

As a Product Owner with knowledge of work in my project, I want to review the backlog for my project so that I can see if the backlog is current and correct compared to reality.

In VE, this has two parts: First, are tasks in right categories? This normally happens in triage, but the Product Owner occasionally notices something out of place (a task in the wrong column) while examining the board view for other purposes. Second, are categories right in relation to one another? This happens when the PO looks at the board, but more often when the PO looks at the Phlogiston report that shows not only columns but also task family (blocked by)-based categorizations.

VE sometimes does overall work planning (in the style of Scrum card mapping, where tasks from different areas/columns are all sliced into different releases/rows) from the board. I've already heard that some teams have approximated Scrum card mapping by using "dummy tasks" in columns, so that tasks above or below that task in a column can be perceived to be in a theoretical "row" that may be consistent across columns.

The main activity in VE that isn't supported adequately in Phabricator is mixing blocked-by relationships and columns. For example, VE may have 50 tasks in the "Language" column, and five of those tasks may all be set to block a "Release Korean support". Those six tasks comprise "sub-category" within Language, where Language is a broad, long-term grouping and "Release Korean support" is a subset with a fixed scope. There is no way directly in Phabricator to see, in one view, which tasks share the same blocking relationship. One way to support this in Phabrictor would be to add a display field in the task and/or task card showing the ancestor "blocks" task(s). Currently we can see this in aggregate, but not per-task, in Phlogiston reports. The sub-project construct supports the same underlying data relationship, but in a different, reversed way: in Phabricator, you can filter on a project and you will see all tasks belonging to sub-projects.

Decide what to work on next

As someone doing work in a project, I want to use category and priority and assignment information to figure out which task to work on next.

Normally, VE team members do this via consultation with the Product Owner, but on occasion they navigate to the VE work board and look at the top of the columns they are working on to identify new work.

Definitions

"Category" refers to fields differentiating the type of work or subject of the work (which software package, which team, which website, etc) that people use to filter tasks. I've seen teams use project tags, project columns, blocked by relationships, and tacit conventions about task placement within Phabricator project boards, and combinations thereof, to categorize work. "Priority" refers to any task information used to determine relative importance; I'm aware of teams using either the Priority field, or position and rank within a Phabricator project or columns, or both.