What is Scrum?
There is a common misconception about Agile and Scrum. Most people in IT would have an idea, but unless they practice these, they would not be able to describe and differentiate between these two properly. In most instances, Agile and Scrum have been used interchangeably. It begs the question, “What is Scrum?” and “How is it different from Agile?”
Agile started out as a methodology. It is was meant to provide an alternative to traditional project management methodologies which used the Waterfall model. With the continuing development and evolution of Agile, especially as it is used in other disciplines, it has become a mindset or a strongly guided philosophy with different frameworks for the implementation. Scrum happens to be one of those frameworks. The others include Kanban, Lean, and Extreme Programming. During implementation, it is quite common to see that Agile teams would be using one framework but include elements from others.
Agile itself feels more like Rapid Application Development on steroids. A common trait of both Agile and RAD is the active participation of users. Another characteristic is the rapid turnaround of development stages. However, RAD still uses the older waterfall concepts of finishing one stage before proceeding to the next one. It is only iterative in the prototyping and development stages and not in the whole project. RAD is also more rigid in its implementations.
One characteristic of Agile is the inherent introspection which leads to the streamlining of the process. In this regard, it is easy to see that Scrum, as a framework, is flexible, adaptable and fits changing needs and situations. Scrum can coexist with other traditional tools, and make use of traditional roles and personnel. However, it is quite a ways away from the traditional waterfall processes, typified by Structured Systems Analysis and Design Method (SSADM) which was the backbone of big software development efforts during the 1970s and 1980s.
What is Scrum? – An Introduction to the Framework
Scrum is considered as a subset of Agile. It is also an agile development process framework. It has its own set of practices and terminologies which define how work is to flow. The process framework includes Scrum Artifacts, Scrum Ceremonies, and Scrum Roles.
Strictly speaking, Scrum is not really a subset, but a full implementation because it contains all the tenets of Agile. Agile is the mindset, and Scrum is how work is done with the given mindset. Within the framework:
- Has a disciplined process of project management;
- Promotes self-organization;
- Has accountability;
- Frequent inspection of the process, results and status;
- Encourages adaptation;
- A set of best practices for assurance and delivery of quality software;
- Aligns business development with the Agile Manifesto.
Even though it is a full-fledged methodology in terms of implementation, Scrum is considered a lightweight framework. It is lightweight in the sense that it does not have any extras which can weigh down how it works. It is designed to be streamlined, which resulted in a small, clean process with maximum productive time to get the actual work done.
Even though it has been stripped down to minimize distraction, it is capable of use for complex and large software development. It uses incremental and iterative processes, which ensure that tasks are finished, and any revisions or changes are incorporated in the process. It presumes that the development is also a moving target and adapting to these changes is part of the process.
Software engineering has raised the issue of software development and the inherent problems it faces. Among these is that a finished product once delivered is obsolete. A software is designed to address a problem. It is viewed from a given point in time. Time passes from the project ramp up to final delivery. During that time, the requirements have changed and users want more features. This is addressed in several ways by Scrum. The iterative process enables adding new items to the to-do list. It expects that the to-do list will change as the project moves forward. Additionally, the project is conducted and tracked in terms of “done” tasks. It starts with a to-do list called a backlog, and in time, the list shrinks as more tasks are accomplished.
Scrum process benefits include:
- Improved quality of product deliverables. The iterative process also includes a QA process which corrects any mistakes in terms of output or directions.
- Expecting changes to affect the outcome. Scrum not only expects that there will be changes during development, it has a system to include the changes during the development.
- Better time and resources estimation and management. The shorter time between iterations allows for better estimation while also using up less time creating the estimate.
- The team and organization are given more control over the schedule and status. It also has more transparency over the process, including the tasks that need to be done.
In any project, documentation is the key to effective communication. Traditional structured development and project management methodologies rely on creating various documentation and using these as a baseline to compare with actual development. In Scrum, the major paperwork or tasks, or otherwise output are called artifacts.
Artifacts are not project documentation. The product documentation is an output and a deliverable artifact. Artifacts are used to keep track of the project tasks.
The primary to-do list is called the Product Backlog. It is a master list of items which are not yet done. Maintaining the master list is the job of the product owner or manager. It is a list of requirements, product features, revisions and enhancements, fixes and others. From the Product Backlog, items are chosen to be included in the Sprint Backlog.
It is interesting to note that the Product Backlog is alive and dynamic. It is constantly changed, revised, reviewed, and appended. The Product Owner has responsibility for updating the Product Backlog and he can change it according to market conditions, changes in the business process, simplification of processes, and others. The Product Owner can also have the items re-prioritized for any of the above reasons for revisions. At the same time, items may be removed if they are no longer needed or relevant.
A Sprint is a chunk of time for development work between iterations. A Sprint Backlog is the list of items to do during the sprint. It is a subset of the Product Backlog and chosen according to priorities.
One method used to determine what items are included in the Sprint Backlog is MoSCow prioritization. It is a technique to understand project priorities. MoSCoW stands for:
- Should Have
- Could Have
- Won’t Have at this time-boxing
The criteria for prioritization can also change as the project progresses. It is necessary to know that the items on the Sprint Backlog are not written in stone. It is possible that an item is shelved for the next iteration, but is removed because it is no longer relevant. During the Sprint Cycle, it is also possible that some items in the Should Have category are done, or that some Must Have items are not done at all. The Sprint Backlog only lists those which are going to be done and given attention. It is not an absolute list of items which have to be finished within the fixed time for the Sprint Cycle. It is not uncommon to not have enough time to do everything in the Must Have list. The Sprint Backlog can be reviewed during the sprint cycle and changed as needed. It is also a dynamic to-do list. What cannot be changed is the sprint goal.
Also called the Sprint Goal, the Increment is the end-product of the Sprint. It is a usable deliverable or deliverables. In some Scrum implementations, there is a separate ceremony where the completed Increment is shown outside of the team. When all the items on the Sprint Backlog are done, the Increment should also be considered as “done.”
Teams define the sprint length and increments. Typically, the sprint length is two weeks, and the Increment is an item which can be done in during that time. Some teams may choose to have sprints which last a month. There are some other projects may have to consider other factors including corporate or client commitments to determine their sprint cycles. Having longer sprints can cause problems with schedules. Long sprint cycles often result in the team not meeting their goals.
An Increment does not have to be a deliverable for the client. It can also be a partial delivery of a larger project. It is possible to deliver partials during sprints, with integration at the end of the project. These are considerations on the choice of Increment which depend on the development or the building approach.
Scrum is an iterative framework and the increments all add up to a larger build down the road. It is up to the team to determine what the Increments are going to be and how these are going to be sequenced. It is also up to the team to define what the increment is, and what “done” means.
Scrum Events or Ceremonies
Scrum events or ceremonies are activities within the framework. These events are time-boxed with a fixed duration. Within the context of the Scrum, these cannot be shortened or lengthened. This allows people to be productive within the given timeframe for the specific activity, without encroaching on other activities. This lessens time wastage for the event as well as for the project as a whole. The different scrum events include Backlog Organization, Sprint Planning, Sprint, Daily Scrum, Sprint Review and Sprint Retrospective.
Strictly speaking, the Backlog Organization is not a scrum event because it is an organizational activity done prior to setting up the framework. Also called backlog grooming, the Product Owner is held responsible for this activity. Among other tasks, the Product Owner is also responsible for the product vision, driving the product towards the vision, and to have a constant monitoring of the market and the potential customer. Although the activity is simply to organize the backlog, listing down the items and set up initial dependencies and priorities. The backlog list maintenance is based on user feedback, and with the help of the team, the items can be prioritized according to defined criteria. The Product Owner is also responsible for ensuring that the Product Backlog is ready for the development team to work on.
The Sprint Planning lays down the work to be done during the next sprint cycle. The entire development team meets to decide on the sprint goal. Use Stories are added to the sprint for the team to better understand the individual items on the sprint backlog. The team determines if the stories are feasible for addition to the sprint, as these are used to clarify the goal. Sprint planning sessions are led by the scrum master.
The sprint is the actual time between iterations. Typically, it is two weeks long. However, some teams may choose to have longer sprints. The length of time is up to the team, and they can adjust for succeeding cycles as they see fit. It is the development time during which the team builds items on the sprint backlog. Each time an item is finished, it is tagged as “done”, and the developer moves on to the next one. The sprint scope can be changed in negotiations between the development team and the product owner. If warranted, the goals, deliverables and increments can be changed accordingly. It has been suggested that with complex work, there should be shorter sprints. This leads to more sprints with higher quality output.
A sprint is the time parcel for the scrum. Every activity happens during a sprint, from planning to the retrospective. The length of a sprint should be held constant for the length of development. This helps the development team to learn from their experiences and apply their learnings to succeeding sprints.
Also called the Daily Stand Up, the Daily Scrum is the daily team meeting. It is conducted standing up to ensure that it is a short meeting and would not eat up productive time. The meeting discusses the accomplishments of the previous day, the plans for the next 24 hours, and the expected challenges or obstacles. The meetings also emphasize the team composition, ideally composed of 7 to 8 persons. They meet at the same time every day at the same place. Due to the time sensitivity, this is usually held for only 15 minutes. There is not enough time to consult a calendar about the previous day’s activities, thereby shortening a daily summary. The stand up is the time for members to relay their concerns about sprint goals and any obstacles.
The Sprint Review is done at the end of a sprint. This is the time when the team conducts an informal review of the increment. Backlogs done are noted, and the development team gives its feedback. The product owner also decides whether to release the increment or not. Additionally, the product owner re-organizes the backlog in preparation for the next sprint planning session. This is a short meeting which should up to two hours for two-hour sprints.
The Sprint Retrospective is the time allotted for the team to review and discuss the previous sprint cycle. Among the items for discussion are the things which well and what went wrong. This is not a time for finger-pointing, rather it is for fine-tuning the process. The aim of the retrospective is to gather the learnings and move forward while improving the process.
Important Roles of Scrum
There are three roles in Scrum: Product Owner, ScrumMaster and the Team. The Team is composed of team members. The nature of the work involves the members working closely together daily, ensuring the flow of information and resolution of any issues.
Scrum Product Owner
The Product Owner keeps the product requirements. Considered as the “single source of truth” for the requirements and the order of implementation. He is the main point of contact between the various stakeholders, including the company or corporate managers and the potential customers, regarding their product needs, as well as the team. The Product Owner acts as a buffer for the Team, shielding them from direct communication regarding bug fixes, and requests for revisions. He supplies all the product-related information to the team. The Product Owner helps define the user-facing aspects of the products, like the user experience and interface, as well as the technical requirements. He maintains the Product Backlog, managing it and keeping it updated, meeting the requirements for the Team to do their work. He decides on the schedule for the release of the completed product, and he also makes the decision on implementation features and quality assurance prior to release.
The ScrumMaster is often mistaken for the project manager. This role is separate from the project manager and has little project management tasks included. The ScrumMaster’s responsibility is to keep the process running smoothly. To accomplish this, the ScrumMaster is responsible for:
- Clearing any obstacles during development;
- Facilitate the interaction between the product owner and development team, allowing the product owner to drive the project;
- Assist the development team by encouraging creativity and to empower their roles;
- Improve productivity;
- Impart learnings and best practices to the team;
- Provide the necessary information for the team to act upon, updating the team and stakeholders about the development progress;
- To keep the project visible to all parties and stakeholders.
The ScrumMaster is the group ideologist, keeping the Team on board and within the Scrum framework.
Scrum Development Team
The ideal Development Team is trained not only in Scrum and its methodologies but also in other Agile methodologies which can be used as needed. These include Kanban, Lean and Extreme Programming (XP). It may be necessary to work using dual programming from XP for a short period of time. The members should be ready for these and other eventualities.
The goal of the team is to create the product. They have the authority to decide on how to divide the work and how the project will proceed. They are tasked to communicate on a daily basis as well as to inform other members of any issues which they need to know. A Scrum Development Team can be from 5 to 9 people.
Who benefits from Scrum?
The short sprint cycles provide immediate benefits to the customers. Revision changes are usually included in the succeeding sprint cycle. High-value revision requests are given priority and it shows in customer reviews. This allows the team to also revise the product backlog to include the revisions and their effects on the final product. This responsiveness enables the development to keep up faster with the evolving customer needs.
Stakeholders have better control of the resources, as well as scheduling and are provided a more accurate estimate of development time. Compared to traditional waterfall project management methodologies, it is more efficient, with less time lost due to meetings resulting in improved productivity.
The short cycle time also creates better software due to the inherent quality assurance function of the process. This results in better customer experience, positive responses, and retention.
Team members are not asked for documentation and other artifacts which are not needed after the development efforts. Documentation of processes also entails a couple of iterations for checking and quality assurance. This time is removed from the schedule and is used by the team in doing what they do best. They value their work more because they are not tasked to write these lengthy project documentation. Developers who enjoy programming are given more time to do so. The development team feels better about their work with the appreciation that their effort is valued by the customer.
The Product Owner benefits with higher customer satisfaction. They are able to bring to the table the concerns and changing requirements from their customers. They can re-prioritize work to fill their customer’s needs, and ensuring a better deliver value to the customer.
Upper management also benefits with the transparency of the process. They can see the development in short cycles and the improvements in each cycle. Management also has more control with the resources, as well as the project output.
Scrum practitioners can form Communities of Practice among themselves or with those who have the same interests. These could be a group of developers, technical personnel, or even product owners. The community is a way for practitioners to exchange ideas about particular niche industries, roles or processes. They can also engage in discussions and exchange feedback about issues and concerns regarding scrum in practice, and Agile as a mindset. Sharing their interests, the communities serve as a conduit of information, where learnings are passed from one person to another. The communities also serve as repositories of information about a wide range of industries and practice. These can range from shared experiences, as well as problem-solving and brainstorming opportunities.
A scrum community is a highly organic group which follow a lifecycle. The community would be in the best position to educate people about Scrum, answering the question, “What is Scrum?” Although this means that the lifespan may only exist for a limited amount of time, it also means that stagnation won’t set in. Other communities start with different interests which mirror those of the members. Older communities may die out because their topics or interests are no longer relevant.
Ready to increase your work productivity?
#1 rated scrum tool
Monday.com Project Management Tool
You may also be interested by: