Development Sprints

The OpenMRS core development team uses the a semi agile sprinting mechanism for getting features written in a coordinated fashion. This allows new features to move forward at a quick pace. It also distributes the knowledge of different features to a wider audience.

Anyone interested in joining a sprint should let either the sprint lead know or just send a general request to be on one to the dev list.

Sprint Details

• Sprints are focused on one topic, and are usually 2 weeks long
  • some could be 1 or 3 weeks long as appropriate for the topic at hand
• Each sprint should include 2+ OpenMRS developers. We may occasionally have multiple sprints going simultaneously
  • not everyone needs to be assigned to every topic.
• We will schedule and publicize Sprint topics ~4 weeks in advance
  • this will give developers at other organizations a chance to organize their time to participate
• Sprints should always have a release in JIRA, unless they're around a core topic like "work on 1.9 tickets", in which case we'll use a "label" in JIRA.
  • Tickets in the release should be partially organized one week before the sprint.
  • They must be finalized by the day before the sprint. (The scope and tickets are locked-down once the sprint begins.)
• Each Sprint has a leader, who is in charge of the ticket list, and can help assign tickets to participating developers.
• All developers working on a Sprint should be in a real-time group chat in our IRC channel
• To keep improving, each sprint ends with a retrospective look at what did and did not work with the previous week.

Weekly Emails

You should expect to see an email from Ben and Darius every week which will:

• (either) summarize the status of the current Sprint
• (or) summarize the retrospective look at the last Sprint, and preview the next one
  • this includes highlighting the developers and organizations that are participating in the Sprint
• give the calendar for upcoming Sprints

Designing a Sprint

These are required features that must be in place before a sprint can be started (or maybe even to just be scheduled)

• Must have a leader assigned
• Must have X tickets for the sprint designed, not just created
  • New developers should be able to pick up the ticket and know what needs to be done
  • Each ticket should list the proposed solution in its description, or in a comment with the text "Proposed Solution".
• Must have an outcome / release for the end of the sprint
• Must have a sprint page created

Being a Sprint Leader

See the Being a Sprint Leader page

During a Sprint (for developers)

• You should not have to spend a large amount of time designing out a feature. (It should already have been designed before being included in the sprint.) If the design for a ticket is unclear, ask.
• If you spend, or expect to spend, more than 6 hours on a ticket/feature, bring it up to the group to make sure you are going in the right direction

Schedule of Sprints