This is how we Scrum – The Daily Scrum

A picture of three monitors is worth a thousand words.

For our daily Scrum, we gather around my computer at 1:15pm.  I dial in to a pre-arranged phone conference and setup my monitors to display key information about our project.

The left monitor displays our sprint burn down chart.  The middle is a video feed of our remote contributors.  The right monitor shows our sprint task board.

We have two people on the phone.  They are two members of our QA team located in Tucson.  The video feed is an Office Communicator video conversation with the audio turned off.  We use the phone conference instead of the webcam microphone because is much clearer and allows local team members who are working from home to dial-in and participate in the stand-up.

We host the burn down & task board on a SharePoint site so that anyone working remotely has access to the data.

We repeat this arrangement for each daily Scrum in our sprint.

This is how we Scrum – The Planning Meeting

From storming to performing.

After reading and responding to questions by people who are curious about Scrum and want to implement it, I thought I would write my teams experience with Scrum, starting with the planning meeting we had today.

Here is a little background about our project:

Project length:	1 year
Size of the team:	8: 3 QA, 3 engineers, 1 team manager, 1 project manager.
Fixed release date:	2nd half of 2009.  Sorry no specifics 🙂
Sprint length:	2 weeks.  Monday = planning.  Friday = demo & review
Length of the planning meeting:	1.5 hours.  Used to be 3.5 hours, but over time the daily stand-ups keep us informed and reduce the need to discuss the tasks in detail.  The prioritized backlog also helps us focus on a few subjects at a time)
Who attends:	Everyone attends the planning, stand-up, demo, & retrospective meetings.

Here is how our planning meeting progressed:

1. The team manager gives a project status overview.
   • What does our product burn down chart look like?
   • Are we on track?
   • Are there any upcoming external influences on the project?
   • Some light discussion on how we interpreted the Product burn down.
2. We then capture the teams availability using half days as our unit of measure for the next sprint within an Excel spreadsheet.
3. Then we review any tasks that were not completed last sprint.
   • What are the next steps for these tasks?
   • Do we need to add tasks to the sprint to complete them?
   • Should they be moved to a future sprint?
   • Assign the tasks to team members, estimate the days to complete them, and reduce the appropriate team members availability for the remaining tasks.
4. Look at the next highest priority item in the product backlog.
   • Create and assign tasks to work towards completing that item.
   • Estimate and reduce the available time of the appropriate team members.
5. Repeat step 4 until each team member is fully allocated for the sprint.
6. Now we break and begin working on our tasks.