Release Prioritization Meeting

One of the key early steps in planning a release is to decide which tickets will be included.  As of OpenMRS 1.7, we began a process to select tickets by quickly prioritizing them as well as selecting ten minor/trivial tickets to be included in each release.

The Release Prioritization Meeting requires at least a quorum of core developers who can help prioritize existing tickets.  Briefly described, you gather a list of all candidate tickets for your release and then quickly run through them assigning a priority of Must, Should, Could, or Won't to each one, sort them by this priority and decide on which tickets will make the release.  Then ten minor/trivial tickets are selected to be included in the release (to help avoid minor tickets from getting eternally kicked to the next release).

Prioritization Recipe

1. Before the meeting, create a list of candidate tickets for your release.  Tickets 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. 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.