On Mon, Jun 1, 2015 at 1:35 PM, Kevin Smith <[email protected]> wrote: > > On Mon, Jun 1, 2015 at 12:26 PM, Bryan Davis <[email protected]> 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 <[email protected]> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855 _______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
