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:
- What did you do yesterday?
- How much time is left on your tasks?
- What are you going to do today?
- 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 |
|
| Tasks and Estimates |
|
| Resource Allocation |
|
| 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).
continuously i used to read smaller articles or
reviews which as well clear their motive, and that is also happening with this piece of writing which I am reading
at this time.