Today’s companies have to move fast and be intentional in every decision they make. Processes such as product and service development must be governed carefully by a set of tested principles and frameworks that are proven to work — but not so rigid that they’ll get in the way or slow the organization down.
In this business landscape, scrum has become a leading problem-solving approach, one that companies of all kinds are using to direct their teams and accomplish their objectives. Especially if you have experience in the world of technology and software development, you may have already come across scrum as a project management philosophy. In any case, it’s worth asking in detail: What is scrum? Understanding how it works and what it can contribute to businesses’ efforts can help you become a more productive member of the team, whatever your specific role may be.
What Kind of Project Management Framework Is Scrum?
Scrum is a framework for project management developed by Ken Schwaber and Jeff Sullivan. In their own publication on the methodology, The Scrum Guide, the authors argue that their approach is valuable because it is not an inflexible process, method or technique. It is adaptable and lightweight and can apply to a number or situations.
The creators focused scrum on being lightweight and easy to understand while also being hard to master, meaning there is plenty of learning and growth possible within a scrum context. Scrum itself has nearly 30 years of use as a project management and product development approach for when teams are facing complicated, multifaceted issues and need a way to pull together productively, with each person doing their part to achieve a central goal.
How Do Scrum and Agile Development Go Together?
Scrum fits in with another commonly held principle in product development today, especially when it comes to software — agile processes. The Scrum Alliance indicates that scrum is an agile framework by which companies can follow agile principles, namely constant iteration and refinement.
Cross-functional teams break down their projects into small pieces when following scrum principles, creating “timeboxes” in which to perform cross-team development activity, then stop and look back, performing inspection and adaptation of the work. By reviewing what they’ve learned during these frequent breaks, personnel lessen the risk of making mistakes and enable themselves to reduce waste by intelligently changing course as needed.
Scrum Alliance pointed out that at the end of each development period, the team members don’t just stop to think about how their product or service is coming along, they also inspect how they are using scrum. It may be appropriate to make an adjustment during these intervals and become more effective in the next timebox.
A product released in these iterative cycles isn’t considered done when it’s initially released, which is another way in which agile development and scrum go together. In these methodologies, constant revision of a release to make it more suited to end-user needs is a normal part of doing business.
What Are the Scrum Values?
There are five core values associated with scrum. Scrum.org points out that these ideas have been talked about for a long time, but have only become an official part of the Scrum Guide in the past five years. These are concepts that will help keep teams focused on their work, ensuring they help each other and the project. The values are:
- Courage: This means the ability to take on difficult problems rather than deflecting or deferring.
- Focus: This value indicates that when a sprint period is underway, team members should be on task.
- Commitment: People working on a scrum project should take personal responsibility for achieving the goals of the team.
- Respect: Each member of the group should respect that the others have their own work and let them complete it independently.
- Openness: Rather than closing themselves off, scrum team members should communicate and be honest.
These values apply to everyone working on a scrum project, but that doesn’t mean every person will be doing the exact same work. Instead, there are a few separate team designations to ensure the whole group is working toward a united objective.
What Are the Roles within a Scrum Team?
The Scrum Guide points out that scrum teams are not directed from outside — rather, these are self-organizing units that consist of cross-functional personnel and make internal decisions about how to reach their goals. Since scrum teams are designed to be flexible, there is not a large list of rigidly defined job titles. Instead, there are just three major categories of worker within a scrum framework, each with duties to the organization as a whole and team responsibilities to the people in the other two roles.
The scrum master is the person designated to act as an ambassador between the team and the rest of the organization. This individual is responsible for the interactions between the scrum group and everyone else, helping the business at large understand scrum and the value being created. In cases where there are multiple scrum teams active, the scrum masters from each group work together to create an overall culture at the company that will support scrum work going forward.
The scrum master is also a coach, assisting the team members with any information they need to more effectively embrace scrum principles and move the project forward. This is the individual who will enforce principles such as agility and will make sure agreed-upon variables such as the scope and eventual objectives of the project are clear to everyone.
Since the goal of a scrum project is often to create a product or service that a company can use, it’s important for someone to have direct oversight of that end result. This is the product owner’s job. The Scrum Guide indicates that the product owner’s exact operational style will vary widely, but in general terms, this is the person who ensures the team is creating something with positive value. There is only one product owner per team.
This individual oversees the product backlog, a transparent list of steps that the group is working to achieve. The product owner should make sure there is sufficient clarity about not just the backlog in general but also the individual items on it, as well as the current status of the team in checking off those steps. When a member of the team wants to change something about the backlog, such as the order or priority of one item, that person goes through the product owner.
Development Team Members
While scrum master and product owner are jobs for individuals, the development team makes up the rest of the group and consists of many people. How many? The Scrum Guide suggests somewhere between three and nine members. This is because when there are fewer than that number, the group might not have the skills to complete its objectives, and may not communicate enough. By contrast, when there are 10 or more people, it is hard to keep the group coordinated and focused. The extra complexity counteracts agile team principles and is not worth the added skill at that point.
The job of the development team is to break the product backlog into increments that can potentially be released and then “sprint” through those increments. Other members of the team such as the project owner and scrum master don’t direct the development team or tell its members what to do — they organize themselves from within. There aren’t sub-teams in the development team. Every one of the cross-functional members is part of the same unit and development teams work as a single group.
What Are the ‘Events’ Associated with Scrum Sprints?
As Scrum Alliance indicates, sprints are the major unit of time during which a scrum project takes place. These are short, lasting between a week and a month and are each designed to create something “potentially releasable.” While sprints are mere parts of a larger project, the things they create are complete, reviewed, and tested unto themselves.
Breaking up the functionality of a large project into small discrete groups that each get their own planning, completion, and review is a way to allow personnel to stop and adapt their overall approach more often. When a major project is completed without such an agile framework in place, it’s possible for teams to miss major faults in a product until a full delivery later on, calling for time-consuming and expensive changes.
Since the sprint is the main unit of a scrum project, it pays to consider the role of other processes in accomplishing a sprint. This encompasses the planning that goes on before the sprint, the daily briefings that keep the team on track and the reviews and retrospectives that occur when each self-contained increment of the project is delivered.
While it’s important to have a strategy for a sprint before it begins, teams can’t get too bogged down in this work. That’s why The Scrum Guide states personnel should spend eight hours, at maximum, planning a month-long sprint. The plan is all about predicting what units of functionality the team can deliver in the duration of the upcoming sprint and how the team will complete the goal.
The development team reviews items from the product backlog and chooses some that seem to be achievable in the duration of the sprint. These items now make up the sprint backlog — they should make sense as a unit, and point toward a single objective, known as the sprint goal. The Scrum Guide acknowledges that sometimes the nature of work changes during a sprint. If that happens, the product owner and development team work together to adjust the sprint backlog.
The high-transparency nature of scrum sprints means there should be a check-in every day. This is a short meeting, typically just 15 minutes, but it is a valuable way to set the day’s agenda. The members of the development team see what they have accomplished since the previous day and plan what interval of the backlog they can reasonably complete in the next 24 hours.
While daily scrum meetings are designed to be extremely focused and not expand beyond their quarter-hour allotment, there are often more detailed meetings afterward, according to The Scrum Guide. These follow-up sessions are where the members either change their plans based on what they discussed in the daily meeting or simply get more in-depth about their work for the day. The scrum master makes sure the daily scrum happens, but does not directly participate — this is by and for the development team.
At the end of the sprint, it’s important for the team to reflect on how much of the product backlog they have completed. No matter how long the sprint was, the sprint review meeting should not be more than four hours long, and it should be a time for free discussion and collaboration.
The sprint review is a time to determine what items on the product backlog can now be considered done, and where that leaves progress on the product as a whole. If the scope or purpose of the product has changed based on the work accomplished during the sprint, this meeting is the place to consider what the new outcome should be. The team should leave the meeting with a rough idea of what the next sprint will cover.
Between the review of one sprint and planning of the next, there is a sprint retrospective meeting. The Scrum Guide indicates it’s up to the scrum master to ensure this session is positive and leads to a clear path forward. At this meeting, the team will assess the previous sprint and plan on improving for the next sprint.
Rather than the type of product backlog that was the focus of the sprint review, the sprint retrospective is designed to make the team think about their own work. If the members have discovered ways to improve the end result, the product, they discuss them at the retrospective. Perhaps there is a new work process that could make an impact, or maybe the definition of “done” the team uses could be adapted.
What Are the Scrum Artifacts?
Scrum is based on being transparent, with the progress of work being visible to all participants. This means the “artifacts” associated with the scrum process, including the product backlog, sprint backlogs, and increments must be visible and straightforward. The product backlog is overarching and lists everything the finished release will have. Items on the log are clarified until they are “ready” to be included in sprint planning, then declared “done” at the conclusion of a sprint.
The sprint backlog is made up of items from the product backlog. It is not an unchanging document — when new work is needed during a sprint, it is added. If something is deemed superfluous, it is taken off. The increment is the sum of items completed in a sprint — it must be in releasable condition and stand alone while still being part of the overall product.
How Does Scrum Apply to Information Systems?
Scrum’s focus on agility and continuous development is a perfect match to the modern approach to software development. However, this is not the only way in which it interacts with information systems work. Today’s organizations of all kinds have become keen users of advanced technology, both purchased and developed internally, and they need project managers to keep those deployments on track.
The places where technology and business objectives meet are the crux of modern operational management. Companies not only need programmers who can do the hands-on technology work, but also planners and organizers who understand technology through a management lens. These professionals can use scrum techniques to keep their projects on track.
What Types of Degree Programs Teach Information Systems Project Management?
If you are interested in a role that combines business and technology, it can pay to earn an advanced degree that specifically deals with this mixture of abilities and objectives. The online Master of Science in Management Information Systems from the University of Alabama at Birmingham’s Collat School of Business is one such program. The online nature of the program means you can maintain a full-time job while building master’s level technology and leadership skills on your own time.
The core courses within the online MS MIS, such as IT Project Management, are based around what it takes to be a skillful leader and organizer in today’s tech-driven work environments. Guiding discrete projects through to their conclusion using modern agile methodologies such as scrum is a fundamental ability, one that hiring managers may weigh highly.
Becoming an expert in information systems today means simultaneously understanding the latest in technological frameworks while also having the soft skills to lead a team in a productive and positive manner. Thinking strategically and keeping team members on task can be just as important as comprehending app development or server maintenance, and they are all part of a master’s level education in IT.
To learn more about the degree program and to see if it’s the right next step for your career, visit the program page.