Scrum is one of the most famous agile methodologies. Its history can be traced back to a 1986 Harvard Business Review article, “The New Product Development Game” where Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development.
Scrum proposes two main concepts:

• Decomposition of the work in short cycles of delivery and feedback
• Empowering teams and trusting them to optimize their work

The idea is to provide a framework to enable the team to organize itself around the context it is in and the available work, to find the best way to perform the work properly and to remove impediments.

Scrum Roles

Scrum defines three roles that will keep the process flowing:

• Scrum Master: which is responsible for making sure that the scrum process is being properly used and followed. Besides that, (s)he is also in charge for removing impediments from the team’s way
• Product Owner: which is the voice of the customer next to the team. A PO has the responsibilities of define the priorities, manage the backlog and, above all, maximize the value of the product and the work of the team
• Team: which is the group of people that really does the job. The team is responsible to find the most productive way of performing the work at hands. Usually the team should have between 3 and 8 people

Scrum Ceremonies

Scrum defines a set of events or ceremonies that are always time limited and quality oriented. This time limitation is based on the concept that meetings are non productive time by definition and that developers should spend the most of their time doing what they are good at: developing great software! Besides that, they provide opportunities to plan the activities to foster predictability of results and, in the end, a quality work. Here you can find the list of ceremonies proposed by Scrum:

• Sprint: The sprint is the unit of delivery and feedback. It is in a sprint that the real work happens. It usually takes between 2 and 4 weeks. This duration is defined by the team in conjunction with the scrum master and the product owner to maximize product value. Once the sprint duration is defined in the beginning of the project, it should remain the same during all the project
• Sprint planning: this meeting is used to plan the work of the present sprint: the sprint backlog tasks are selected and estimated. The meeting is led by the scrum master and both the team members and the product owner must be present. The product owner should provide all kinds of clarification to enable a correct estimation and the grooming of the backlog items and sprint backlog definition. Once the sprint backlog is defined no changes should be accepted during the sprint (this rule can only be broken on very special situations and should be very uncommon). The duration of this meeting should be 2h per sprint week (for instance, a 2 weeks sprint should have a 4h sprint planning meeting duration)
• Daily stand up: these meetings are the most well known and widespread, but not always well used meetings. Usually they involve the scrum master and the team. However, the product owner may also attend these meetings. They occur every day (usually at the beginning of the day) and they take, at most, 15 minutes. Everyone should be on their feet to incentive a quick meeting. The main purpose of these meetings is to plan the work day. Here each team member should report the main difficulties that (s)he is facing and the risks that (s)he foresees for this day. All the remaining subjects should be issued outside these meetings. It is the scrum master’s task to lead these meetings and ensure that they are quick and effective
• Sprint review: this meeting is led by the scrum master and should be attended by the team, the product owner and other stakeholders invited by the product owner that may be relevant for the product or the specific features of this sprint. The duration of this meeting should be 1h per sprint week (for instance, a 2 weeks sprint should have a 2h sprint review meeting duration). In this meeting all the work performed (and finished) during the sprint will be presented to the product owner and relevant stakeholders. The attendees will, in turn, provide relevant feedback to the development team. The idea is always to show the increment of the sprint in the working product and collect relevant feedback to increase the product value. Now, with all this relevant people at the table is also time to discuss the next steps of the project in order to maximize the product value. This discussion will have, as output, a product backlog update
• Sprint retrospective: this meeting is led by the scrum master and should be attended by the team. The duration of this meeting should be 1h per sprint week (for instance, a 2 weeks sprint should have a 2h sprint retrospective meeting duration). This meeting occurs after the sprint review and before the sprint planning meeting of the next sprint. Its goal is to analyze the sprint that is finishing and propose improvements to the next sprints in order to make the next sprints’ outcome more effective

Scrum Artifacts

Scrum works around several artifacts that support all the process. I will describe here the ones that I think are important to the process itself. There are others that are important for the management of the process that I will refer and describe in detail in future posts.

• Product backlog: describes all the work that needs to be done in order to finish the project/product. It is an ordered list of items and it is constantly improving
• Sprint backlog: is a set of work select to the current sprint and a plan to complete it. It should be kept unchanged until the end of its sprint. The set of work is selected on the sprint planning meeting and should be dimensioned in order to be accomplished during the sprint. For quality improvement purposes it should include at least one high priority process improvement identified in the previous retrospective meeting
• Increment: is the set of product backlog items that were finished during this sprint. This artifact will be very important for the measurement of the process and team improvement
• User story: describes, from the user’s perspective, a feature that a user can use. A product/sprint backlog is composed by user stories and, when needed and the product owner accepts it, technical items

Adding all up

Ideally a project may start with a set of user stories in the product backlog (however, in the real word, it may start with just an idea in someone’s head or a diffuse description of some requirements). There may be one or more sprints dedicated to the grooming (definition) of user stories or even to the technical project setup. Usually these initial setup sprints may start to include “normal” user stories. Hopefully as the team and the project stabilizes, there will be more and more percentage of “normal" user stories.
A sprint should start with a sprint planning meeting. In this meeting a sprint backlog is extracted from the product backlog. Each of the following days of the sprint you’ll have a daily stand up meeting where the team organizes itself to accomplish all the items of the sprint backlog. At the end of the sprint, the accomplished items (comprising the sprint increment) are presented during the sprint review. Immediately after this meeting, a sprint retrospective should be held. Here all the problems that were faced during the sprint should be addressed and solutions should be proposed in order to improve the overall process. At the end of this meeting the sprint is officially finished and a new sprint with the correspondent sprint planning should be started. And all the process starts again.

Conclusion

These are the basics about Scrum. In future posts I will enter in more detail about each of these parts, how they relate to each other and how all the process can be measured or, in other works, managed.