Introduction to Scrum

Scrum is an software development methodology from the family of Agile methodologies.

It’s main focus is on project management as opposed to software engineering principles.

Scrum accepts that the requirements cannot be fully understood or defined at the start of a project, recognises that unpredicted challenges often arise and allows customers to change their minds about what they want and need during the lifecycle of a project and focuses on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

Scrum has been widely adopted in many global IT companies as their software devlopment methodology of choice including Yahoo!

There are 3 types of people in a Scrum team:

1. The Product Owner (responsible for identifying work to do, could be the client or more likely someone in the organisation that knows the client’s business well)
2. The Scrum Master (similar to a traditional project manager, keeps track of progress and removes impediments for the production team)
3. The Production Team (who do the work)

The Product Owner maintains the Product Backlog, which is a prioritised list of all the Stories for a Product.

The development iterations are called Sprints, can last anything from 1 to 4 weeks.

At the start of each one, in the Sprint Planning Meeting, the team identify which stories from the product backlog, they will commit to this sprint, and therefore go on the Sprint Backlog.

Each story on the product backlog has an estimated Effort, which should be based on the number of Ideal Hours it would take to achieve a task without interruptions or things going wrong.

The amount of work you plan to do in the next sprint should be your scrum team’s Velocity, which can be the number of ideal hours of the 100% completed stories achieved in the last sprint, or to iron out any anomolies, you can use the average over the last 3 sprints.

Although change is welcomed, it must go into the product backlog rather than the sprint backlog, which remains fixed for the duration of the sprint.

During the sprint, the production team work on the sprint backlog. At the start of each day, at the same time and place, the scrum team have a 15 minute Scrum or Daily Standup (meeting, but stood up to encourage brevity) in which they state:

1. What they did yesterday
2. What they are doing today
3. What are their impediments

The scrum master notes the impediments and works on removing them, and monitors the sprint progress through mean of a Sprint Burndown Chart which plots the “time left on stuff to do” (vertical axis) over “days in the sprint” (horizontal axis).

The activity and state of stories during a sprint can be monitored at a glance using a wall chart like the following:

…where stories on index cards or post-its are stuck in the various cells.

Production team members should focus on one story at a time to minimise Work In Progress, but note some stories may be blocked by 3rd parties.

Reviews can mean Code Reviews which involve getting someone to look over your shoulder, checking the code quickly before committing to your version control system. Or design reviews.

As soon as a member of the production team has finished a story and had it peer reviewed, they alert the QA it’s ready for testing and move on to the next story. If the QA identifies an issue, they alert the relevant member of the production team, who at their next convenient stopping point, fix the issue before continuing with the next story.

At the end of each sprint, the objective is to have potentially shippable software and, over 1 day, preferably mid-week:

1. The production team demo the work to the Product Owner (1 hour)
2. The scrum team do a retro-spective examining what worked well and what didn’t, identifying problems and changes and/or solutions (1 hour)
3. The scrum team agree what to do in the next sprint (3 hours)

If you don’t identify bugs until the end of your sprint, fix them first in the next sprint before embarking on the Sprint Backlog. Since your velocity is a measure of work done, and work is not done if there are bugs, your velocity and therefore work achievable in the next sprint will reflect this.

To keep track of progress over the project the scrum master maintains a Product Burndown Chart which plots the “time left on stuff to do” (vertical axis) over sprints (horizontal axis).

Consider making the day before the sprint review/planning meeting an R&D day whereby production team can work on stuff to improve your processes/systems or develop reusable features that can be used in future projects. Then, whilst the QA is testing your sprint work, if they identify any bugs you can fix them before the demo the next day, then get back to R&D if you have time.