Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Before the meeting, create a list of candidate tickets for your release.  For 1.7, we were using Trac and made a simple list of tickets; however, we might want to experiment with GreenHopperTickets from the JIRA backlog and those not completed in the previous release.  Essentially, any ticket assigned to the release or not assigned to any release is a potential candidate.
     
  2. As a group, review all of the candidate tickets marking their priority as Must, Should, Could, or Won't.  This needs to be done quickly (e.g., at a rate of one per 30 seconds per ticket or faster) to get through the list.
     
  3. Sort the tickets by descending priority and decide which ones will go into the release.  Typically, this will be all of the "Must" priorities, most of the "Should" priorities, and few if any "Could" priorities.
     
  4. Select ten minor/trivial tickets (these should be in the "Could" priority) to be included in the release.  For 1. 7, ?Former user (Deleted) created a list of the "Could" tickets and presented them to the community, allowing the community to help pick then ten minor/trivial tickets to be included.  This process should be limited to 1-2 weeks.
     
  5. Return to this page and edit it to add/remove/revise its content based on your experience with the meeting, since (hopefully) you learned how to do things a little better than we did for the prior release and updating this page will ensure that future release managers benefit from your new found wisdom.