Hello, all -

I have been working on and started organizing into a Work Package workflow
that I think will work for Snowdrift.coop.  I'd like to get your thoughts
and feedback on the layout as well as the proposed process.

Please note that, even if we decide to move forward with this proposal, I'm
most focused on what works best for the project and its members, so if we
find something that doesn't work for us, we'll tweak it.  I'm not expecting
this first pass to be deemed perfect for our usage, but I had to start with
something to get the conversation started.

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
   - *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
      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)
Discuss mailing list

Reply via email to