Works by students from the " PJAIT " at the International Puppet Theater and Animated Film Festival “A Puppet Is a Person, Too”

Scrum is one of those terms that comes up very often in job postings, IT project descriptions, and discussions about modern team management. For those just entering the tech industry, however, it may sound like just another corporate acronym. In reality, it’s a structured way of working that helps teams respond more quickly to changes, regularly review results, and deliver a product step by step.
When we type search terms like “what is Scrum” or “what is a Scrum Master” into a search engine, we’re usually looking for a simple answer: Is Scrum a methodology, a set of meetings, a project management approach, or perhaps a specific role within a company? The answer is a bit more complex. Scrum is a framework—a structure for organizing team work—that’s particularly popular in the IT sector but is also increasingly used in marketing, education, finance, and administration.
To fully understand Scrum, it’s worth starting with the relationship between “Scrum and Agile.” Agile is a broader approach to project work, based on flexibility, collaboration, short cycles, and frequent feedback. Scrum, on the other hand, is one of the most well-known ways to put Agile principles into practice.
In other words, Agile describes a way of thinking about work, while Scrum provides guidance on how to translate that philosophy into the day-to-day organization of a team. Agile project management in IT emerged as a response to the limitations of traditional, rigid project management models. Scrum builds on this logic by introducing specific roles, events, and artifacts that help the team work in short iterations.
This distinction is important, if only because Scrum is not “Agile in its entirety.” Rather, it is one answer to the question of how to organize work when a project is complex, requirements may change, and the team must regularly deliver something of value to users or customers.
In everyday language, people often refer to the “Scrum methodology,” and that is exactly how the phrase appears in many job postings and job descriptions. More precisely, however, Scrum is a framework, because it does not describe every step of the work process from start to finish. Instead, it sets a framework within which the team itself selects specific practices, tools, and techniques.
Scrum is based on the simple premise that in complex projects, it’s impossible to predict everything at the outset. The team should therefore work in short cycles, regularly review results, and adjust future actions based on what it has learned. That is precisely why transparency, inspection, and adaptation are so important in Scrum.
Transparency means that the team and stakeholders can see what work is in progress, what the priorities are, and what has actually been completed. Inspection involves regularly checking progress and quality. Adaptation means being ready to change the plan if new information, different user needs, or technical constraints arise.
The basic unit of work in Scrum is the sprint. It is a short, fixed cycle that lasts up to one month, although in practice many teams opt for one- or two-week sprints. During a sprint, the team completes selected tasks and works toward creating a product increment—that is, a concrete, working result of their work.
At the start of a sprint, the team plans what it wants to achieve and why this area is important. Over the following days, it monitors progress, removes obstacles, and refines the details. At the end, they present the results, gather feedback, and analyze what can be improved in the next cycle. This rhythm helps reduce the risks typical of long-term projects, where a team works on a solution for many months, only to find out at the very end whether the result meets users’ needs. In Scrum, verification occurs more frequently, allowing errors, misunderstandings, and misguided assumptions to be detected more quickly.
A Scrum team consists of a Product Owner, a Scrum Master, and developers—that is, the people who build the product. However, this doesn’t refer exclusively to programmers. Depending on the project, the team may also include testers, UX designers, analysts, data specialists, or other individuals needed to deliver the final solution.
The Product Owner is responsible for the product’s value. This person organizes the backlog, sets priorities, and ensures that the team works on what matters most from the user’s and the business’s perspectives. It’s also important to note that the Product Owner does not manage people, but rather the direction of product development.
Developers, in turn, are responsible for completing the work planned for the sprint. They decide how to technically implement the tasks, ensure quality, and deliver product increments. In a well-functioning Scrum, the development team is not a group of people waiting for instructions, but an independent team of specialists that takes responsibility for the outcome.
The Scrum Master, on the other hand, ensures that Scrum is understood and applied in a meaningful way. He is not a traditional project manager; he does not assign tasks on a daily basis, nor does he act as the “team leader.” Rather, his role is to support the team, remove obstacles, facilitate meetings, and help the organization work in accordance with Scrum principles.
The Scrum Master plays a role that isn't very intuitive—he or she doesn't write requirements in place of the Product Owner, nor does he or she micromanage the developers like a traditional supervisor. Instead, the Scrum Master helps the team work more effectively, with greater transparency, and with a stronger focus on the sprint goal.
The Scrum Master can lead or facilitate meetings, help resolve conflicts, ensure that Scrum events are meaningful rather than empty rituals, and support the team in removing obstacles. If the problem is unclear priorities, the Scrum Master can help the Product Owner and the team clarify the area. If the problem is cross-functional dependencies, the Scrum Master can facilitate communication with other parts of the organization.
A good Scrum Master also teaches teams to be self-reliant. The point isn’t for all decisions to go through a single person, but for the team to be able to plan on its own, assess risks, discuss challenges, and improve its own work process. That is why communication, empathy, knowledge of teamwork mechanisms, and an understanding of the technological environment are so important in this role.
Scrum has several fixed events that structure the workflow. The most important of these is the sprint itself, which serves as a framework for the other activities. Within the sprint, the team holds a sprint planning meeting, daily stand-ups, a sprint review, and a retrospective.
Sprint Planning is used to define the sprint goal, select the most important items from the backlog, and plan how to implement them. This is the moment when the team answers questions such as: What is most valuable right now? How much can we get done? And how will we approach the work?
A Daily Scrum is a short, daily meeting of a team working on tasks. Its purpose is not to report to a supervisor, but to quickly check progress and plan the next step. A well-run Daily Scrum helps identify roadblocks, align efforts, and maintain focus on the sprint goal.
The Sprint Review takes place at the end of the sprint and provides an opportunity to showcase the results of the work to stakeholders. It shouldn’t be just a slide show, but a discussion about what was delivered, how it has changed the product’s status, and what lessons should be taken into account in future decisions.
A Sprint Retrospective is a meeting focused on how the team works. Participants analyze what went well, what hindered progress toward the goal, and what improvements are worth implementing. As a result, Scrum isn’t limited to delivering new features, but supports continuous process improvement.
Scrum uses three main artifacts that help organize work and increase transparency. The first is the Product Backlog, which is an organized list of needs, features, improvements, bugs, and ideas related to the product. It is not a document that is set in stone. The Backlog evolves as our understanding of users, the market, technical constraints, and business objectives grows.
The second artifact is the Sprint Backlog. It is a work plan for a specific sprint, covering the sprint goal, selected items from the Product Backlog, and how they will be implemented. The Sprint Backlog belongs to the development team that performs the work, so it should be updated whenever new information becomes available.
The third artifact is the Increment, which is a finished, tested piece of the product. It can be a new feature, an improvement to an existing solution, a quality enhancement, or any other result that brings the product closer to its goal. It is crucial that the increment be tangible and meet established quality criteria, rather than merely a promise of future work.
Is there a place for a project manager in Scrum? The answer depends on the organization, the scale of the project, and how responsibilities are divided. Scrum itself does not define the role of a project manager, but that does not mean that project management skills are no longer needed.
Project management in the technology industry requires planning, communication with stakeholders, risk management, budget control, and an understanding of how technical teams work. In a Scrum environment, some of these tasks may be distributed among the Product Owner, the Scrum Master, and the development team, but larger organizations often still need people who can tie together multiple work streams, manage dependencies, and coordinate activities at the project portfolio level.
What matters most, then, is not the role itself, but clarity regarding responsibilities. If the Project Manager, Scrum Master, and Product Owner work in the same environment, they must understand where one role’s responsibilities end and another’s begin. Otherwise, chaos can easily ensue: the Product Owner may lose influence over priorities, the Scrum Master may be reduced to the role of a meeting organizer, and the team may lose its autonomy.
Modern IT project management rarely involves simply following a predetermined plan. Digital products evolve in an environment where user expectations, regulations, technologies, business models, and competitor actions are constantly changing. Scrum helps teams work in such conditions because it emphasizes continuous learning and rapid adaptation of subsequent decisions.
That is precisely why Scrum is often discussed alongside terms such as project management methodologies, Agile, Kanban, and Waterfall. Each approach has its own applications. Projects with a stable scope and strict formal constraints may benefit from other models, while innovative, product-based, and digital projects often benefit from short work cycles and frequent user interaction.
However, Scrum is not a magic solution to all problems. It won’t fix poor communication, indecisiveness, or an unclear product strategy if the organization isn’t truly committed to changing the way it works. It can, however, very quickly reveal where bottlenecks lie, because it enforces greater transparency and regular discussions about progress.
You can learn about Scrum through courses, certifications, hands-on experience in project teams, and working independently with tools such as Jira, Trello, Azure DevOps, Miro, or Confluence. The key, however, is understanding that Scrum isn’t just about mechanically following a set of meetings. The most important thing is to understand the purpose of each element—that is, why we plan a sprint, why we hold a retrospective, how the backlog helps us make decisions, and how the team measures progress.
A good starting point for those interested in combining technology, business, and work organization might be “ field of study ” (Information Management) atPJAIT. The program combines IT, management, analytical, and communication topics—areas that are particularly important when working on IT projects.
In doing so, it places particular emphasis on the use of IT tools that support management, working with information systems, and acquiring competencies related to IT project management. This naturally ties in with the principles of Scrum, as effective work in agile teams requires both an understanding of technology and skills in communication, information analysis, and decision-making.
Scrum is a practical framework that supports agile project management, particularly when the product is complex and requirements may change. It helps teams work in short sprints, deliver regular product increments, and learn from feedback.
For those considering a career in IT, project management, business analysis, product management, or as a Scrum Master, knowledge of Scrum is one of the core competencies. It does not replace technical, business, or communication skills, but it helps to integrate these areas in a practical way. That is why Scrum remains one of the most important concepts for anyone who wants to understand how modern technology teams really work.







