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 <[email protected]> wrote: > 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 >
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
