The entrance of the Agile model might have as well marked the exit of the traditional waterfall model. The waterfall model was characterized by the ineffective utility of the three most important factors in a project, time, finances, and the end-user. Today, businesses are keen on optimizing available resources to meet customers’ needs and are on the lookout for tools, models, and practices that will make this happen. This is where Agile methodology comes in which is usually implemented by a ScrumMaster who has undertaken a CSM Certification Course. The same projects that the waterfall methodology implemented, Agile implemented in a short time with fewer resources in a more flexible manner and still delivered higher quality.
What then is Agile?
Agile is defined as development methodologies based on incremental iterative development. A project is divided into cycles known as iterations. With each iteration are client requirements, development, testing, delivery, and client feedback. This allows the development team to adapt quickly to changes in requirements so that ultimately, it is delivering a high-quality product that aligns with a client’s requirements within a short time.
What is Scrum
Scrum, on the other hand, is one of the popular frameworks under Agile methodology used to implement complex projects whose requirements are sometimes not clear or known. Scrum adopts the same approach as Agile by subdividing a project into several iterations called sprints to build a product incrementally by adding and improving features with every sprint.
Scrum is more focused on value and operates on empirical process control which includes three critical pillars.
- Transparency. This is the principle that ensures visibility of all aspects of the process to the scrum team and the stakeholders. Transparency in Scrum is not merely visibility but knowledge and a clear understanding of all aspects of the process by the team members.
- Inspection. Frequent inspection of the process by everyone involved ensures that variances and bugs in the process are identified and resolved in time to deliver quality eventually. This is done by collecting client and stakeholder feedback after every sprint.
- Adaptation. Scrum is by nature a framework that supports fast and easy adaptation of requirements. Adaptation can only happen where inspection and transparency are effective. Adaptation is best done as soon as possible to prevent further variance.
The Scrum framework is simple. It is made up of guidelines in the form of three elements to enable the successful adoption and use of the Scrum framework.
- Roles. There are three clearly defined roles in Scrum including the product owner, ScrumMaster, and the scrum team. Everyone involved in the process has a specialized role that they play without which the product cannot be developed. Scrum teams are cross-functional and self-organizing.
- Artifacts. Scrum artifacts embody the empirical process pillars described above. These are the physical elements of the process generally used during development and are the ones that create an opportunity for transparency, inspection, and adaptation. There are three artifacts in Scrum which include product backlog, sprint backlog, and increment.
- Events. Communication, collaboration, openness, and transparency are at the core of scrum processes and Scrum events make them achievable. Scrum events create a regular structure for meetings taking into account frequency, time factor, attendees, and the agendas. Scrum events ensure that the inspection and adaptation pillars are achieved within the time set-out. There are 5 events including:
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Within the Scrum framework, the product development process is divided into sprints. Sprints are time-boxed iterations usually two-four weeks which encompass planned activities to be carried out by the scrum team to deliver a usable, releasable, or done product for review before embarking on the next sprint. A sprint is in a sense, a mini-project with a goal, a plan, and a defined finish and start plan.
Sprints detail the following:
- Sprint planning
- Daily scrums
- Development work
- Sprint review
- Sprint retrospective
The Sprint Backlog
The Scrum guide defines a sprint backlog as an artifact with features pulled off the product backlog to create a sprint. These features are in the form of user stories which then makes it possible to identify tasks to be done within each story to complete it. This should also be accompanied by time estimation so that activities are completed within timelines.
It is important to note that the sprint backlog is not a strict commitment to tasks but a forecast of the functionalities to be included in the next increment and the work involved to deliver it as ‘Done’.
Importance of the sprint backlog
- The sprint backlog is a time plan that details all the activities required to deliver the increment in time and with high quality. This helps the team to stay on course during execution.
- The sprint backlog rounds up all the roles of the development team into one unified approach so that they are working in collaboration and monitoring progress in tandem to the achieving of the sprint goal. This eliminates overlapping or overlooking of tasks.
- Enables progress tracking on the working spreadsheet and in daily scrum meetings. This way, the team will be in a position to identify variations as soon as it occurs and address them.
- In the course of addressing variations, the team can also predict delays and communicate this in advance.
- The sprint backlog may also include a process improvement priority which should be in response to challenges raised in the preceding Sprint Retrospective.
How a sprint backlog is created
The process of creating a sprint backlog starts at the sprint planning meeting.
- Sprint backlog planning
Before a sprint takes off, a sprint planning meeting is conducted to define the goals of the sprint. As we have seen, the length of the meeting is predefined and this depends on the duration of the sprint. For instance, a two-week sprint should take a maximum of two hours to plan.
The sprint planning meeting is facilitated by the ScrumMaster in the presence of the Product Owner who shares the details of the product backlog and the acceptance criteria to the Scrum team. The team will ask as many questions as they can in a bid to clearly understand the features of the product backlog and their priorities. Afterward, these features will then be selected from the product backlog and pulled into the sprint backlog.
A product backlog is the first of Scrum artifacts whose owner is the product owner. It is a listing of all the features of a project along with their description, priority, and the expected functionality.
- Updating Sprint Backlog
During the progress of the sprint, daily scrum meetings are held for at least 15 minutes to update each other about the status of the sprint tasks and ensure that each team member is on track with their allocated items. After the meeting, all other updates are done on the spreadsheet by the ScrumMaster.
- Managing a sprint backlog
While the product backlog is owned by the product owner, the sprint backlog is owned by the development team. As team members mark their tasks done, the sprint backlog keeps being updated and modified with tasks from the product backlog as required.
It is the role of the team to break down features pulled from the product backlog into tasks. This allows the team to pull the right work into the sprint backlog. However, sometimes when the work is too little or too much the team is allowed to either add or reduce the tasks.
- End of the Sprint
The end of a sprint is when most allocated tasks are marked ‘Done’ and can be delivered as a usable increment. It is important to note that it is not a must for all the tasks to be completed. If by the end of the sprint some tasks are remaining, the team agrees with the product owner to return them to the product backlog after which they will be pulled along with other features for the next sprint.