Scrum basics – everything but the gobbledygook

I have recently written a few short posts about Scrum without having the decency to set the scene and introduce you to what Scrum really is. That’s why I’ve now made an effort to summarize the mechanisms of Scrum.

I’m making this a short, stripped down introduction for two purposes; a) To show how small the “formal overhead” of the process is, making it graspable by anyone, and b) to use this post as a reference for later discussions on Scrum. This is why I have taken the liberty to remove all rationale, philosophy and reasoning behind Scrum. The rationale and the reasoning, however, is as important, if not more important, as the specific mechanisms. This, in turn, renders this post incomplete. Don’t worry too much about that. I’m covering rationale and the “why Scrum” part in extensive detail in prior, and upcoming posts. So let’s cut to the chase, and see what the Scrum process forces down your throat (in a good sense).

1. Create and maintain a product backlog. This is a list of functional and non-functional requirements sorted by importance, and given estimates on a “best guess”-basis. These requirements should be understood by the customer (Product Owner).

2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog. The team break these requirements into actionable items (tasks), and carefully adds their estimates. A goal is constructed for the sprint that the team can commit to. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later.

3. Do the sprint (with daily scrums). The team carries out the sprint during the coming month, and scrum masters (managers) are mere facilitators at this stage. The team self-organizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) of only 5 to 15 minutes duration regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me to do what I plan to do?

4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review.

5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving in the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints.

6. Rinse and repeat every 30 days.And that’s all there is to it.. if you cut out all the “gobbledygook”, that is.

We’ll have to visit and revisit each of these topics in more detail, and we’ll have to inspect and discuss their impacts on understanding Scrum, and how the team, the managers and ultimately the customer benefits from Scrum. Following this list of activities in its bare and naked form is no recipe for success. Please stay tuned for the upcoming discussions on this topic.