My Daily Scrum Routine

Headline: This describes my daily routine as I participate on a virtual team scattered about the globe as we work on a project using the Scrum template.

The Situation

Currently I’m working with a team where no two people are in the same time zone!

We’re using Visual Studio Online (VSO) with the Scrum process template. We also use Visual Studio for our IDE (Integrated Development Environment). The tools are actually quite helpful for virtual teams. I point that out as I describe my daily routine.

Clear Things Out

There are all the non-development tasks. I try to clear those out of the way first. Handle the email on various topics it probably the biggest thing. Then I’m ready to begin.

Visit the Team Room

VSO has the concept of Team Rooms now. I wish I could filter out certain messages about people entering and leaving, but I still find the room valuable. This is where we each do our Daily Standup. Since we’re are scattered all over the globe there isn’t a good time for us all to talk in person each day. So instead, we write out a slightly modified version of the daily standup. Most do “what I did yesterday” and “what I plan to do today” since the daily standups tend to be in the morning.

We modify that and do it at the end of our day stating:

1. What I did today
2. What I plan to do tomorrow
3. Blocking issues

We move pretty fast and by doing it at the end of our day, then the people in the other time zones have the benefit of what we did as soon as we completed it rather than waiting until the next day.

I visit the room at the beginning of the day to read everyone’s daily standup information. That allows me to not work on something if they are and also let’s me get an early start on resolving blocking issues (since I’m sort of the Scrum Master).

Visit the Task Board

In my last post I showed an image of the task board. Each row is either a PBI (Product Backlog Item) or a Bug that the team committed to do in this sprint. These are all in priority order.

Then there are three columns:

1. To do
2. In progress
3. Done

At the beginning of the day I have no tasks in the In progress column, all are either To do or Done. I start at the top of the PBI/Bug list and work my way down. I look for a story I can really help with and prefer items at the top of the list over those further down. Sometimes I don’t have the skill or others have a story handled so I work my way down the list.

I then think about the day and perhaps a few more ahead. If tasks don’t exist yet I’ll create them. I’ll try to make sure that I have at least enough tasks for today. I want to change this so that we have all the tasks identified at the beginning of the sprint, but we’re just not there yet. I also try to break the tasks down into something that can be done in less than a day. I hate having a task go between To do and In progress for days on end.

Next I drag over the Task I plan to work on next and begin.

Develop

Now the fun begins! I strive to do test driven development, but it doesn’t always happen. But I work on the task until I have it done.

Definition of Done

On thing that is important is the Definition of Done. My current project is still ramping up so we don’t have everything “done” just yet, but I think we’ll get there soon (this month). Here is my definition of done for developers on the team:

• New code has unit tests
• There are no code analysis warnings using the Microsoft All Rules
• All public members have XML documentation (///<summary> type)
• There are no strings in the code – they are all in the Resources file.
• The code builds
• There are no failing unit tests
• When the code is checked in it is associated with 1 PBI and 1 Task
• The CI (Continuous Integration) build was successful (built and had no failing unit tests)

Now there is a broader definition for the team regarding, “Is the PBI done?” Usually the story is sufficient, but many times we discover something someone didn’t think about up front. These might become new PBIs.

Iterate

Once I check in code, I go back to the task board again, drag something into the In progress column and keep moving.

Close Out The Day

At some point I’m ready to call it a day. I will do this after a check in. I never leave code sitting on my machine overnight. Venkat Subramaniam taught that in a course he taught in 2008. He said if you don’t check it in at night (and it better be good), then delete it all the next day and start again. I’ve been practicing that since then and it’s really help. The day I liked the most was when I spent 9 hours the day before and probably had 800 lines of code. I threw it all away and that day I realized I could do it with about 70 lines of code! The day before just taught me what the real problem was and once I knew it the solution was quite simple.

When I check in, I always associate that with one PBI and one Task (see my previous post).

Next I visit the task board and move any In progress tasks either to Done (but the check in process usually moves those) or more likely, back to In progress.

The final step is to go into the Team Room and write my Daily Standup Report.

When things are moving well (See Super-sonic Software Development) it’s not uncommon for me to have 3 to 6 check ins per day.