Scrum for Managing Projects

November 10, 2010

What is Scrum?

I must admit, at the beginning of the semester I had never before heard of Scrum. So, let us begin where I began. Wikipedia defines Scrum as “an iterative, incremental methodology for project management often seen in agile software development.” It is a framework that defines certain roles, activities, and artifacts. Scrum was originally intended for software development projects, but it appears to be quite effective for just about any type of project. Scrum provides a method for getting things done, measuring progress, and allowing improvements as you go. It is actually a fairly simple and intuitive concept, which is probably why it works so well.

The People

With Scrum, we basically have three different roles.

The first role is the product owner. The product owner represents the customer and the users. The product owner gets the ultimate say on what the product is actually supposed to do.

Next, we have the ScrumMaster. The ScrumMaster is a bit like a project manager. He or she takes care of the team and makes sure that things are flowing smoothly.

Speaking of the team, the team is the third and final Scrum role. The team consists of a self-organized group of folks that turn the product owner’s wish list into a reality.

The Artifacts

Being a software engineer, this is probably my favorite part of Scrum. I say that because I am highly allergic to writing documentation. There are three basic types of artifacts in Scrum: the product backlog, the sprint backlog, and the burndown chart. That’s it. No huge requirements document or design document to waste valuable development time.

The product backlog defines what the product is going to do. It is the “wish list” of the product owner. Each item in the product backlog is assigned a priority.

The sprint backlog is a subset of the product backlog. To fully understand the sprint backlog, we must first understand the sprint itself. A sprint is an interval in which a potentially deliverable “chunk” of the product is created. This interval can last anywhere from a few days all the way up to four weeks. It will take several sprints to produce the final product. So, the sprint backlog is the subset of the product backlog that is to be implemented during a specific sprint. It is broken down into tasks and contains time estimates for each task to be completed during the sprint.

The burndown chart is what keeps the project on its toes. The burndown chart shows the daily progress of the team and provides a clear understanding of the work remaining. It is not uncommon to have a burndown chart for each sprint as well as an overall burndown chart for the full life of the project.

The Activities

Scrum is cyclical. Each cycle includes four important “ceremonies”.

The cycle begins with the first ceremony, sprint planning. During sprint planning, the Scrum team gets together with the product owner and they all choose the features from the product backlog that will be implemented in the upcoming sprint. During this time, team members choose the tasks they wish to work on and provide time estimates for completing the tasks. This is where the sprint backlog is born.

The daily Scrum is a quick daily meeting where the ScrumMaster and the Scrum team review the events of the last 24 hours. The team updates the ScrumMaster on their status and makes the ScrumMaster aware of any “impediments.” The ScrumMaster will usually ask three ceremonial questions. “What did you get done during the last 24 hours?” “What are you going to do during the next 24 hours?” “Are you encountering any roadblocks?” During the daily Scrum the burndown chart is updated and any necessary adjustments are made to the sprint backlog. In my opinion, the daily Scrum is probably the most important Scrum activity. It is what keeps the work flowing and the project on schedule.

When the sprint is over, we have the sprint review. This is a meeting where the team shows the product owner what they have (and what they don’t have). Project level adjustments can be made at this time.

After the sprint review, the team has an internal meeting called the sprint retrospective. At this time, the team reflects on what worked well and what did not work well, making adjustments where appropriate.

After the sprint retrospective we go back to sprint planning. The cycle repeats until the project is over.

Wrap Up

Scrum is awesome. If you are interested in getting things done, staying on schedule, allowing flexibility, and making the customer and the workers happy, Scrum is definitely the way to go.

By: Anthony Huffstetler

References:

1. http://en.wikipedia.org/wiki/Scrum_(development)

2. http://www.scrumalliance.org/pages/what_is_scrum

3. http://www.codeproject.com/KB/architecture/scrum.aspx#Introduction0

4.

2 Responses to “Scrum for Managing Projects”

  1. Phil Stafford said

    Well done Anthony. I really like the Video. I feel like I just had a 10 minute Scrum class.

  2. Kimberly Williams said

    I really enjoyed reading your blog, it was very educational, and I also liked the video. Within my group at IEM we have study Scrum project management and have applied it to our current project. It has worked very well for us and I would suggest scrum usage to be a very efficient and effective way to manage a successful project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: