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

  • 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

  We'll start by experimenting with Skype and a dedicated IRC channel

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

  most things should be designed already though) If you go

  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

  that its

  you are going in the right direction

   

Schedule of Sprints

2011

Potential Sprints

...

(included from the Sprint Schedule page)