Are you planning on having a sprint on OpenMRS or an OpenMRS-related project? Here's a short list of best practices (conventions) useful for sprints in the OpenMRS Community:
How to Announce a Sprint
- Make a new topic on OpenMRS Talk (usually under the development category)
- Choose a brief, meaning title, like "Foo Bar Sprint Announcement"
- Be sure to include the
sprint-announcementtag on your post.
- Include overview, start & end dates, objective(s), link to issues, and how to join
Creating a Sprint in JIRA
- Search the list of Agile Boards on issues.openmrs.org for your project. If there's already a board for the project, you can go to its backlog view and select/create tickets for your sprint.
- If the project doesn't have an Agile Board, create one and then create a sprint within it. The typical convention is to just number sprints (e.g., if you are having a third sprint on the "Foo Bar" board, then it would be named "Foo Bar 3").
- Alternatively, if your sprint is hosting a list of tickets/cards outside of OpenMRS JIRA, then make sure to provide a link to a public view
Creating a Sprint Wiki Page
Create a sprint Wiki Page defining the Following
- Clear goal of the sprint,
- Sprint Time line
- Sprint Lead and Technical Lead
- Participating team members
- Sprint jira Dasbord and board links
- See example Upgrade Core Libraries Sprint
Sprint Kickoff Meeting
A sprint kickoff meeting is best practice in hosting a sprint. The goal is to get everyone on the same page in terms of background & objectives, answer any questions, and get people motivated to participate. Ideally, you give people at least a few days notice of when & where the kickoff meeting will take place. It can be on IRC, in Telegram, in Uberconference, in a Google Hangout, on Skype, or whatever works for you.
- Announce the kickoff time & place (ideally at least a couple days beforehand) either in your sprint announcement on Talk or in a reply to that post.
- Start the kickoff by giving some background. Why are you having the sprint? Review technology or terminology that may not be familiar.
- Review the objective(s) of the sprint.
- Make sure people know where to find tickets and how to claim one.
- Make plans for any daily standups or other forms of communication during the sprint.
- Let people know where to go with any questions.
Open source and agile development teams thrive when people take the time for retrospectives. We routinely have these at our hackathons and meetings, since the information gained from a retrospective inevitably helps improve things going forward. Usually we ask three questions (in order):
- What did you expect to happen?
- What actually happened?
- What should we do differently next time?
Make sure people spend a few minutes on each of these, try to get everyone to contribute their thoughts on each, and take shared notes as you do it. At the end, don't forget to celebrate everyone's efforts.