Hi, Bryan -

Thank you for that feedback.  I realized as I was reading your response
that you were out of the channel most of the week and I had forgot to put
in this caveat in this e-mail:  I intentionally set it up as detailed as I
could think of, realizing that it probably would be overkill for
Snowdrift.coop.  The intent behind that was to let people see it used fully
and try to determine what we *don't* need, as opposed to trying to go too
basic and having people say "I think it needs something more, but I can't
figure out what."

That being said, I totally appreciate everything that you said, and I'm
inclined to agree on most of it.  It definitely needs to be scaled back.
Here's my feedback on the few things that I'd like for you (and others) to
ponder a bit more:

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.  That being said,
I personally don't care what the work package types are called.  If you
prefer Milestone to be the top level, here would be my proposal:


   1. Rename the current Milestone work package type to "Tag"
      2. Rename the current Phase work package type to "Milestone" (or some
      other term that we agree on)
      3. Delete the Release work package type


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.  There's
a bunch of additional defining that goes on beyond "I can pledge artificial
money to projects to see how the mechanism works."  What page will the
pledging options be on?  How will the user get to that page?  Granted, for
that example, I think we already have answers to those items, but the point
is that by defining individual tasks in a User Story (e.g. "User clicks
clicks on 'button x' to go to project page"), it will allow us to analyze
each step and ensure that we have identified every task of work that will
need to be performed.  I'm concerned if we don't split out the high level
"I want to do this" from the low level "This is each step that needs to be
taken to get to this", we may miss something during the implementation.
I'm not saying we definitely have to go the Epic + User Story route, but
I'm just asking you to rethink it based on that explanation.  You may be
right:  It could still be overkill for Snowdrift.coop.  I'm just not fully
convinced of that yet.

So, let me know what ya'll think about these.  Thanks!!

- Jason

On Fri, Feb 5, 2016 at 4:31 PM, Bryan Richter <br...@snowdrift.coop> wrote:

> On Fri, Feb 05, 2016 at 01:23:57PM -0600, Jason Harrer wrote:
> >
> > Here are my proposoals.
> >
> >    - Work will be tracked in Releases
> >       - Release is a new Work Package type that I created.
> >         OpenProject was using it in their instance, and it made
> >         sense. It's a high level package to track all the cumulative
> >         work going on to get us to a certain point (in our current
> >         case, the alpha prototype)
> >       - We currently have more of a rolling release style, so either
> >         we can consider revising when we release updated code, or we
> >         can just consider the release done when the last piece is
> >         rolled out.  I'm guessing the latter, but I just watned to
> >         point out the two options.
> >    - Each release would be laid out to have 5 different phases:
> >
> >
> >      - *Phase I:  Requirements Gathering*:  This will be when we
> >        determine all of the different components we want to work on
> >        for this release.  Each component will yield its own Epic
> >        (which will be chlidren work packages under Phase I), tracked
> >        under Phase I.
> >      - *Phase II: Implementation Specifications*: (Note: Thinking of
> >        changing this to just Specifications or Solutioning):  This
> >        is where the Epics are reviewed and broken down into User
> >        Stories (which will be children work packages under Phase
> >        II).  From those User Stories, tasks will be created (as
> >        children under Phase III, even though they're created during
> >        Phase II).  Note that the tasks will need to be assigned to
> >        the appropriate Circle/Group).
> >      - *Phase III: Implementation*: This will be where the tasks
> >        that were created in Phase II are actually worked on by the
> >        respective teams.  Any code bugs during this step can be
> >        created and made children under Phase III to be worked before
> >        moving to testing.
> >      - *Phase IV: Testing: *This will be where the code is ran
> >        through automated tests, as well (potentially) as manual
> >        review, to ensure that there are no foreseable bugs.  Any
> >        bugs found during this phase would be created as children
> >        under Phase IV.
> >      - *Phase V: Deployment:  *This would be assigned to the Sys
> >        Admin team to actually deploy the changes.
> >
> >
> >      - If we stick with Rolling Release, I still believe the above
> >        five phases could work, though each Epic could be in
> >        different phases at different points.  Then, I believe we'd
> >        be probably be looking more at a kanban style workflow than
> >        what I have listed above.  I know there is the backlogs
> >        section that we have that could be reviewed as well.
> >
> >
> >      - I still need to figure out where we  would want to store our
> >        Feature Requests/WishList items.  There are some proposals
> >        I'd have on that:
> >
> >
> >    1. We could create work packages with a type of Feature Requests,
> >       which (at first) would not be linked to anything.  When we
> >       decide we want to use it, we could convert it to an Epic and
> >       add it to the Release we're putting it in.
> >    2. If we're not going to use the Backlogs section for anything
> >       else, this could be a place to have them, which would at least
> >       allow us more sorting capabilities than #1 (Though I would
> >       have ideas for prioritization in #1 as well, just probably not
> >       as quick and easy as a kanban board).
> >    3. Wiki page on OP.  Then, every member has access, organization
> >       is a simple cut/paste, etc.
> >
> > I appreciate and welcome all comments, questions, brainstorming, etc.
> > Anything to help us move forward.  Thanks!!
> >
> > - Jason (JazzyEagle)
>
> Hi Jason, thanks for taking the initiative on this. It's nice to have
> a starting point.
>
> For such a small team, a process that's too structured will just end
> up getting abandoned. Let's make sure the process is meeting our
> needs, and *only* meeting our needs.
>
> I already feel like we're caught up in fitting into some predefined
> framework instead of finding tools to fill our needs.
>
> So what are our needs?
>
> I will only speak of the WEBSITE project (not legal, not financial,
> not outreach). For that project, I posit that we only need milestones
> and user stories right now (for the next couple weeks).
>
> MILESTONES
> ----------
>
> One need we have right now is keeping the ship pointed in the right
> direction. Getting to full functionality is crossing a big ocean and
> we need some stars to guide by.
>
> We've *already done this*, by breaking it down into milestones. I
> think we should keep that terminology. I know OpenProject makes the
> word "milestone" special and kinda useless by default, but that's a
> checkbox that can be unchecked:
>
> https://i.imgur.com/xCkexfp.jpg
>
> http://shovel.snowdrift.coop/projects/snowdrift/settings/types
>
> So, if we can, we should uncheck that box and use 'milestone' as our
> biggest-scope work package.
>
> Side note: we need milestones *right now*, as we move towards full
> functionality, but I suspect we won't always need them at all times in
> the future. That is, we should *not* mandate that work always fall under
> a milestone. Sometimes that scope will be too big to be useful.
>
> Side note 2: One thing we *don't* need is releases. Those exist for
> software that is bundled up and distributed. We only do that in the
> most degenerate sense, and that won't change.
>
>
> USER STORIES
> ------------
>
> Like I said, we already have milestones. The first milestone, Alpha,
> has the following definition:
>
> "A complete website that has a functional pledging prototype using
> artificial money"
>
> Here's the thing. That's just a collection of user stories.
>
> 1. "As a registered patron, I can pledge artificial money to projects to
> see how the mechanism works"
>
> 2. "As a new, interested visitor, I am presented with visuals and
> explanations that help me understand what Snowdrift.coop is trying to
> accomplish."
>
> 3. "As a visitor, I can quickly sign up and become a registered patron"
> [but the visitor must be made sufficiently aware of the responsibility
> they are undertaking]
>
> 4. "As a viewer, I can always quickly get information about the
> organization running the website, and about policies pertaining to how
> I use the site"
>
> Do we need any more process and structure at this point? As long as we
> have structure for milestones and user stories, we have all the
> structure we need to make a lot of real progress. Let's add more
> structure retroactively, reflectively, once we see the clear and
> present need for it. In the meanwhile, I'm pretty sure we can write a
> lot more than four user stories! Let's write a bunch and see what we
> need next.
>
> _______________________________________________
> 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

Reply via email to