Scrum: how the most widely used Agile methodology works
Scrummage or Scrum?
Do you know rugby? That sport where 15 people against 15 try to get an oval ball into the opponent’s goal in any way possible. It’s certainly not the most famous of sports (although for me it’s still one of the most honourable), but if you’ve ever seen any of it, you will remember for sure one very particular phase of the game: the fray, also known as the scrummage or scrum for friends. In a scrum, the players of a team, packing closely together, attempt to gain possession of the ball by pushing together and in the same direction: a convenient way of achieving a common goal.
This is where Ken Schwaber and Jeff Sutherland took their cue back in 1995 to give a name to the working methodology they were devising: Scrum. This is what it was all about: a method of bringing a team of people together and getting them to work in a coordinated and organised way to achieve a goal in the best possible way.
Since the 90s we have heard a lot about Agile and in particular about Agile methodologies (if you have never heard about Agile I recommend this article), nowadays most companies in the IT industry (actually also in other fields) adopt such approaches in the design and implementation of successful products. Scrum is one of the most popular Agile methodologies and according to the State of Agile Survey, about 64% of companies adopt it, making it the most suitable method for complex and innovative projects.
What is Scrum and how does it work?
The official guide describes Scrum as: ‘A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.’
So we are talking about a framework: a set of practices, roles and tools for organising one’s production process in the best possible way. A set of knowledge to start with in order to refine one’s own methodology and adapted to one’s own organization.
Scrum is based on the empirical approach: transparency, inspection and adaptation are defined as the 3 pillars of empirical control. The objectives of the project must be clear, each step of the process must be inspectable and on the basis of the experience gained, the process must be adaptable in order to improve the final result.
Like all Agile methodologies, Scrum is based on dividing the project into several iterative development phases, called Sprints. At the end of each Sprint, the new implemented functionalities are presented: the customer can evaluate them and decide how to continue. This iterative system makes it possible to increase the project functionality project little by little, but very frequently. At the same time, the team and the customer can constantly check the overall progress.
The design and development work is entrusted to the Scrum Team, a team of professionals who adopt the Scrum framework by defining Roles in the team, using Artifacts and organising the Sprint in certain Events.
There are 3 roles within the Scrum Team: Product Owner, Scrum Master, Development Team
The Product Owner defines the work to be done, acting as an interface between the stakeholders and the team. His role is to gather requirements, mediate between the parties and plan the progress of the work, in order to maximise the value of the final product and the work of the Development Team. He/she actively collaborates with the developers by clarifying doubts, answering questions and defining development goals in line with the product roadmap and the users’ wishes.
The Scrum Master is a leader, a kind of coach, at the service of the Scrum Team. He is responsible for promoting and supporting Scrum by helping everyone understand the theory, practices, rules, and values of Scrum. His role is to protect the team from external interferences and interruptions, to solve possible impediments, to facilitate confrontation meetings, so that the project will be successful.
Team di Sviluppo
This is a self-organised, cross-functional team of professionals, consisting of a minimum of 3 and a maximum of 9 members, which is responsible for product development and functionality testing. The team decides autonomously how to implement the functionalities identified by the Product Owner and takes responsibility for the entire development in order to complete the individual Sprints.
There are 3 artifacts: Product Backlog, Sprint Backlog and Increment. They are designed to increase the transparency of key information and the opportunity for inspection and adaptation.
The Product Backlog is a list of all requirements needed for the realisation of the project. The Product Owner is responsible for its content, availability and the ordering of its elements according to development and release priorities. It is a dynamic document: a continuously improved list, with the initial version listing only the most preliminary and well-known requirements and then evolving according to how the product changes, to the feedback received from the customer and to the needs that emerge. The Product Backlog is made up of User Stories: short and simple descriptions of the functionalities from the user’s point of view considering the business value it brings to the project.
A User Story usually has the following structure: As <user role>, I want <goal> so that <reason or business value>
As blog administrator I want to moderate comments so that there is no spam
As a user, I want to register on the portal so that I can access the reserved services.
As an e-commerce administrator, I want to receive an email for each order so that I can better organise shipments.
The Sprint Backlog is the set of Product Backlog elements selected for the Sprint. It is a forecast made by the Development Team in relation to the priorities indicated in the Product Backlog and the work needed to achieve the Sprint Goals. The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to achieve the Sprint Goal, keeps track of the work done on a daily basis, the tasks completed and what remains to be done.
Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments from all previous Sprints. An Increment is a set of “Done” and inspectable work that supports empiricism at the end of the Sprint. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Definition of ‘Done’
The Scrum Team defines the rules and conditions under which a Product Backlog item or increment is “Done”, members must have a shared understanding of what is meant by a completed job in order to ensure transparency.
The Sprint is the core of a Scrum: it is a a limited (time-boxed) period, generally ranging from two weeks to a month, during which a potentially usable and releasable Product Increment is created.
It can be seen as a mini-project and the whole team must be clear about the Sprint Goal. During the Sprint, the goals identified in the planning phase remain fixed, as does the duration: once the deadline has passed, the Sprint ends even if not all results have been achieved. Only the results achieved and considered as completed by the team can be selected for the final product.
The Sprint is organised in 4 main events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Of course, followed by the development sessions.
The events used in Scrum have a fixed duration and serve to create regularity, synchronise activities and minimise the need for undefined meetings. The purpose of these events is to allow critical transparency and inspection of the project’s progress.
This is the meeting that marks the beginning of the Sprint: the Scrum Team agrees on the main Sprint Goal and identifies the elements of the Product Backlog needed to achieve it. The Development Team analyses the User Stories, identifies the single activities to bring them to the “Done” state and makes an estimate to understand which ones can be developed during the Sprint. At the end of the Sprint Planning the Sprint Backlog is drawn up. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
The Daily Scrum is a daily 15-minute meeting for the Developers of the Scrum Team. In this short period of time, the team plans the day’s work by inspecting the work done since the last Daily Scrum and forecasting the upcoming planned work. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.
The meeting allows the Scrum Master to identify any issues that may be slowing down the team’s work and allow to take timely action.
The Sprint Review is the second event of the Sprint and is time-boxed to a maximum of four hours for a one-month Sprint: its aim is to assess whether the Sprint Goal has been achieved and with what results. The Sprint Review is an informal meeting and serves the Scrum Team to show to stakeholders the Increment achieved during the Sprint. The purpose of the review is to elicit comments and promote collaboration between the team and the stakeholders. Following this discussion the Product Owner can decide whether or not to release the Increment.
Immediately after the Sprint Review the Sprint Retrospective is organised, a formal meeting for the Scrum Team only to discuss the Sprint.
In this phase the team identifies what went right, what caused problems and what improvements can be made to the process. At the end of this inspection, the team is able to plan any corrective actions for the next Sprint.
The Sprint Retrospective officially ends the Sprint and development of the project starts back from Sprint planning, going on iteratively until the project is completed.
As we said at the beginning of this long article, Scrum is a framework, it is a starting point for process optimisation. We apply it to software development, but this doesn’t mean it can’t be applied to any field.
Its nature as a framework allows us to have a set of tools and well-established practices, it is up to us to apply and use them at their best in order to…
“…productively and creatively delivering products of the highest possible value.” – cit. The Scrum Guide™