[teampractices] Phabricator's "Epic" tag...why?

Mon Jun 1 21:27:05 UTC 2015

Thanks Bryan. I'm not convinced that I would find it helpful, but I think I
see how you did.

Navigating between bite-sized tasks, epics, and roadmaps is a challenging
problem, which doesn't appear to have been solved.

I fully retract my proposal of eliminating the Epic tag. But I stick by my
proposal of making it optional.

Kevin Smith
Agile Coach
Wikimedia Foundation

*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*

On Mon, Jun 1, 2015 at 1:44 PM, Bryan Davis <bd808 at wikimedia.org> wrote:

> On Mon, Jun 1, 2015 at 1:35 PM, Kevin Smith <ksmith at wikimedia.org> wrote:
> >
> > On Mon, Jun 1, 2015 at 12:26 PM, Bryan Davis <bd808 at wikimedia.org>
> wrote:
> >>
> >> We used them for quarterly planning and other roadmapping activities.
> >> This was a replacement for our prior process of maintaining a wiki
> >> page to track the things that the team was interested in working on
> >> (or that other teams were asking us to work on in the future).
> >
> >
> > Ok. I'm still trying to understand this. Were *all* issues part of an
> Epic,
> > or were there a mix of Epics (with subtasks) and standalone non-epics?
> For
> > me, the line between epic and non-epic is very fuzzy, so viewing
> everything
> > on one side of the fuzzy line doesn't seem very helpful. I'm genuinely
> > curious here.
>
> Not all tasks were traceable to an epic but all areas of work that we
> felt were large enough to be considered for quarterly planning were
> epics.
>
> For me, the line between an epic and a non-epic is easy. Epics are all
> tasks that are larger than the granularity used by the team for
> iteration planning. Epics are useful to track and discuss features
> that are too large to be built in a single sprint or as a single
> sprint task. Discussion of this is veering towards a religious debate
> however. :)
>
> > Would the Goal project type be more appropriate for roadmapping?
>
> Maybe in some cases. Creating a separate goal project for each epic
> seems pretty drastic unless the epics are very very large. I guess for
> the use case that MediaWiki-Core was using we could have had a
> "future" goal type project that we stuck things in. For us the big
> issue was that there were hundreds of various sized issues that had
> been assigned to the team for some reason or other and most of these
> were not issues that were relevant for roadmap grooming. The
> intersection of #mw-core and #epic was much easier to groom. Due to
> the way that Phabricator is designed to work these sort of
> intersection searches work well where non-structured text searches
> fail.
>
> >> I have no personal desire to force a team or project into a particular
> >> workflow. I'd rather not have my team's workflow changed so that you
> >> don't get nagged by some undisclosed Phabricator user however.
> >
> >
> > That makes total sense to me. If there is one right answer that fits
> > everyone, great. But if not, then let's not force either team to work
> > inefficiently.
>
>
> Bryan
> --
> Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
> [[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
> irc: bd808                                        v:415.839.6885 x6855
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150601/87d2ed67/attachment.html>