Being a Sprint Leader
The leader of a sprint is responsible for designing and running the sprint. The leader must choose/describe the tickets in the sprint and completes (or at least coordinates) reviewing of the code submitted during the sprint.
Qualifications
Knowledgeable on the sprint topic
Able to respond to questions about the topic
Fully available throughout the sprint
Responsibilities of the Sprint Leader
Pre-Sprint Tasks
Two Weeks From the Sprint (17-10 days before the sprint)
Present the Sprint Topic on the Wednesday Design Forum
One Week From the Sprint (9 to 5 days before the sprint)
Identify the sprint tickets
All tickets should be fully described for anyone to pick up and work on each ticket with minimal extra explanation
There should not be any "Needs Design" tickets during a sprint. EVERY ticket in the sprint MUST be fully designed before the sprint begins.
Sprint leader is responsible to include adequate number of tickets that can be covered during a 2 week sprint period.
Each ticket should have an 'estimated time' coded before the start of a sprint.
Assign all tickets to a common release version (if not a module release, then usually named "Sprint 1" or "July 2011 Bug Fix Sprint")
Create a JIRA homepage
Include appropriate charts, links to tickets. See the hl7query module sprint jira dashboard/homepages for examples
Burndown Chart: To enable, you must have the jira project set up in Greenhopper. This must be done by an IT admin. Open an ITSM ticket to request it be done for you.
The version used for your sprint must have a start date defined in greenhopper:
Go to the chart board for your project
In the yellow version box on the right you should see a startDate option. Set that to the first date of the sprint.
If you can't see the startDate, click the "toggle visibility" link in the config options
Set the end/due date to be either the end of the sprint or a week after to give time for followups
Create the new filters for the sprint dashboard widgets
Edit each widget to have filters pointing at the right jira project and fixVersion
Search for the filter by name. See https://tickets.openmrs.org/secure/ManageFilters.jspa#filterView=search
Click through to it, then choose "edit" in the left column
Change the project and fixVersion in the search query box and search
Click "Save as new" in the left column
Enter the name and be sure to add "Public" as the view permissions
Creating a JIRA homepage (alternative to 3.)
Go to https://tickets.openmrs.org/secure/Dashboard.jspa?selectPageId=11755
Tools -> Copy Dashboard
Issues -> Manage Filters
Search for "Event / Atom Feed"
Open one by one and:
Create new filter from current
Edit -> Adjust the query -> Search -> Save
Go to the new dashabord
Repeat for each box:
Click arrow in the top-right corner -> Edit
Search for the right filter in the Quick Find input
Save
Email the community about the sprint which should include the following information
Dates of the sprint
Goals of the sprint
Daily scrum meeting time
Who the sprint leader is along with IRC name
During the Sprint
The leader should stay present in #openmrs throughout the sprint.
Do reviews as soon as possible. Reviewing should not be put off because of the possible feedback cycle and needing more work done.
Sprint leader should check if the developers are logging the time spent on a particular ticket accurately.
Post-Sprint Tasks
1-2 Days after the Sprint
Email the community about what is finished, what is left to do, etc.
Communicate to the community what unfinished items can still be worked on by the team
5-7 Days after the Sprint
Present sprint outcomes on the developers forum
Time Management Tips
Here are a few time management tips from past sprint leaders to help find a balance between managing the sprint and writing code:
Writing Code
If you effectively direct, manage, and communicate with the team about writing code, that will should result in more work being done than if the sprint leader tries to write the code on his/her own
It is sometimes worth writing less code to ensure that committed code is correct semantically
Managing Time in IRC and Email
Make small amounts of time to ignore email and IRC to work on coding (i.e. 20-30 minutes)