Agile methodology builds on agile principles and makes use of agile practices. Here we look at the practices, which we categorize into organizational and technical practices. The Scrum artifacts and Scrum roles mentioned are explained in their own blog articles.
Organizational Practices
This part of our introduction to Scrum covers the organizational and technical practices associated with it. These include the cadenced approach, the various meetings, continuous delivery of the product, and test-driven development.
Cadenced Development: The Sprint Cycle
One of the core agile practices is working in a cadence (Timeboxing), typically with a period of between one and four weeks. The associated fixed time period is called a Sprint, cycle, or iteration. In each time interval, a small piece of the overall project is worked on and completed. The goal is to have a working (partial) product after every iteration — continuous delivery of results. Sprints give the team the opportunity to gather early feedback from potential users and the Product Owner.
The Kick-off Meeting
A Scrum project begins with a “kick-off meeting,” in which the initiative is discussed with the project team for the first time. Goals, customer expectations, and the product backlog are all addressed.
Sprint Planning Meeting
The Sprint planning meeting marks the beginning of a Sprint. This first meeting consists of two parts. In the first part, the team commits to a set of features to be created in this Sprint. In the second part, the team collects the tasks that need to be done in order to deliver the agreed-upon user stories. The Sprint planning meeting takes one to two hours per week of development.
Daily Scrum
At the Daily Scrum — a regular standing meeting typically held at the start of the workday — team members meet for a maximum of 15 minutes (strict Timeboxing limit). Each person presents what they have accomplished since the last Daily Scrum, what they plan to accomplish before the next one, and what has been slowing them down. The goal of the meeting is to analyze the team members’ work and adjust the approach if necessary. The analysis happens during the meeting; the adjustment can take place after it. The team does not need to solve problems during the meeting itself — it is enough to raise the difficulties and decide which team member will handle them.
Sprint Review
The Sprint Review marks the official end of the Sprint. All stakeholders are invited to this meeting. The team shows what it has achieved and demonstrates the stories that have been implemented. Stakeholders can now see how the product has incrementally improved through this Sprint. They can give feedback to the team, which allows the product to be analyzed and refined further. The Sprint Review should be between 30 and 60 minutes per week of Sprint duration. If the team has not managed to implement a user story, this is the moment to inform the stakeholders.
Retrospective
At the end of a Sprint, the team holds another meeting in addition to the Sprint Review: the retrospective. Scrum supports the idea of continuous improvement. The retrospective, held at the end of every Sprint, is the time for the team to reflect on what was learned during the Sprint and how that learning can be applied to achieve improvements. Taking minutes can be helpful for documenting outcomes. The retrospective takes one to two hours per week of development time.
The goal of the retrospective is not to create a long list of things that went well or poorly. It is enough to identify one or two things that will make the next Sprint more effective.
Shared Code Ownership
In Scrum, the entire team is always responsible for the entire product — and therefore for the entire source code. This is meant to ensure that a consistent coding style is maintained and that the team remains capable of acting in all areas of the code, even when team members are replaced.
Technical Practices
Continuous Integration
Another agile practice is “continuous integration.” The aim is to have a system available at virtually any point in time — even if incomplete, it must be functional. To achieve this, implementation is structured so that each increment of implementation results in a functional increment for the overall system. The system’s operability is verified, for example, every night through automated tests.
Test-Driven Development
In software development, it has in many cases proven useful to write tests for a module before creating the module itself. This approach offers several advantages:
- Tests define the acceptance criteria
- Functionality can be clarified before investment is made in implementation
- It prevents tests from being skipped due to time pressure
- Tests are an essential quality assurance tool in Scrum
Refactoring
“Refactoring” refers to the structural restructuring of an existing code base in which the external behavior of the system does not change. The restructuring takes place in a series of small steps, in the hope that not much can go wrong along the way.
Refactoring is used primarily to correct deficiencies in design. Rather than spending a great deal of thought upfront on the design of a system, refactoring is used later to fix design flaws. Only with the help of automated tests can it be proven — after refactoring — that the behavior is equivalent to what it was before.
Further Information
The practices described here are found in almost every agile project management software. Our separate article offers an overview of project management tools and a comparison of them. Further background reading: agile project management, agile principles, agile values, Kanban board, Scaled Agile Framework, and Agile vs. Waterfall.
Editor and Writer
Gabriella Martin is a Yale University graduate and holds a Master's degree in German Literature from the University of Tübingen. She loves explaining complex things in simple terms.
