My personal introduction to Scrum

When you are completely new in Scrum, it’s a good idea to read an introductory book or browse through Wikipedia. When you’ve learned about the Scrum roles and artifacts, it’s also a good idea just to start with what you’ve just learned. My experience was that the really interesting questions only arise when you actually do Scrum. I’ve done the same and like to share my three Scrum lessons with you:

Implement a process for continuous improvements. Scrum does this trick by strictly “time boxing”: Define some fixed repeating time frame and call it “sprint”. If you run into delay or failure, do not expand the sprint length. After the fixed time period, ask yourself what you’ve achieved and think about how to become better next time. Think about how you can measure your progress. The Scrum artifact for measurement is the burn down chart. If you’re a manager, do not look on it as a new fancy tool to control your team. It’s rather tool for the team to measure their progress and become transparent in what they’re achieving every day. Derive a target what you want to achieve in the next sprint. Find a person who’s responsible that the Scrum rules are obeyed, and call him Scrum master. He/she should do his/her job once a day in the daily Scrum, and you’ve done your first Scrum lesson.

Second lesson is to achieve a team’s commitment. In classical project management there is some project manager who’s going to plan the project. This requires making assumptions about uncertain information and forecasting the team activities. Who is the most able to do this? It’s the team who’s most able to do the detailed planning. Again “time boxing” will do the trick: The sprint length should be small enough that the forecast becomes more certain and the team becomes confident in their plan. If the team becomes committed to the sprint target, you’ve done your second Scrum lesson.

The third lesson is to introduce a Product backlog. The product backlog is an ordered list of all requirements – both functional and technical. Call these entries “stories”. Find the Product owner who owns the product backlog, i.e. has the authority to decide on the stories. At every sprint start, the team selects the top stories from the backlog, plans activities and chooses which part they can commit. This is called “pull principle”. The team should do the decisions late, such that the product owner can decide to rearrange the product backlog as long as possible. This makes the Scrum agile and completes the final lesson.