If haven't already, start with Part 1: Planning & Poker.
In our planning session we figured out all of the stories and tasks we need to complete in the next two weeks. The project manager will create an index card for each task which include the task title, hours remaining, and hours spent. He will place these tasks on a scrum board. There are a variety of ways to setup a board, we typically use a row for each story and populate the columns with "TODO", "IN PROGRESS", "TO VERIFY", "COMPLETED". On the first day of the sprint, all of the tasks will be in the TODO column.
Every day, at the crack of 9:15 we meet in front of the scrum board to have our Daily Scrum. If you are late, you either pay a dollar or get to sing 'I am a little tea-pot'. On the first scrum meeting we won't have much to report. Instead we will pick a couple tasks and move their index cards from the TODO column and place them into the IN PROGRESS column. On the remaining meetings each person will start by reporting what they did on the previous day. They will mark off the hours they spent on the task and update the estimated hours remaining. If a task has 6 hours on it and you spend 4, that does not necessarily mean you will write 2 hours remaining. Instead you write whatever you think it will take... Maybe you are rocking it and it will just take 1? Or maybe you have the lovely experience of uncovering a bug and decide it will take more time than you initially estimated... who knows. But it is important to keep the estimates up to date in order to measure our progress. Plus, if something is taking too long, it will be immediately obvious that something needs addressed.
If you finish a task you will mark the remaining hours down to 0 and place the card in the "TO VERIFY" column. Tasks are not verified until someone else has either read your code review and/or tested the feature (if it is something you can test). If someone can vouch that it is verified, then you can move it to the COMPLETED column (and there is much rejoice). On the flip side, someone may point out something is borked and you will need to move the task back to IN PROGRESS and update the estimated hours.
This meeting should not take more than 15 minutes. Afterwards, the project manager will calculate the total hours remaining and will print out a scrum burn down. A scrum burn down is a line graph showing two values. One is the budgeted hours remaining which is represented by a straight line going from the top left to the bottom right. If you had 40 hours on a 5 day sprint, it would have 40 on day one, 32 on day two, 24 on day 3... etc. The second line on the chart is the estimated hours remaining. Lets say on day one you completed a 10 hour task in 8 hours. Therefore you would have an estimated 30 hours remaining on day two. This means your estimated hours remaining would dip below your budgeted hours remaining (32). On the flip side, lets say you spent 8 hours on your 10 hour task and think there is still 4 hours remaining. This means you estimate there are still 34 hours remaining instead of the alloted 32 and your estimated line will jump above your budgeted line. A picture is worth a thousand words, so please take a break from reading my rambling about numbers and lines and check out the example images on google for a scrum burn down.
So what does this mean? Well, its easier to figure out than a double rainbow, if the line starts to dip well below the budgeted hours, then we will grab some backlog stories (stories that we were going to tackle next sprint) and add them to the board. On the flip side, if we see the line slowly going up away from our budget, we know we need to put in some extra hours. If things get bad, we can make arrangements to work over the weekend in order to get our estimated line back on track with the budgeted line.
At the end of the two week sprint our estimated hours remaining should be 0 and all stories complete. However, if something didn't quite make it, it will have to be addressed in our planning session and carried over to the next sprint.
That wraps up the daily scrum. I'll post my thoughts on the pro's/con's in the near future.
