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)

1. Present the Sprint Topic on the Wednesday Design Forum

One Week From the Sprint (9 to 5 days before the sprint)

1. Identify the sprint tickets

   1. All tickets should be fully described for anyone to pick up and work on each ticket with minimal extra explanation

   2. There should not be any "Needs Design" tickets during a sprint.  EVERY ticket in the sprint MUST be fully designed before the sprint begins.

   3. Sprint leader is responsible to include adequate number of tickets that can be covered during a 2 week sprint period.

   4. Each ticket should have an 'estimated time' coded before the start of a sprint. 

2. Assign all tickets to a common release version (if not a module release, then usually named "Sprint 1" or "July 2011 Bug Fix Sprint")

3. Create a JIRA homepage

   1. Include appropriate charts, links to tickets. See the hl7query module sprint jira dashboard/homepages for examples

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

      2. The version used for your sprint must have a start date defined in greenhopper:

         1. Go to the chart board for your project

         2. In the yellow version box on the right you should see a startDate option.  Set that to the first date of the sprint.

            1. If you can't see the startDate, click the "toggle visibility" link in the config options

         3. Set the end/due date to be either the end of the sprint or a week after to give time for followups

      3. Create the new filters for the sprint dashboard widgets

         1. Edit each widget to have filters pointing at the right jira project and fixVersion

         2. Search for the filter by name. See https://tickets.openmrs.org/secure/ManageFilters.jspa#filterView=search

         3. Click through to it, then choose "edit" in the left column

         4. Change the project and fixVersion in the search query box and search

         5. Click "Save as new" in the left column

         6. Enter the name and be sure to add "Public" as the view permissions

4. Creating a JIRA homepage (alternative to 3.)

   1. Go to https://tickets.openmrs.org/secure/Dashboard.jspa?selectPageId=11755

   2. Tools -> Copy Dashboard

   3. Issues -> Manage Filters

   4. Search for "Event / Atom Feed"

   5. Open one by one and:

      1. Create new filter from current

      2. Edit -> Adjust the query -> Search -> Save

   6. Go to the new dashabord

   7. Repeat for each box:

      1. Click arrow in the top-right corner -> Edit

      2. Search for the right filter in the Quick Find input

      3. Save

5. Email the community about the sprint which should include the following information

   1. Dates of the sprint

   2. Goals of the sprint

   3. Daily scrum meeting time

   4. Who the sprint leader is along with IRC name

During the Sprint

1. The leader should stay present in #openmrs throughout the sprint.

2. Do reviews as soon as possible. Reviewing should not be put off because of the possible feedback cycle and needing more work done.

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

1. Email the community about what is finished, what is left to do, etc.

   1. Communicate to the community what unfinished items can still be worked on by the team

5-7 Days after the Sprint

1. 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:

1. Writing Code

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

      1. It is sometimes worth writing less code to ensure that committed code is correct semantically

2. Managing Time in IRC and Email

   1. Make small amounts of time to ignore email and IRC to work on coding (i.e. 20-30 minutes)