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
best.
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@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
