If you are considering hosting or having a sprint, please see How-To Have a Sprint for best practices
This page is out of date and does not reflect our current active sprints. Please check with devs on IRC (http://irc.openmrs.org) for now until we get this page updated with current information.
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.
- 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.)
- The sprint leader should give an 'estimated time' for each ticket in a sprint.
- Developer should log the total number of hours he/she spent on a particular ticket.
- 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.
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
(included from the Sprint Schedule page)