What is Scrum?
Scrum is a software development methodology created partially by Ken Schwaber in 1993. Scrum is a framework that allows teams to work together to easily create software products. Products are developed in small iterations called sprints. Sprints typically last from 1-4 weeks with the goal at the end of the sprint being a releasable piece of functionality.
Since Scrum is iterative each additional sprint can build on the pieces built in the previous sprint. By doing multiple sprints a product gains more and more functionality. The entire basis of Scrum is that a team will work together cooperatively with the Product Owner to create a piece of software that is exactly what the Product Owner wants.
Components of Scrum
Scrum has three primary roles:
- Product Owner – This is the person or representative who is seeking a product. They are the person that determines what needs to be built. They give the team guidance on selecting the next piece to build.
- ScrumMaster – This is the person who is responsible for making sure the sprint and the entire process goes according to plan. They help improve the process over time and help insure the team is functioning properly.
- Development Team – Development teams in Scrum are typically cross-functional groups who are self-organized and are responsible for creating fully functional, fully tested pieces of software in 4 weeks or less.
Scrum has actually grown over time and has multiple methods for being successful. The original version consists of four parts:
- Sprint Planning Meeting – This is an initial meeting to kick off the sprint. The goal is to fully explain items in the backlog and choose which items will go into the sprint.
- Daily Scrum – This is a 15 minute stand up meeting to discuss what the team did yesterday, what the team will do today and what if any roadblocks are in their way.
- Sprint Review Meeting – This is a meeting to show the finished product at the end of the sprint.
- Sprint Retrospective – This is a meeting to allow the team to reflect on what went well and didn’t go well in the last sprint and discuss ways to improve next time.
Scrum has two “backlogs”. Backlogs contain items typically called user stories that describe pieces of functionality the team needs to create. The two backlogs are the Product Backlog and the Sprint Backlog.
How does Scrum work?
The Product Owner, ScrumMaster and a representative of the team work together to create a product backlog. Once the backlog has enough stuff in it to fill at least one sprint a Sprint Planning Meeting can be held. In the Sprint Planning Meeting the team and the Product Owner pick things from the backlog by priority with some negotiation on time and fill the Sprint Backlog.
Once the Sprint Planning Meeting has been held the sprint typically starts the next day. A sprint is a time boxed period of time from one to four weeks where the team will work on nothing but the items in the Sprint Backlog. The team cannot be interrupted during this period of time and the contents of the Sprint Backlog cannot be changed.
The goal of the team in a sprint is to finish all items in the Sprint Backlog. These are the items the team agreed to do in the Sprint Planning Meeting and it doesn’t matter how they complete them. It’s totally up to the team’s discretion on how to get them done.
At the end of the sprint a Sprint Review meeting is held to showcase the items completed in the Sprint. Only fully functional items can be shown. If the item isn’t complete, it can’t be shown. It will be the Product Owners decision at the end of the meeting to decide if the product can go live or if it needs more work.
After the Sprint Review a Sprint Retrospective is held for the team to discuss how the sprint went. They typically create a couple lists in this meeting. The first list is the things that went well that shouldn’t change next time. The second list is things that can be improved next time.
This was a quick overview of Scrum. Scrum is much more detailed and rich than I’ve presented in this short article. I personally have developed many pieces of software using this methodology. For a more in depth look at Scrum I recommend reading the Scrum Guide written by Jeff Sutherland and Ken Schwaber. It’s freely available here:
For anyone looking for a controlled way to develop software that beats the old traditional waterfall method, I highly recommend giving Scrum a try.