Heard the buzz about Scrum and want to learn more? Want to get a sense of what it is and why some teams choose to use it? This was originally written as a presentation for BarCamp2 in Ottawa. With only forty minutes to present and discuss, I had to boil my description down to an absolute minimum.
Advantages of Scrum – frequent releases means the customer always knows where the project is going and is able to make simple course corrections. Burndown charts and the product backlog provide the product owner and other stakeholders continuous visibility on the projects status.
Scrum is an agile process that allows self organizing teams to focus on delivering the highest business value in the shortest time.
Using iterative development, it allows us to rapidly develop and repeatedly inspect working software every two to four weeks (a sprint or iteration).
At the end of the every sprint, anyone can see real working software and decide to release it or continue to enhance it.
- Used to determine the work for the next sprint
- A prioritized list of everything needed or wanted for the entire product
- Often written in the form of user stories
- Have estimates associated with them (often Story Points – Clinton Keith has a good explanation here)
- Examples: A company can pay for a job posting with a Visa card; A company can pay for a job posting with a MasterCard (from here)
- List of tasks that are to be completed in a sprint
- The tasks are created by breaking down the stories during the planning meeting
- Have estimates (often in hours) associated with them
- Creates and prioritizes the product backlog
- Understands the customer’s needs and the business value
- Organizes the process
- Keeps track of the teams progress
- Removes obstacles from the path of the team
Team (not just developers – everyone required to create the product)
- Organizes itself to perform the work and deliver business value
Events (all events in Scrum are timeboxed)
- Iteration typically of 1-4 weeks length
- This is where the development work (code, test, review, ...) occurs
Sprint Planning Meeting
- Select the stories the team believes it can commit to in a sprint
- Break the stories down into tasks and provide estimates for those tasks
- Team members share progress with other team members (not the manager)
- answer the three questions – “what did you do yesterday”, “what will you do today”, “do you have any roadblocks”
- Anyone may attend, only team members (people with skin in the game) may speak
- Scrum master uses the information from the standup to update burndown chart illustrating progress
- Fifteen minutes maximum - typically held standing up in front of Task Board - helps keep the meeting focused - side conversations are taken offline
- Product Owner plays the sprint’s work (without guidance) and provides feedback
- Developers may also demo work
- Team owns up to deficiencies with the product helping to build trust with the Product Owner
- Team reviews what went well and what went poorly
- Use retrospection techniques to find potential for improvement
- Pick one or two areas to focus for improvement
Caveat Emptor - this article outlines the mechanics of Scrum, it doesn't make it clear what difficulties and issues you will encounter trying to implement Scrum. In addition, it only hints at the Agile spirit that's required to make any methodology like this work. If you're interested in implementing Scrum (or any other Agile method), do some more reading, find a mentor/coach (if you're in Ottawa/Kingston Canada - talk to me). Scrum isn't something you can fully understand in 5 minutes.
If there's something more you would like to learn about Scrum (or Agile in general), leave a question in the comments and I will try to answer it.
Tip of the hat to Matt Truxaw whose 100 word summary I rewrote and Mishkin Berteig whose CSM course notes helped me nail my definitions.
Updates: Added a disclaimer as per Tobi's suggestion.
- 25th January, 2007: Initial post