To work with Scrum is dealing effectively with a changing world. Decisions are made on the basis of observation and experimentation, not the anticipation of detailed planning.
Scrum utilizes an empirical approach to adapt to changing customer requirements. The empirical approach is based on facts, experiences, and evidence. In particular, progress is based on observations of actual events, not plans built on a lot of initial requirements.
The three pillars of Scrum that support the empirical approach to process control are Transparency, Inspection, and Adaptation. We will discuss in the following lines what these pillars mean and how important they are to Scrum, in order to bring more productivity and better and more effective results.
Before we get started, let’s check a few samples of what we already talked about Scrum:
Transparency allows each team member to know what the others are doing. In fact, for a self-organized team, transparency is critical to the team’s success, as it allows everyone to follow the progress of the Sprint and have a real sense of what is needed to reach the goal.
However, even knowing the importance of keeping the team communicating and showing what they are doing, many people have difficulties in maintaining transparency in their projects, which often makes the end of the Sprint not as planned.
Two artifacts help a lot to maintain the team’s full understanding of what is being done. These artifacts are the task board and the burndown chart.
The task board allows the team to allocate everything that will be done in the Sprint into columns that represent the states of each task. In our projects, we use the columns “to do”, “doing” and “ready”.
It is worth emphasizing here the importance of defining what is ready for each story. Moving all tasks to the “done” column means the story is ready to be reviewed and approved by the Product Owner.
Therefore, the tasks should clearly show everything that needs to be done for the story to be really done, and this can include documentation tasks and some specific tests.
Board tasks are created early in the Sprint, in the second part of the planning meeting. A well-done planning meeting allows the team to start the Sprint with well-defined stories by the Product Owner and with their work well divided by the team itself, into tasks.
This is the first step to achieving the transparency necessary for Sprint’s success. By breaking down the work of a story into tasks that can be easily understood by the team, the progress of each story’s development becomes clear and the team will know how to estimate how long it will take for it to be done.
In addition to checking, from the tasks on the board, how much time is left for the story to be completed, it is also possible to check how much remains for the team to complete everything that was planned for the Sprint.
The daily meeting allows the team to find out more details about the tasks that have been completed as well as the issues the team has gone through or is going through.
Having daily meetings together with the correct use of the task board and burndown chart facilitates transparency in the work and thus increases the chances of success at the end of the Sprint.
You need to use artifacts and assess team progress to understand how important they are to making a team self-organizing. Here we discuss the use of the burndown board and chart, as well as the importance of the daily meeting.
The second pillar is Inspection, which means that every job must be inspected as often as necessary to ensure quality on the first attempt.
Inspection is such a strong principle that Scrum considers the testing process to be within the sprint itself.
This brings us to the concepts of continuous integration, test-driven development, and pair programming, which are ways to guarantee quality while the product is being produced, instead of controlling the quality only at the end.
Inspection is the art of thinking. Thinking in the sense of applying a critical view of what is happening, opening your eyes and your head to understand that the world is much bigger than your daily tasks, and understanding the impact of each one’s actions.
By this we mean that not only the product but also the dynamics of the team must be periodically evaluated, noting that inspection should not be so frequent that it interferes with the actual execution of the work.
Inspections are more beneficial when performed diligently by inspectors specialized in the work to be verified.
A good example of inspection practice is the retrospective meeting, when the team revisits the sprint that is about to end, assesses its work dynamics, and indicates the adjustments it deems necessary to make over the following sprints.
The inspection takes place, for example, through the following items:
- Definition of ready
- Definition of done at the grooming meeting
- When estimating the story points of a user story
- Review meeting with the customer (product owner)
- Daily, when someone finishes a story and a group member does the DoD check
- Checking for bugs and their respective correction
The third pillar is an adaptation, which means the ability to adapt the project to the business need.
Adaptation is the big thing about Scrum projects, as it can start with a set of stories and end relatively differently. The PO can build, modify and delete stories at the end of each sprint.
Once inspected, the process must be adapted whenever it is convenient to meet the needs or remedy any inconsistencies.
Adaptation is not just about the process defined by the team, but also about the product, as the team moves towards its definition of done.
It is at this moment that it is necessary to understand that it is always possible to do better. Another point that we are always attentive to is concerning complaints and problems, as we build a company to solve problems, and knowing how to adapt is knowing how to go over it and do it differently.
Practices such as one-on-one, reviews, retrospectives should always come with actions to be taken to further improve delivery, whether in quality, speed, and/or cost.
The PO’s prioritization of user stories, an adjustment to the team’s ready-made definition (or any other working arrangements the team has established), and the grooming backlog are good examples of this pillar.
Adaptation takes place, for example, through the following items:
- In project planning, when the PO prioritizes stories
- In a sprint review, when the PO reprioritizes the stories (backlog items)
- In the sprint goal concept, when the team has the freedom to make more or fewer stories than was planned
- In the concept of speed – which differs from progress, when, after a few sprints, you have the real speed of the team and you can calculate the time needed to finish the project.
Boost your productivity and creativity with GitScrum Scrums!
GitScrum has many Scrum features that will support all your project necessities. Increase your productivity and get instant and efficient results with our Scrums! Follow the cycle using our Scrum features!
Sign up now and make your team grow together!