| Note |
|---|
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.
...
- 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.
...
(included from the Sprint Schedule page)
| Include Page | ||||
|---|---|---|---|---|
|