Another option would be to make Reading Web Planning a Milestone of the backlog project, which would allow for it's own workboard AND a column.

I think that, if a column is desired in some form, it should be for in-progress epics, and anything that does not have tasks in progress should be in Triaged but Future. Example: https://phabricator.wikimedia.org/project/view/56/

Might also be worth noting that Android and iOS, other teams in Reading, have abandoned the approach of having a separate project for epics/goals.

Yet another option would be to abandon epics altogether, a la Android, and just use project boards (instead of cards) for "epics". The projects could be Goals, and the cards just get populated in them. The project could be called something like "Reading-Web-2016-Q1".

Would be easier to track, too. A little radical, but not too hard to implement.

A la Android sounds great!

In T139486#2435904, @bmansurov wrote:

A la Android sounds great!

+1. I think this would put a little more pressure on us to only commit to one goal per quarter – the overhead of having to switch between multiple boards…

In order of personal preference (from +1 to w/e)

• Android-style sounds good
  • Avoids the mess of every quarter change in Reading-Web-Planning
  • Keeps history of what was planned on each quarter
• 1 and 2
  • Get rid of the extra board, just using the backlog
• 3
  • Fine with it but would ask to rename it to #reading-web-epics so that it is obvious what is in there going forward

My preferences coincide with Joaquin's exactly (Android-style > 1 & 2 > 3).

I'm not sure which I prefer. My main concern is we currently keep epics together with tasks which is clearly wrong. I however, worry that throwing more boards at things is unnecessary.

If I understand correctly we would have boards like Android-app-feature-Feeds and Android-app-feature-Navigation ? Would we have one specifically for tech debt?

I'm not so keen on using Q1 / Q2 in project names. Some projects span more than one quarter and are plans frequently seem to change. I think project names would force us to focus and scope.

Been a while, so just wanted to acknowledge I'm thinking of this and will respond ASAP next week.

@Jdlrobson

My main concern is we currently keep epics together with tasks which is clearly wrong

Could you elaborate? For example, epics can coexist with tasks if they are regularly broken down, particularly in a backlog such as the one Reading Web uses. I think the issue may be that Phab, like most digital tracking systems, doesn't play well with epics the way writing on paper does. Traditionally, you crumple up the epic as you shave it down into smaller pieces (post-its etc). Phab prefers to subtask/block. Anyway, my understanding of the Epic pain is that we don't know how they fit into the workflow that tasks use.

There may also be a separate, related problem of trying to work on too many epics simultaneously.

I however, worry that throwing more boards at things is unnecessary.

Agreed, this is a legitimate concern. Specifically, losing One Source of Truth and opening the potential for tasks to be moving across boards that are not the backlog or the sprint. My feeling is multiple "tag" boards = OK and multiple "status" boards is not. Work should be happening in one place (the sprint). Regardless, keeping track of multiple boards is a PO responsibility, so this may have to wait.

If I understand correctly we would have boards like Android-app-feature-Feeds and Android-app-feature-Navigation ?

Yes, in theory, though with Web there are many more projects for which the team is responsible, so it might look/feel different.

Would we have one specifically for tech debt?

We could, sure, although if we are just looking for tasks we could also use filtering (Web-Team-Backlog + Technical-Debt ). Depends on our approach and how we want to organize stuff.

I'm not so keen on using Q1 / Q2 in project names. Some projects span more than one quarter and are plans frequently seem to change. I think project names would force us to focus and scope.

The tags for Q's would be archived with the quarter end, like sprints at the end of the iteration timebox. Example: Open --> TPG-FY2016-17-Q1-Identify-Common-Pain vs Closed --> TPG-2016Q4-Measure-Light-Engagement

We can carry over tasks from one quarter to the next, or skip quarters, just like sprints. That is to say, Q tags can be used to identify work for the quarter, but that is not mutually exclusive relative to other tags. A task could be tagged with a category as well as the quarter.

I initially envisioned the Q tags after we identified a single epic for the current quarter ( T137932: [EPIC] Mobile language switching improvement work II ), which looked like it could be a project (or just tagged with a quarterly tag, at minimum).

Ultimately, the idea is that rather than having an overarching task full of tasks, you have an overarching project full of projects, with the value (and risk) being that there is more flexibility to move cards. Structurally, it's nearly identical, but the UX is better. And it should be said, it doesn't have to be one method or the other. Project tags and traditional epic cards can coexist, we just have to be wary of redundancy (we are also struggling to find a home for epics, which would persist if they remain).

Regardless, I think we should hold off of anything drastic until the new Web PO has her thoughts added to the mix, as it will affect her more than anyone, methinks. Perhaps we can experiment with one epic conversion. I'll also reach out to FR-Tech, as they are a team similar to Reading Web in scope and style, and appear to use project tags like this.