<div dir="ltr"><div class="gmail_extra">I'm playing with this idea here:</div><div class="gmail_extra"><a href="https://phabricator.wikimedia.org/project/sprint/board/942/">https://phabricator.wikimedia.org/project/sprint/board/942/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Problems with using epics is that they can literally capture any category of task -- in any team, for any type of work whether it's testing and practices/process stuff or API/platform work or user-facing releases. Much of this doesn't belong in a roadmap. </div><div class="gmail_extra"><br></div><div class="gmail_extra">So in order for this to work with "epic" alone, we'd have to ..</div><div class="gmail_extra"><br></div><div class="gmail_extra">- stash a lot of epics away into a column where they don't bother us</div><div class="gmail_extra">- hypercategorize the workboard, which would make it less readable as a roadmap</div><div class="gmail_extra">- spend a fair bit of time grooming the backlog to keep it manageable</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not fond of these possibilities. I think having a "Roadmap" project would force a more conscious choice -- you add this if a task meets certain specified criteria _and_ you know that you're going to actually schedule it for completion. "Epic" seems to mostly have value intra-team but less value cross-team, IMO.</div><div class="gmail_extra"><br clear="all"><div>Erik</div>-- <br><div class="gmail_signature"><div dir="ltr">Erik Möller<br>VP of Product & Strategy, Wikimedia Foundation</div></div>
</div></div>