Jul 31, 2023

By Alberto Méndez

Basic principles of Scrum

Agile methodologies were developed to provide a mechanism that facilitates adaptation to change in the development and creation of projects. In today’s fast-paced world, it’s essential to be ready for these changes to ensure the final quality of the project or product. Hence, the choice between an agile methodology over a predictive one can set us apart from our competitors.

History

Initially, every project was planned using predictive methodologies. These processes dictated every step from start to finish, leaving little room for flexibility. Any small deviation or unforeseen obstacle was a significant issue. Moreover, error detection usually came late when rectifying them became even more challenging. In contrast, Agile methodologies, focused on functionalities, enable early error detection, swift incorporation of changes, and immediate reactions to unpredicted challenges.

“Inhabitants of the Red Queen’s country have to run as fast as they can, just to stay where they are, as the country moves with them.” - Alice Through the Looking-Glass, Lewis Carroll

In the 80s, Takeuchi Hirotaka and Nonaka Ikujiro from Japan first introduced SCRUM’s application in product development. They implemented this methodology in companies like Epson, Honda, Hewlett Packard, among others. SCRUM, named after the rugby formation, was seen to have strategies applicable in businesses (and other domains) for product development.

It was only in 1995 at the OOPSA (Object-Oriented Programming Systems And Applications conference) that Ken Schwaber first associated SCRUM with software development.

Come 2001 in Utah, 17 critics summoned by Kent Beck coined the term “Agile Methods” to offer an alternative to predictive methodologies. They drafted the Agile Manifesto, summarizing the principles of the so-called agile methods.

Agile Manifesto

SCRUM is anchored in four core values extracted from the Agile Manifesto:

1. People and interactions over processes and tools: The main focus is on human interactions and iterations.
2. Working solutions over comprehensive documentation: Documentation should be succinct yet valuable.
3. Customer collaboration over contract negotiation: Continuous customer interaction ensures early error detection and appropriate actions.
4. Responding to change over following a plan: Agility is key to addressing changes and unexpected events effectively.

Our main objective is to meet customer needs by delivering valuable software early and consistently. Addressing changing requirements is pivotal. It’s not about minimizing changes but managing them. They are inherent to product development. Frequent deliveries (every 2-8 weeks) of functional software enable early error detection and efficient problem-solving.

Both the business and development teams must collaborate daily. They should synchronize to ensure accurate project estimations. Significant misalignment can lead to frustrations, affecting both the process quality and product outcome.

Projects should be built around motivated individuals. They should be provided with all necessary resources. Communication should be direct and face-to-face, minimizing misunderstandings. While remote communication tools can be utilized, in-person meetings remain crucial.

The primary focus should be on delivering working software. But this shouldn’t come at the expense of overburdening the team. Sustained work pace, technical excellence, and daily improvements foster agility. Simplicity is key. Basics should be solid, reliable, and error-free.

Without a leader, the team should still function. Team self-organization should be emphasized from the outset. This approach results in the best architectures, designs, and requirements.

Technical Scrum

This is based on three primary pillars:

• Roles
• Events
• Artifacts

The basic SCRUM cycle comprises the Product Backlog, which organizes features in order of priority. This backlog is dynamic. The Sprint Backlog contains the current sprint’s tasks and is static. Features chosen for the sprint transition between these backlogs through a process known as grooming. After the sprint concludes, we have what’s known as the increment, representing the delivery of the developed features.

Values and Principles

Agility stems not just from practices but also values:

• Respect among peers.
• Accountability and self-discipline.
• Work that’s value-driven for the client.
• Commitment.

There are three fundamental principles:

1. Empowerment: Teams should be self-organized and decision-makers.
2. Transparency: The development process should be transparent and well-informed.
3. Inspection and adaptation: Regular reviews to spot deviations and make necessary adjustments.

Roles

SCRUM distinguishes three main roles:

• Product Owner: Must be thoroughly familiar with the client’s business environment. They have the product vision and establish the objective, knowing what they want and determining the product’s value through the increment. There can only be one product owner, who provides the product backlog with all well-defined functionalities, sets priorities for each one, and acts upon them. Ideally, this role should be filled by the client or even better, the end user.

• SCRUM Master: They are not part of the team but ensure the team has the necessary tools to do their work. They act as a facilitator, offering servant leadership, ensuring the team meets its objectives, and advising them on self-organization. They are also responsible for explaining the rules, providing information, advising the product owner, reviewing and validating the product backlog, and moderating meetings.

• Development Team: Should consist of no less than 3 and no more than 9 members. The team should be multifunctional, multidisciplinary, and versatile, allowing any member to perform another member’s task. They are responsible as a group and work cohesively and self-organized. All members participate in decision-making, respecting each other’s opinions and contributions.

The roles of stakeholders or interested parties are also worth mentioning. While they are not typically integrated as a role, they represent all third parties involved in the project that aren’t part of the roles above. Within these roles, we can distinguish two groups:

• Committed: Those who commit to the product development process. This includes the product owner and the team.

• Involved: They are not part of the process but indirectly intervene in it. This group includes the SCRUM master and the stakeholders (management, sales, marketing, etc.).

Events

• Sprint: The name given to each iteration of the development process. It’s the core that generates progress at a set pace with a minimum of 2 weeks, 3 as recommended, 4 weeks as the maximum recommendation, and 6 as the absolute maximum. The manifesto mentions up to 8 weeks, but this isn’t practical in reality.

• Sprint Planning Meeting: Marks the beginning of each sprint, where the objective and necessary tasks to achieve it are determined. It’s led by the SCRUM Master, and both the team and the product owner, as well as any stakeholders, attend. It’s divided into three parts:

  • Preconditions: Available resources for the sprint are studied, user stories are prepared, and the employed technologies are known.
  • Inputs: The product backlog, what was developed in previous increments, data on the team’s velocity or performance in the last sprint as a criterion to estimate a reasonable amount of work to integrate, and the circumstances of the client’s business conditions and the technological scenario used.
  • Outcome: The sprint backlog, its duration, and the date of the review meeting, as well as the sprint’s objective.

• Daily SCRUM: It should not last more than 15-20 minutes. In this meeting, team members should report what they accomplished the previous day, the tasks they will undertake on the current day, and any problems or obstacles they faced, whether resolved or not. These issues should be explained so the entire team can benefit from this knowledge, and this explanation should not exceed two minutes. Ideally, this meeting should be conducted with the SCRUM board present. The team leads this meeting, and within it, two subgroups are established:

  • Inputs: Sprint Backlog and burn-down chart, both updated with information from the previous meeting and the progress of each team member.
  • Outcomes: Updated Sprint Backlog and burn-down chart, along with the identification of potential needs and obstacles.

• Sprint Review: The generated increment is analyzed and adjusted to the Product Backlog if necessary. The focus is on what is being built. It’s an informative meeting, not meant for decision-making or critiquing the increment. Those in attendance include the Product Owner, the SCRUM Master, the entire development team, and any other stakeholders who wish to participate. The completed increment is presented, and feedback should be directed towards the Product Owner—not the other way around. The subsequent sprint’s meeting is also scheduled during this time. The Product Owner should provide information to enhance the product’s vision value.

• Sprint Retrospective: This meeting is to review what occurred during the sprint. The team and the SCRUM Master discuss how they’re working and devise an improvement plan for the following sprint. It should be held in a constructive and positive manner. Sharing information and gathering data for process enhancement is crucial.

Artifacts

Within the artifacts, several elements can be identified:

• Product Backlog or backlog: It consists of user stories that define requirements in an agile methodology and are crucial for describing a feature. As previously mentioned, it’s an ever-evolving element, never considered complete. The Product Owner is responsible for maintaining it in order of priority.
  • User Stories: These make up the Product Backlog. Each story should provide a description, its priority, and an estimate of the effort. There should be one story for each functionality. They also highlight the acceptance tests which will later transform into tests.
• Sprint Backlog: This is the team’s responsibility and contains tasks that result from the grooming process applied to the Product Backlog. It’s initiated and concluded with each sprint and remains unchangeable except when setting task priorities. It’s displayed for the entire team on a board or wall in the same physical space where the team operates. Each task should indicate its owner, its status, and the time left for its completion.
• Increment: This represents the portion of the product developed in a sprint that is potentially shippable. It should be thoroughly tested and, of course, deemed complete.
• Epic: This symbolizes the client’s expectations—it’s essentially an unprocessed idea. It encompasses the user stories that form it.

Agile Measurement and Estimation

The process demands obtaining information on measurable values and numbers that determine performance, customer satisfaction, and efficiency. Additionally, there are various indicators related to the project itself, including effort, cost, size, development, defect density, design complexity, and availability.

Indicators should be few in number and practical. Any that are not useful for the process should be discarded. Often, the Product Owner requests indicators that provide the necessary information to understand the project’s status and evolution.

One of the most significant indicators contrasts the estimated time with the actual time, essentially comparing the anticipated duration of a task to the actual time it takes to complete it.

Velocity, Work, and Time

• Velocity (work/time): Displays the amount of work done per unit of time. It represents the amount of work completed by the team during a sprint (iterative increment). The usual trend is for the velocity to increase after each sprint.
• Time
  • Iterative Increment (SCRUM): In iterations, it indicates the number of tasks we’ve managed to complete in a sprint.
  • Continuous Increment (without sprints, characteristic of predictive methodologies, typical of Kanban): Shows a steady progress flow, measured in days, weeks, or months. Thus, the velocity is expressed in points that signify the amount of work.
• Work or effort: Determines the progress of the project that remains to be done, even though what has been completed is mentioned, it isn’t recorded. The remaining pending time might be greater than the previous day’s if unexpected issues arise in the task, revealing it requires more time than estimated. Two similar tasks performed by the same individual in different settings might have varying time estimates. It’s unrealistic to discuss the quantity or quality of work done by an individual per unit of time. Accurately estimating the amount and time required to execute a task isn’t possible. To enhance this precision, tasks are often broken down into smaller subtasks using the expert judgment technique.