How To use This Page
Blue headers take you through the steps of your project. (Prior to design, Design, Kickoff Meeting, During, and Post Project Wrap up)
Information 
show areas where you need to fill out information to have a successful project, most information is optional, but the more you fill out the easier it is for others within the community to help.
Ask Kiran Reddy or Chris Power for help if you have any questions.
Tasks To Be Completed Prior To Design
Type of Project (Spike, Sprint, Epic):
...
Sprint
Goals
Goals: Must Have, Should Have, Could Have and Won’t Have
Must Have means we must have this as part of the solution. It is a requirement or we should rethink doing this work. This is what we will deliver before the end of the work period this this also doubles as our DOD “Definition Of Done”
...
Could have means anything else we could do. But this does not always mean low priority. But our selection of which could haves to include or exclude (or deliver later). Also is considered low hanging fruit (if we are in this code already for x reason we can deliver y with for x reason wecan deliver y with little or no extra effort) or can be items or ideas for this module that can be packaged for a later spike or sprint.
Won’t Have means this will not happen. It might be technically impossible, a taboo for our organization or out of scope. It does not mean “might happen or would be nice”.
| Info |
|---|
Must Have: Should Have: Could Have: Won’t Have: |
General Info
| Info |
|---|
Topic: |
...
Visit Scheduling |
...
or Queueing Lead (Product Owner): |
...
Tobin Known Developers Assigned (amount of effort in hrs dedicated to this work if possible): Date: |
...
TBD |
How to Participate
Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.
...
These are a combination of parent tickets with child tickets underneath to break up the work or tickets needed for completion of the work. These tickets should be made in as much detail as possible going into the design calls through use of the mail groups mailgroups and small group design meetings. Larger design calls will be used to answer questions these groups cannot or for the community to resolve.
All tickets should have in their description a DOD (Definition of Done) or what it should have accomplished
| Info |
|---|
Tickets involved: |
Design
There should be multiple design meetings. The first starts off with a small group working with the leader to determine the high level scope of the project and then to break down into smaller pieces to eventually place as tickets. Once those meetings have happened havehappened use of the community design meeting time should be used to refine the tickets and if possible assign them to who will be doing the work.
| Info |
|---|
Risks (these should be resolved prior to or during the design meetings): Enter anything that is still questionable or worrisome that has not been answered: (open issues, potential concerns) Once a decision is made make sure that a summarized answer is included. Example: Q. How will we handle issues with conflicting userID’s? |
...
A. All ID’s will have an added identifier that is unique. Effort Accounted For: (At the end of the design call all tickets should have an estimated effort and that total should be balanced against the known available effort of the developers assigned) (Yes/No) If not in balance in favor of success why and the action plan for remaining items |
...
|
via IRC on
...
the #openmrs
...
channel on freenode.
Use this channel
...
for ALL
...
debugging and random questions having to do with the sprint. Please avoid direct messaging to personal contacts. If you have a question, someone else most likely does too, and our geographically distributed community
...
benefitsfrom public group discussion.
Kickoff Meeting
Kickoff meeting Date: TBD TBD
(Meeting setup with known developers after the final design meeting, but prior to the start date):
| Info |
|---|
Kickoff Meeting Checklist
|
During Project Notes
| Info |
|---|
Add notes, comments, concerns, that occurred during the sprint that should be noted to help in the retrospective. |
Post Project (Retrospective)
| Info |
|---|
Did we complete tickets to a 100% DOD? (Yes/No) if no, have those tickets been assessed and placed for future work if needed? What did we do well? What could we do better? What should we not do again? |
Resources
...
Kickoff meeting recording: ??