Page Comparison

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

  , as

  • not everyone needs to be assigned to every topic.

• We

  should always try to decide on a sprint topic 4 weeks before it starts.Each sprint should

  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

  . The tickets

  , 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.

Schedule

2011

May

• 2nd - 16th: a module focused sprint

April

• 25th - May 2nd: Core bug fixes
• 11th - 24th: 1.9 Tickets
• 4th - 10th: Learn to use the 2.x UI Framework by building patient dashboard fragments. Lead: [Darius Jazayeri|~darius]

March

...

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

(included from the Sprint Schedule page)