Agile Scrum: Understanding concepts and knowing typical processes
Perhaps you've heard of Agile Scrum before. In meetings, in job advertisements, during project meetings. And maybe you nodded every time — but thought, “Honestly, I still don't know exactly how it actually works.” You're not alone in that. Many talk about Scrum, but only a few can explain it in an understandable way. That's exactly what we're doing here, so that you really understand how Scrum works, who does what and why it makes sense in the first place. Here you can find out what Scrum really is, how it is structured and when it makes sense.
Difference: Agile vs. Scrum
Working agile means: You assume that requirements can change over the course of the project and build your process in such a way that you can react to them. The opposite of this is a rigid plan that is fixed from start to finish, even if the environment changes.
Scrum is a concrete framework that provides this mobility (Agileity) in practice. It gives you a clear structure: with fixed roles, defined meetings and a recurring work rhythm. The attitude is therefore agile — Scrum is a method of how you can implement it.
You can also work in an agile way without using Scrum. And you can use Scrum without being really agile (you'll notice that very quickly in the project)
Example of Agile vs. Scrum
Imagine you want to organize dinner with friends and cook together
Thinking agilely means: You don't decide on a fixed menu weeks in advance, but see for yourself what you feel like during the day and adjust your dish spontaneously if some ingredients are not available today. It's about flexibility, collaboration, and quick response.
Scrum is the method you use to organize this: One takes on the role of Product Owner (who decides what's on the table), one is a Scrum Master (who makes sure that the tasks are distributed and that everyone can handle), and the team cooks. You plan together (Sprint Planning), briefly discuss the preparation (Daily), show the finished dish at the end (review) and talk about what should go better next time (retrospective).
Tip: In our article, you can find out more about agile software development.
What is Scrum: structure and process
For Scrum to work, it requires more than good intentions — namely clear roles, fixed processes and common tools. In this chapter, you can see how Scrum is specifically structured, who does what and how collaboration in the sprint is organized.
The roles in Scrum
- Product owner: Responsible for the product. He collects requirements, prioritizes tasks and ensures that the team is working properly. He talks a lot with stakeholders and makes professional decisions.
- Scrum Master: The Scrum Master is not a boss, but rather a coach. He makes sure that the team works according to Scrum, moderates meetings, removes obstacles and helps improve collaboration.
- Development team: These are the people who actually implement the product. It is interdisciplinary and self-organized. The team decides for itself who takes on which tasks.
The meetings (events)
- Sprint: The central work cycle, typically 1—4 weeks. The end result is a working partial result.
- Sprint planning: Here, it is decided together what will be implemented in the next sprint. The team plans what is realistically feasible.
- Daily Scrum (Daily Stand-up): A short, daily meeting (15 minutes). Everyone says: What did I do? What am I doing today? Are there blockers?
- Sprint Review: At the end of the sprint, the result is presented. Stakeholders provide feedback. Important: It's about the product, not the team effort.
- Sprint Retrospective: After the review, the team reflects on the process: What went well? What not? What will we improve in the next sprint?
Scrum artifacts: The tools of work
- Product backlog: The list of all requirements — maintained by the product owner, prioritized according to benefit.
- Sprint backlog: The specific selection of tasks for the current sprint — created by the team.
- Increment: What is finished at the end of a sprint and could potentially be delivered.
Step by step: A typical sprint in agile Scrum
Imagine your team is working on a new booking function. The product owner has already described and prioritized this feature in the product backlog. In sprint planning, the team jointly selects the most relevant tasks and formulates a sprint goal, e.g.: “Users can select and book appointments via a calendar.”
The sprint then starts. The team meets daily to coordinate. It is designed, programmed, tested — all within the team. If problems arise (e.g. the calendar API is not working as expected), the Scrum Master helps remove obstacles.
At the end of the sprint, there is a review: The new feature is shown to stakeholders. There is feedback that flows into the product backlog for the next sprint. This is followed by a retrospective: What was good, what went wrong, what will we do differently next time?
What does agile Scrum bring — and when does it make sense?
Scrum provides the necessary insight. You regularly see what's working and what's not. Instead of developing months into the blue, you get early feedback. Errors are noticed more quickly and user requests can be recorded. Even internally: Roles are clearly distributed, meetings are structured, processes are transparent.
Scrum is useful when you have a complex project with unclear or evolving objectives. If you work in stable processes with a fixed plan, a classic model may be more appropriate.
Typical use cases for Scrum:
- Development of new digital products
- MVPs for startups
- Long-term platform development with many stakeholders
Less useful:
- Unique, clearly defined implementations with no leeway
- Projects with very rigid approval processes
Understanding and using Scrum — with Axisbits
Maybe you're there right now, your team more agile or are you looking for a partner who not only knows Scrum in concept, but also lives in everyday project life. At Axisbits, we have been working according to agile principles, with real sprints, real reviews and real team responsibility for years.
Whether you already have an internal team that needs selective support, or would like to set up a project from scratch with Scrum: We'll get in where you need us. With technical experience, methodological clarity and the willingness to take on joint responsibility. You can see that our customer projects are running successfully in our portfolio.
So if you're looking for someone who thinks along for your project, collaborates and develops with you on equal footing: Let's talk — we look forward to your project.
{{fs-btn-cta}}
Wir schaffen leistungsstarke Plattformen und Websites für Startups, Scale-Ups und KMUs, von Konzept bis Go-Live.
We take on software development for start-ups, scale-ups and SMEs — from the idea to the finished product.
Agile Scrum — Common Questions and Answers
Not entirely. Agility is an attitude — the idea of reacting flexibly to change. Scrum is a concrete framework that allows you to implement this approach in everyday project work.
If the sprint goal is not achieved, it's no drama for now. It is important that it is clear why. The team discusses this in review and retrospective and adjusts the planning for the next sprint accordingly.
Ideally yes, otherwise important functions are missing from the process. In smaller teams, roles can also be combined, e.g. an experienced developer temporarily takes on Scrum Master tasks. But in the long run, Scrum works better with clear roles.
Yes, that is possible if the cooperation is well coordinated. It is important that external partners are involved in Scrum meetings and are really part of the team, not just contractors.
Scrum works in fixed periods of time (sprints) and with clear roles and events. Kanban is more flexible: Tasks flow continuously through the system, without a sprint cycle. Both are agile, but the work rhythm is different.
Most teams work with 2-week sprints. It's long enough to develop something tangible, but short enough to get quick feedback and adjust direction. 1 to 4 weeks is usual, depending on the project and team.
Typical tools include Jira, Trello, Azure DevOps, or Asana — they help with backlog maintenance, sprint planning, and task tracking. For daily meetings and retros, many teams also use whiteboards or virtual boards such as Miro or MURAL.
A good Scrum Master ensures that the team can work undisturbed. He moderates meetings, clarifies obstacles, ensures compliance with Scrum rules and helps to continuously improve cooperation.
More articles
Mobile applications, i.e. apps, can basically be implemented in two ways: as a native app or as a web app. Native apps are developed specifically for an operating system such as iOS or Android and installed directly on the device. Web apps run in the browser, require no installation and work independently of the operating system. But there are also intermediate routes.
When X was still called Twitter, “Twitter Lite” was introduced as a progressive web app. This resulted in a 65% increase in page views per session and a 75% increase in tweets sent. Other companies also rely on the benefits of a PWA. Here you can find out what PWAs are all about and when you can use them effectively.