If you have decided to implement SCRUM, congratulations! Read this guide carefully. It will serve as an introduction to what you will need to do, and as a step-by-step guide as you actually implement it.
Step 1: Choose the Product Owner
The Product Owner is a person who has a vision of the product and is perhaps championing the product in the company. This person will also have a vision of what the SCRUM Team needs to do, perform, or achieve. They must be able to consider risks and take note of possible threats. The Product Owner is the only person who decides what the priorities are and in what order the work will be done.
Step 2: Select the Development Team
To build the right Team for the project, you need to know a great deal about both the pool of employees you have to choose from and the skills required to complete the tasks. Teams may be as small as 3 people for a simple project, while no project is large enough to need more than 9 people. The success of the project depends on the Team more than anything else, so make sure the members get along, communicate well, and are good at organizing themselves.
Step 3: Choose a SCRUM Master
The SCRUM Master will guide the other Team members through the SCRUM framework and help remove any obstacles that might slow the Team down in its efforts.
Step 4: Create the Backlog and Prioritize
The Product Backlog is a list of all the important elements (functionalities) that need to be built, produced, or completed. The Product Owner builds the Backlog from Epics, which in turn are aggregated user stories. This person then prioritizes each item on the backlog and uses it as a checklist during implementation.
Step 5: Improve the Product Backlog
Next, the SCRUM Team needs to evaluate how much effort will be needed to complete the Product Backlog Items (PBI) and assess the following:
- how feasible each item will be with the resources provided (knowledge, skills, people, time, and equipment);
- if the item is small enough that the Team members’ effort can be assessed;
- if appropriate milestones can be defined.
Each PBI should be defined so that, when complete, a Team member can present it to any stakeholder who asks. Interestingly, the workload needed to complete the PBI is assessed on the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, and so on. The number 1 represents the smallest amount of time and effort, and each successive number represents a multiple of that amount. These numbers are then used to settle tasks and determine the Team’s Velocity.
Step 6: Sprint Planning Meeting
The Product Owner, the SCRUM Master, and the Development Team work together to plan the Sprints. No Sprint can be longer than 4 weeks—the Definition of Done (the functional product of a Sprint) is adjusted so that every Sprint takes the same number of weeks.
First, the Team members review the Product Backlog, starting with the highest priority PBI. They then break each Backlog Item into tasks.
Next, they define the objective of the upcoming sprint and determine how much they can accomplish during the upcoming Sprint. To do this, they need a deep understanding of each PBI. With experience, the Team members will be able to learn from previous sprints in terms of what’s generally possible, how the Team works and how that affects its pace, and what they themselves are capable of. They can then adjust their predictions accordingly.
One of the principles of SCRUM is that once the Team agrees on what it thinks is achievable in a Sprint, it becomes mandatory for all Team members. This mutual accountability is an essential feature of SCRUM.
Step 7: Complete Tasks and Present Results
Most commonly, SCRUM Teams will make a SCRUM board—a large piece of paper—with 3 or 4 columns, or more recently, use one of a number of digital versions. Each PBI is written on a self-stick note and placed in a column to show that it is planned for that Sprint, in progress, or completed (often termed “To Do,” “In Progress,” “Done”). During the Sprint, the Team moves the notes from one column to the next to indicate the current status of each item.
There is also a Burndown Chart, a graph that the Team can use to check how many Stories or points are left in the project versus how many days are left in the Sprint.
Step 8: Organize and conduct the Daily SCRUM
The Daily SCRUM is a meeting that is held at the same time every day for a maximum of 15 minutes. The entire Development Team meets to answer three questions:
- What have the Team members accomplished since the last Daily SCRUM in order to move closer to achieving the goal of the current Sprint?
- What will the Team members do today to help the Team achieve the goal and overcome difficulties?
- Do Team members see any obstacles blocking themselves or the Team from achieving the Goal?
This meeting keeps the goal of the Sprint at the top of everyone’s mind and ensures that all of the Team members are aware of where they are in the Sprint. If things are going well, the positive note is empowering; if things are a bit slow, it’s a chance to note who might need assistance, attention, or just more motivation.
Then, the Team decides together who will do what task and when on that day, taking into account each person’s skills, the current situation, and the goal of the Sprint.
Step 9: The Sprint Review
The purpose of this meeting is to present the achievements made during the Sprint. This is not only for Team members—you can and should invite and welcome others to the meeting, such as:
- Product Owner
- Management
- Clients
- Other stakeholders
The SCRUM board is useful again at this step for presenting the tasks that have been completed. The SCRUM Team should also demonstrate that the “Definition of Done” has been fulfilled and show what can be immediately delivered to the Client without further effort. (If the Definition of Done has not been met, you should not be having this meeting yet.) Remember, this is not necessarily the same as having a complete product. Each Definition of Done is something that is fully functional in terms of the tasks completed so far.
Step 10: The Retrospective
Finally, the SCRUM Team meets alone to discuss the last Sprint and, if applicable, to compare it to previous Sprints. The idea is to appreciate what went well and give due credit, and then to consider what could have gone better. This is where the Team members have the chance to learn from each other and find ways in which they can grow as professionals. You should especially consider the following:
- What should be done better in the next Sprint?
- What improvements can the Team implement right away in the next Sprint?
- Why did the work go the way it did?
- If something was forgotten, why did that happen?
- Could the Team work faster? If so, what changes would help that happen?
It is important that each Team member take responsibility for his or her performance on the Sprint and for the effect on the results. The members must also have the courage to raise difficult issues and look for solutions. The SCRUM Master and the Development Team can then agree on what to do to eliminate any problems in the next Sprint.
Agile SCRUM implementation
While hardly an overnight process, the effort to implement SCRUM in all of your development projects will certainly pay off. SCRUM methodology offers you not just an efficient way to complete projects but also a powerful motivational boost in terms of interpersonal accountability and individual growth. There are also the benefits from working in a cross-functional Team rather than entirely within a single department.
The next blog post will cover some best practices to make sure your SCRUM methodology is the most effective it can be.
