I don't have terribly strong feelings about this, but here's my 2¢ anyway.
I do worry about clutter. The Cirrus sprint board is nice and simple, and
seems to work.
I like the idea of the Kevin's item (b), a high-level board that shows what
tasks are in service of which goals.
Isn't it the job of the PMs (Dan, and the to-be-hired Other Dan) to make
sure during grooming that tasks are relevant to goals? Not that we
shouldn't all worry about it, but that seems to be enough of a regular
Also, we can try things differently in different sub-groups in Discovery
and share what works and what problems are solved. For example, the
Analysis sprint has a stalled/waiting column and the Cirrus sprint
doesn't—if they add an Epic column, they can report back and let us know,
for example, "the epic column is useful because of X, Y, and Z, though it's
really annoying to have so many columns," or "the epic column didn't really
add anything, but having a lot of columns wasn't that bad once you get used
to scrolling sideways."
Software Engineer, Discovery
On Thu, Oct 15, 2015 at 6:55 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:
Within Team Practices, we have been having discussions
about how to map
quarterly goals into phabricator. So I would like to split this into two
1. Should we have an epics column in the Analysis (and other) sprint board?
2. Should we use epics to track quarterly goals?
For point #1, the tradeoff is visibility vs. clutter. Unfortunately,
phabricator boards become increasingly awkward as you add more columns. So
each column has to be valuable enough to justify the space it is taking up.
I'm definitely willing to try having an Epics column, and later deciding
whether or not to keep it.
For point #2, I believe there are three approaches already being used
within the foundation to track quarterly goals in phabricator:
a. Each goal is a project
b. Each goal is a column in a board (not a sprint board, but a high-level
c. Each goal is a task blocked by other tasks that are in service of
There are pros and cons to each, but at the moment I am leaning toward
option (b). However, the answer to that question could involve rethinking
how our Discovery product board is organized, which also relates to the
rethinking we are doing about our standups, which has gotten me thinking
more about how the department itself is structured. It's a big topic(s).
 Example: https://phabricator.wikimedia.org/tag/rd-2016q2/
 VE does something along these lines
 Whether this "task" is an "epic" or a "saga" or
something else is open
for discussion. Technically, to phab, it's just a task.
 My understanding is that FR Tech uses this approach
Agile Coach, Wikimedia Foundation
On Thu, Oct 15, 2015 at 9:18 AM, Oliver Keyes <okeyes(a)wikimedia.org>
Earlier this week at our stand-up I mentioned my concern that although
we were now in the second quarter, our work did not entirely reflect
that; it was hard to point at cards and say "yes, this impacts our
At our sprint planning meeting I had the idea of adding a new column
to our sprint board - one for epics. Quarterly goals are epics (or
should be), and so exist in a form that Phabricator can track. By
including them in our sprint board we force ourselves, each planning
meeting or checkin, to pass over those epics and explain whether we've
been working on them or not and why, which results in informed task
As an example, if we have an epic called "reduce the zero results
rate", and in our sprint planning meeting none of the cards we're
signing off on relate to it, we can prioritise cards that do when
we're pulling stuff out of the backlog.
People seemed to think this was a pretty good idea, but Dan wasn't in
the meeting, so I thought I'd push this to a venue he is in and do so
in a way that is transparent - in case anyone else has suggestions or
concerns or thinks it's something they'd like, too.
discovery mailing list
discovery mailing list