Understanding the Basics of Scrum, Part 2

Chris HolmokIn my last post I broke down the roles and tasks of the Scrum process.
Today’s post is part two of Understanding the Basics of Scrum, and will break down the events of Scrum and the role of the task board in the Scrum process.
The events of the Scrum process are as follows:
  • Daily Scrum: The daily Scrum is a daily meeting that should only last a few minutes. Based on the idea of the rugby scrum, all team members should be standing and facing one another. Each member of the team states the following: What I got done yesterday, what I plan on doing today, and any impediments. The purpose of these meetings is to assure that progress is happening and to alert the ScrumMaster if there are any impediments that need to be resolved.
  • Sprint: A Sprint is the length of an iteration, or how long the team has to deliver items on the Sprint backlog. It’s usually 14-30 days.
  • Sprint Planning: Sprint planning occurs prior to a Sprint. It is where items from the product backlog are broken down into tasks for the Sprint backlog and team members pick the tasks they want to work on for the Sprint.
  • Sprint Review: The Sprint review usually occurs after two Sprints. Everyone discusses what was accomplished during the previous Sprints, what went well, what did not go well, and what changes need to occur to improve the process.

The daily scrum is usually held in front of a task board. A task board is a section of a wall divided into a grid. It is divided from top to bottom by the product backlog user stories (features and such), and divided from left to right by the status of the task, usually something like the following: Committed/To-Do, In Progress, Testing, Complete. On this grid, team members move their tasks as the status of the task is changed. This approach gives anyone who’s walking by the task board a visual indication of what’s getting worked on and what’s getting done. The ScrumMaster also maintains a “burn down” chart on the task board that charts the rate at which things are getting done.

Now, to be honest, just about every place that uses Scrum uses it differently. Some rules are hard rules never to be broken at one company, and at another, it’s just a rule of thumb. That is the strength of Scrum, it is an adaptive process. It will evolve with a team depending on the team’s strengths and weaknesses. It is so adaptive that it’s not just for software development. It can be used in other venues, too, like marketing. Like many of the other processes, it is not perfect. But, here at Knotice, it allows us to produce customer facing features rapidly and create a flexible, stable platform to deliver them.

One Comment

  1. Posted August 20, 2012 at 1:35 pm | Permalink

    First-class post on Understanding the Basics of Scrum, Part 2 The Lunch Pail. It is really among the most helpful that I’ve looked at in
    a long time. I’ve been waiting for this information.

One Trackback/Pingback

  1. […] Knotice’s Scrum method helps us recognize that potential problems cannot always be completely defined or even flushed out, initially. The goal is to maximize the project team’s ability to deliver projects quickly and respond to incoming requests or changes, no matter when they are made. That process and approach makes project teams more productive, reduces mistakes, decreases development time, and delivers project on time. […]

%d bloggers like this: