The Agile movement is an approach to software development described in the Agile Manifesto. The Agile Manifesto describes the Agile philosophy using four foundational values:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
The Agile Manifesto provides guidance rather than a prescriptive methodology on what and how to be Agile. The values and principles found in the Agile Manifesto are meant to be adapted to best fit a particular situation. For that reason, a variety of methods have been developed to implement the Agile movement. One of the most popular methods is Scrum. According to a 2015 State of Scrum Survey Report, released by ScrumAlliance, Scrum is widely used and will continue to be used across a variety of functional business areas to deliver successful projects. This article discusses the Scrum methodology, the history of Scrum, how it can benefit your organization, limitations you may encounter and how to make the Scrum structure work for your organization.
What is Scrum?
Any discussion of efficient scrum project management must begin with a definition of scrum.
“Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each.”
“It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework.”
“Scrum uses fixed-length iterations, called Sprints, which are typically 1-2 weeks long (never more than 30 days). Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.”
Let’s unpack those statements to gain a deeper understanding of the scrum methodology, frameworks, and processes.
What the Scrum Process is Not
Scrum is not a linear development method; that’s the waterfall model. Waterfall is defined by a series of linear events in which the product is planned, developed, tested, etc., with no step started until the preceding step is complete. Scrum aims to develop smaller pieces of a release faster rather than focusing on all the steps taking place within those smaller iterations, or sprints.
Why Use the Scrum Methodology?
There are four primary benefits that come with using the Scrum method of Agile development:
- Responsiveness to Customers—Software development organizations are all too familiar with the customer demand to “build it yesterday.” In a traditional, waterfall development organization, you may be building a significant feature or function into a twice-a-year release schedule, and may be losing customers in the process. If the customers aren’t lost, they may be unhappy anyway and lost eventually when they encounter a competitor who can deliver more responsively. When working in short and frequent development cycles, you can deliver products to your customers almost on-demand, and can adapt more quickly to new demands.
- Lower Cost of Development—Agile, and Scrum, have proven to be less wasteful and more cost-effective. Developers wear many hats, and can be more versatile because smaller units can be effectively tested by the people who built them. Specialized roles are eliminated or reduced, ultimately creating a cost savings.
- Job Satisfaction—By delivering products rapidly, the team receives that extra jolt of satisfaction when a product is done and goes out the door. Every development team knows how good it feels to release a product twice a year, but with Scrum the team can feel that same satisfaction by releasing a product twelve times a year.
- More Immediate Returns—Instead of getting rewarded by customers twice a year, the reward is much more frequent. In addition, instead of delivering a new feature that will bring in the new customers twice a year, features can be delivered more frequently and special requests can be worked into the accelerated delivery schedule and get out the door fast.
A Brief History of Scrum
After publication of Dr. Winston Royce’s paper in 1970, titled “Managing the Development of Large Software Systems,” many people began looking for a new approach to software development that would eliminate the weaknesses of the criticized waterfall methodology. The name ‘Scrum’ came from Takeuchi’s and Nonaka’s 1986 paper, “The New New Product Development Game.” This paper suggested that the best way to achieve a goal is to provide clear objectives to a small team. In 1995, Jeff Sutherland and Ken Schwaber codified Scrum in their paper titled “SCRUM Software Development Process.”
How the Scrum Structure Works
The Scrum project management framework relies on self-organizing teams whose goal is to deliver complete products after fixed iterations, or sprints. In order to succeed using Scrum, it is useful to follow the Scrum structure. This structure consists of roles, meetings, rules, and artifacts.
Scrum consists of three roles:
- Product Owner—The Product Owner is the champion who has a thorough understanding of the product’s business value. They communicate the customer/stakeholder needs to the development team, but they are not responsible for the technical side of development. The Product Owner also writes the user stories and prioritizes them.
- Development Team—The development team performs all of the technical development tasks. The team is cross-functional and responsible for the analysis, design, writing of code, testing, technical communication, etc., based on the user stories and user story priority.
- Scrum Master—The Scrum Master facilitates the work of the Scrum team. The Scrum Master works with the Product Owner and the development team to remove obstacles and to prevent distractions. All communication to the development team by non-team members is filtered through the Scrum Master. (Sometimes Scrum teams meet in a “Scrum of Scrums,” which usually consists of the Scrum Masters from each team.)
There are four types of Scrum meetings:
- Sprint Planning—The Sprint Planning meeting is attended by everyone on the Scrum team. The Product is presented at this meeting and everyone’s concerns and interests should be voiced here. This is where priorities are presented and time estimates are made.
- Daily Scrum Meeting—A Scrum meeting that takes place daily during a sprint. They are brief and are intended to plan the development team’s activity for the day. This is the place for discussing obstacles encountered or confusion over a user story. The meeting is presided over by the Scrum Master and attended by the development team.
- Sprint Review—The Sprint Review is a demonstration of the working product developed during the sprint. This meeting occurs at the end of the sprint and is primarily used to provide stakeholders a detailed look at what was accomplished.
- Sprint Retrospective—The Sprint Retrospective is a post-mortem to discuss how the team did during the sprint and how it can improve its performance in the future.
In addition to these four meeting types, teams sometimes take time out during a sprint to hold a backlog refinement meeting to discuss backlog items and prepare for the next sprint. This can include conversations about prioritizing items in the Product Backlog and refining backlog items into smaller chunks.
Scrum artifacts represent the work that goes into completing a particular project or sprint and provide transparency into project details. There are three major artifacts that require management throughout a Scrum project: the product backlog, sprint backlog, and burndown charts. These are essential to delivering value-filled software to your customers.
Sprint artifacts and their components include:
- Product Backlog—Everything, both technical and user-centric, that must be completed within a project.
- Sprint Backlog—The set of all tasks to be completed within a sprint iteration. These are taken from the Product Backlog during the Sprint Planning Meeting.
- Product Backlog Item—An item from the Product Backlog that is to be completed within a sprint iteration. It is usually broken down into a few smaller tasks.
- Sprint Task—What you do to deliver a Product Backlog Item.
- Sprint Burndown Chart—The remaining effort required to complete the sprint tasks. The burndown chart can go up or down in response to discoveries the team makes about completing a task. This is not intended to be a report on team progress, but a way to determine how to overcome obstacles and meet commitments.
- Product Release/Burndown Chart—This is updated by the Scrum Master at the end of each sprint. The horizontal axis of the chart shows the sprints and the vertical axis shows the amount of work remaining at the start of each sprint.
Scrum Methodology Rules
For the most part, the Roles, Meetings, and Artifacts are the rules of Scrum, but some other rules may be applied in order to make Scrum work efficiently:
- The Scrum Team consists of the Product Owner, Scrum Master, and Development team and no one else
- Sprints should all be the same length
- When one sprint ends, the next sprint begins
- Every sprint begins with a Sprint Planning Meeting - the Scrum Master and Development team meet every morning for the daily meeting
- Every sprint has a Sprint Review Meeting to give stakeholders a chance to provide feedback
- It is not good practice to add to the sprint backlog during a sprint
For more information on Scrum terminology, refer to a glossary of Scrum terminology.
Limitations of the Scrum Framework
Scrum was developed to enable highly collaborative work. As a consequence, environments that impede collaboration are not ideal for the Scrum method. For example, if teams are located all over the world, the daily meeting may not be realistic for some team members. When a vital element of Scrum, such as the daily meeting, becomes an annoyance rather than a facilitator, that’s a sign that Scrum may not be successful.
Another limitation is that the team must be versatile and nimble. Ideally, any development team member can step into any other team member’s shoes to fulfill a task. This is another reason having all team members collaborate at the daily meeting will lead to success.
The Right Agile Methodology for You
As with any business decision, it’s a good idea to examine all Agile methodologies before settling on the one that is best suited for your organization. For example, you may find that eXtreme Programming (XP) is more suitable for your needs. XP is similar to Scrum, but the sprints are shorter, it allows changes to the sprint backlog during the sprint and XP priorities are set by the customer. Then again, Scrumban may be more suitable for you. Scrumban allows adding new backlog items to the sprint and also does not require time estimation in the planning phase. In other words, there are a variety of methodologies and that variety allows you to find the optimal way to make your customers happy.
Use Smartsheet for Efficient Scrum Project Management
Smartsheet is a spreadsheet-inspired task and work management tool with powerful collaboration and communication features. Use the pre-built agile project plan template to easily track plan details, share status updates, and collaborate on key tasks.
Track assigned tasks, due dates, and sprint status through spreadsheet, Gantt, Card and calendars views. Invite team members to the plan sheet for seamless coordination and collaboration with your team and external stakeholders. Attach files and working documents, and add notes and status details to keep everything related to sprints in a central location. Use Smartsheet’s powerful collaboration tools to manage comments, reminders, and attachments, and make changes in real time.
See how easy it can be to manage sprints, collaborate with team members, and meet Scrum deadlines. Try Smartsheet for free for 30 days.
Want more tips and best practices? Check out our Project Management Resource Hub for the latest articles, templates, and more!