Hi All,
Sorry if I'm missing context since I'm new and just starting to read the 
discussion.  I'm a product manager and I can help with some of the 
terminology.Caveat: Terms are generally flexible, so go with whatever works.
Regarding Milestones they're generally meant for big events (i.e. launches or 
when you complete a suite of inter-related features) wherein you take stock and 
review work and see if changes are needed.   They're sometimes time dependent 
(like after 2 months or after 4 sprints) but it depends on what measure works 
As for Epics, they are user stories but more general and vague, that can cover 
a lot of functionality.  Think of it like an umbrella user story that has user 
stories beneath it.  For example, a checkout process might be an epic, while 
shopping cart, address form, payment processor, and confirmation e-mail would 
be user stories under that epic.  Epics are used to get a general idea of the 
scope/priority of the request without breaking everything down.- As for the why 
it should be explained as part of the User Story.  The general form of a user 
story is, As a (actor/state), I want to (function) so that I can/because I want 
to (why).Date: Wed, 10 Feb 2016 12:10:40 -0800
From: br...@snowdrift.coop
To: discuss@lists.snowdrift.coop
Subject: Re: [Discuss] OpenProject Work Packages Workflow

On Sat, Feb 06, 2016 at 06:38:24AM -0600, Jason Harrer wrote:
> 1) Changing the Milestone work package type is indeed an option.
> The reason I chose to create the separate one is because a Milestone
> in OP is intended to be kind of like a tag is in git:  It marks a
> certain point in time.  Once we hit the milestone, we just mark it
> on the timeline and move on.  If we change the Milestone to track
> all the work to reach the milestone, that would take away the
> "tagging" capability.
This strikes me as a win, but it is very likely that I don't
understand why such a tag would be useful. My rationale is: won't we
be able to see when a work package is done by seeing when all its
sub-work-packages are done?
> 2) Your response indicated ideas that I probably would have considered
> Epics instead of User Stories, and that's based on what I read at
> http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes.
My reading of Scrum literature leads me to believe that "epic" is an
adjective applied to user stories. When I use "epic" as a noun, it is
just shorthand for "epic user story". That's why I wasn't sure we
needed both.
However, one thing lacking in Scrum is keeping track of "why" for
tasks. It probably does make sense to keep the two types so it's
possible to see where a user story comes from.

Discuss mailing list
Discuss mailing list

Reply via email to