This article gives a very quick executive summary of the Scrum process / framework.
It should be noted that referring to the Scrum Process above is somewhat of a misnomer. This is because Scrum is a framework, not a process. What this means is that rather than providing a detailed process, many of the decisions within the Scrum Framework are left up to the team to decide.
So without further ado, let’s get stuck in. Here is a diagrammatic summary of the Scrum framework:
The diagram above can be described as follows:
There you have it. A very basic introduction to the Scrum framework. Below you’ll find some definitions to further clarify the basic components of Scrum.
Product Backlog: This is a document containing high-level descriptions of all features to be developed in business priority order. This document is owned by the Product Owner. Typically, each item on the list will contain a rough estimate of both business value and development effort.
Sprint backlog: This is simply the list of things (again in priority order) that the team thinks they can do in the current Sprint. This is chosen by the team (pull) not by managers (push).
Burndown Chart: These simply show the amount of work remaining – they show in an instant wheather we are on or off target. They can work either at a Sprint level or a Release level. An example Burndown Chart is shown below:
Sprint Planning: This happens on day 1 of the Sprint and is where the team members create the Sprint Backlog.
Daily Scrum Meeting: These are used to synchronize the work of the team. The meeting should last no more than 15 minutes. Each team member discusses what they worked on yesterday, what they’re working on today, and any blockers they’re facing.
Sprint Retrospective: (aka Sprint Review) This occurs at the end of the Sprint and gives the entire team the opportunity to examine the Sprint just completed and identify improvement opportunities for the next Sprint.
Product Owner: Owns the Product Backlog. Essentially the Product Owner directs the team to ensure they are working on the right requirements.
Scrum Master: This role does not direct the team like a Project Manager and allocate tasks, instead they shield the team from outside distractions and remove blockers to enable the team to work as quickly as possible.
I hope this article has given you a good basic understanding of the Scrum Framework, and that you understand why it’s a framework and not a process. Additionally, you will understand that the team is self-organizing, in that the team as a whole determines its own destiny, one Sprint at a time.