Topic: Reporting Sprint
Product Owner: Unknown User (mseaton)
Developer Lead: Unknown User (raff)
Known Developers Assigned (amount of effort in hrs dedicated to this work if possible):
Date: 1/9 to 1/23
- Unknown User (mseaton)
- Unknown User (raff)
- Unknown User (patandrea)
- Daniel Kayiwa
- Unknown User (wyclif)
How To Participate
The general process:
There are 3 primary goals we would like to accomplish during this sprint:
There is also a significant backlog of tickets, of all levels of complexity, suitable for new and experience developers to contribute.
- The ability to share all reporting metadata via metadata sharing
- The ability to expose patient data definitions and person data definitions as calculations
- Create a reporting module screencast for OpenMRS university
- Improve reporting module documentation organization and content
- Add a ScriptedCohortDefinition
- Any "Ready for Work" feature that is Ready for Work and is "Low" complexity
- Any "Ready for Work" ticket in the reporting module that is of type "Bug"
- Everything else
Kickoff meeting Date: 2012/01/09 after the scrum meeting
(Meeting setup with known developers after the final design meeting, but prior to the start date):
Kickoff Meeting Checklist
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 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
Tickets involved: https://tickets.openmrs.org/secure/RapidBoard.jspa?rapidView=15
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 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.
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.
During Project Notes
Add notes, comments, concerns, that occurred during the sprint that should be noted to help in the retrospective.
Post Project (Retrospective)
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?
- Kickoff meeting recording: During first part of Design call 1/9
- Rapid Board: https://tickets.openmrs.org/secure/RapidBoard.jspa?rapidView=15
- Repository Preview: https://github.com/openmrs/openmrs-module-reporting/tree/sprint-201301
- CI: https://ci.openmrs.org/browse/BUNDLED-REPORT0