What Worked (surprisingly) Well – Sprint Tracker in Source Control 1


This past sprint retrospective the team proposed that we change up the way our scrum team reports on task progress.  The team proposed that we keep our Sprint Tracker excel document in source control.   Then prior to the daily standup meeting each team member would check out the document, update the time remaining on their tasks, and check it back in.

I am surprised at how well this worked!  I was expecting that nobody would participate or somebody would forget to checkin and then go on vacation or any number of possibilities.  But I’m proud to report our standups are more effective and efficient because we spend more time to discussing what was done, what to do and what things are standing in the way.

Let me try and explain in more detail.

What did you do before?  Before each daily standup I would email the  sprint tracker to the team.  Then we would walk down the task list and each team member would speak to:

  1. What did you do yesterday?
  2. How much time is left on your tasks?
  3. What are you going to do today?
  4. Is there anything standing in your way?

What is the Sprint Tracker?  The Sprint Tracker is a 6 tab excel document I pieced together from various other sources and concepts.  Here’s a table that outlines each tab and its purpose.  We populate this document during each sprint planning meeting.

Tab Purpose
Release Overview
  • Track release # and release objectives
  • Call out # of sprints to achieve release objective
  • Call out goals and dates associated with each sprint
  • Indicate what sprint we are on and which sprints have been completed
Tasks and Estimates
  • Sprint task list
  • Original Estimates (in hours)
  • Progress along the way (in hours remaining)
Resource Allocation
  • Resource name
  • Commitments levels
  • Task hours remaining
  • Estimated and Actual velocity
Burndown Chart Plot remaining hours against desired trend line automagically
Sprint Information All the formulas to generate the resource hours remaining and plot the burndown chart

What are you doing now?  Now I check the sprint tracker into source control after the sprint planning meeting.  Then each day the team members check out the tracker, update their task remaining hours, and check it back in.  This effectively removed question #2 from above.  And I didn’t realize how much time that would save!

One thing to mention that if someone doesn’t update the document (and doesn’t have a good excuse) then we either A) Publically humiliate the team member who forgot to update the document or B) the offending team member has to buy donuts.  Each of these methods has pros and cons.  But the most important part is to try and keep it fun because scrum masters catch more flies with honey (or they get developers write more code with donuts).


Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “What Worked (surprisingly) Well – Sprint Tracker in Source Control