Scrum in Software Development: Agile and Structured

Scrum is an agile framework for developing complex products. It is based on transparency, regular inspection, adaptation, and the self-organization of the Scrum team. The official Scrum Guide provides guidance for its application, describing roles (or responsibilities), events, and artifacts.

Although many people refer to Scrum as an agile development method, it is actually not a method but a “framework.” The Scrum framework is primarily used in product development but can also be applied in other complex work environments. Development in Scrum is organized into iterations, called sprints. These sprints provide the team with a consistent rhythm through their fixed duration.

According to the Scrum Guide, a Scrum team consists of three accountabilities:

Product Owner is responsible for maximizing the value of the product and managing the Product Backlog

Scrum Master supports the team in effectively applying Scrum, removing impediments, and continuously improving collaboration

Developers implement requirements and deliver a usable increment in every sprint

At Projektron, we have extended these accountabilities for our multi-team product development. Today, five Scrum teams are working on BCS. Product Backlog management is supported by multiple Domain Product Owners who are responsible for specific product domains and contribute their expertise from across the organization. Overall responsibility for product strategy, prioritization, release goals, and central standards lies with the Chief Product Owner.

It is important to note: Domain Product Owners do not replace the Chief Product Owner. They take on delegated responsibility within defined guardrails, for example in preparing requirements, prioritizing within their domain, and managing allocated story point budgets per release.

Scrum teams should be small enough to remain effective and large enough to cover all necessary skills for product development. Oversized teams increase communication and coordination effort. At Projektron, this was one of the reasons why development was split from three into five smaller Scrum teams in 2025: this allows teams to organize more easily, reduce coordination, and focus more effectively on their work.

Anyone who is not part of the Scrum team according to the framework but has an interest in the product development is referred to as a stakeholder. Stakeholders participate in the Scrum process in various ways but are not part of the Scrum team. Examples of stakeholders include customers, users, or management.

There are recurring activities that are scheduled as regular events. They provide the team with a fixed rhythm and create transparency:

The Sprint is a fixed timebox of up to one month in which the Scrum team works toward a shared sprint goal. At Projektron, Scrum teams currently work in three-week sprints. Previously, our sprints lasted two weeks; with the introduction of the fifth team, we extended the sprint duration to allow more time for cohesive development work, coordination, and review cycles.

A special feature of our Projektron Scrum is the rotating mid-sprint. At any given time, one team takes on bundled operational and preparatory tasks such as support, bug fixing, internal improvements, and preparing upcoming sprints. This allows the other teams to work more steadily toward their sprint goals. This rotation ensures that unplanned work does not disrupt all teams at once and that responsibility is distributed fairly.

Each sprint begins with Sprint Planning. In this event, the Scrum team defines the sprint goal and selects the Product Backlog items needed to achieve it. The Developers also discuss how they will carry out the work during the sprint.

During the sprint, the Daily Scrum takes place every day. This short meeting is used to inspect progress toward the sprint goal, align on next steps, and identify obstacles.

At the end of the sprint, the Sprint Review is held. During this event, the increment is inspected together with relevant stakeholders. The goal is not only to present completed work, but also to gather feedback, provide context, and, if necessary, adapt the Product Backlog.

This is followed by the Retrospective. In this event, the Scrum team reflects on collaboration, processes, and potential improvements for the next sprint. While the Sprint Review focuses on the product, the Retrospective centers on how the team works.

In addition to accountabilities and events, Scrum defines three artifacts that create transparency around work, goals, and progress:

The Product Backlog is the complete list of all user stories, requirements, improvements, and tasks that need to be implemented for the product. This list is continuously evolving and contains all items the Scrum team will work on, ordered by priority.

The Sprint Backlog contains the sprint goal, the selected Product Backlog items for the sprint, and the Developers’ plan for delivering them.

The Increment is a potentially releasable piece of the product that meets the Definition of Done. The decision of whether the increment is released or not lies at the discretion of the Product Owner.

The basis for accepting user stories at the end of the sprint during the demo is the Definition of Done (DoD). All criteria of the Definition of Done must be met for a user story to be considered complete—that is, fully implemented and ready for release. During the sprint demo, only completed user stories may be presented.

At Projektron, quality assurance has become significantly more standardized over time. In the past, user stories and tickets were not always processed, tested, or accepted consistently. As a result, requirements could be postponed across multiple releases, and it was not always clear whether a committed implementation had actually been completed on time and in full. Today, clearer standards, defined acceptance processes, a rework process, and more reliable release planning ensure that requirements move through the development process in a more transparent and traceable way.

We decided to introduce Scrum in order to increase developer satisfaction and to structure our product development more reliably. In December 2009, we established Scrum in software development at Projektron. Unlike many companies that adopt Scrum primarily to become more agile, a different aspect was central for us from the very beginning: we wanted to work in a more structured, predictable, and transparent way.

This need arose from the previously unstructured way of working: customer support staff would approach developers of their choice at any time and ask them to quickly implement customer requirements and support tickets. Sales representatives promised software customizations during on-site client meetings, which developers then had to deliver in the next release. Customer complaints were hastily turned into change requests.

As a result, it was often unclear

• what the next release would include,
• whether additional implementation requests would come in at short notice,
• how long it would take until the release could be delivered,
• which additional requirements (beyond those of a specific customer) a feature needed to fulfill, and
• how a customization or feature should be tested.

At the time Scrum was introduced, there was no process in place to ensure that all new software enhancements were included in the documentation and communicated to customers.

Even later, when we were already working with three Scrum teams, it became clear: Scrum alone does not automatically solve all structural issues. Up until 2024, there were still areas where our processes lacked consistency. Domain Product Owners were not always sufficiently onboarded, documented standards were partly missing, and user stories or tickets were not consistently handled, tested, and accepted.

This led to recurring issues in release planning:

• committed implementations were not always delivered reliably,
• releases were sometimes delivered later than planned,
• the scope and coherence of individual releases were not always well aligned,
• requirements were postponed from release to release, sometimes over long periods,
• Domain Product Owners did not always know when their user stories would be implemented,
• some tickets were estimated but not consistently followed through,
• other requirements were defined but not implemented, creating effort without reliably delivering product value.

These experiences were a key driver for the evolution of our current Scrum model. The core idea of working in a more structured, predictable, and transparent way still shapes our Scrum approach today. As our product scope expanded, our customer base grew, and we now operate with five Scrum teams, Scrum at Projektron has been continuously refined. The goal was never to replace Scrum, but to apply its principles in a way that fits our product development, release planning, and organizational structure. We needed clearer standards, more binding processes, better release control, and greater transparency regarding when specific requirements would be implemented.

Today, five Scrum teams at Projektron are working on the further development of BCS. This structure was introduced in 2025, after previously operating with three teams. The goal of this change was to create smaller teams that can self-organize more easily, reduce coordination, and focus more effectively on their work.

With the introduction of the fifth team, we also extended the sprint duration from two to three weeks. The longer sprints give teams more time for cohesive development work, coordination, and review. At the same time, they reduce the relative overhead caused by frequent sprint transitions.

The teams continue to work in staggered schedules. This results in fewer workload peaks during sprint planning, sprint reviews, coordination, and other shared events. Key roles such as Scrum Master, Domain Product Owner, and the Chief Product Owner can therefore be integrated more effectively across multiple teams.

A special feature of our model is the rotating mid-sprint. At any given time, one team takes on bundled operational and preparatory tasks such as support, bug fixing, internal improvements, and preparing upcoming sprints. This allows the other teams to work more steadily toward their sprint goals. The rotation ensures that this responsibility is distributed fairly.

Compared to 2024, we were able to increase completed story points by an impressive 100 percent. For us, this is not the sole indicator of success, but it does suggest that smaller teams, longer sprints, clearer standards, and fewer context switches have improved delivery performance.

Since the introduction of Scrum in December 2009, we have continuously evolved our approach. Today, Projektron Scrum is no longer a one-time implemented process, but a matured model for multi-team product development. We do not follow Scrum as a rigid template; instead, we adapt its application wherever our product, organization, and release structure require additional clarity.

Key adaptations of our current Scrum model include:

These adaptations do not mean that we are replacing Scrum. Rather, they create the conditions under which Scrum principles such as transparency, focus, inspection, and adaptation remain effective even in a multi-team product development environment.

Not all of our earlier adaptations have proven successful in the long term. Some past experiments were discontinued because they were not practical enough for our needs. This regular inspection is part of our understanding of Scrum: the process itself must also be inspected and adapted. Our approach continues to be based on empirical process control: we make work, progress, and problems transparent, regularly inspect whether our processes are effective, and adapt them when they no longer fit our context.

Challenges of our Scrum model

Our Scrum model provides more structure, but it also introduces additional requirements. Especially in a multi-team setup, different working modes must be actively aligned: regular feature teams, the rotating mid-sprint, the specialized team, and multiple Domain Product Owners do not all follow the same routines.

A key trade-off lies in the balance between autonomy and overall alignment. Domain Product Owners need sufficient decision-making authority to effectively apply their expertise. At the same time, it must be ensured that their priorities align with the overall product strategy, release goals, and available capacity.

Process discipline also becomes more important. Clear standards, a defined DPO process, and binding rules for user stories, acceptance, and rework create reliability—but must be reviewed regularly to avoid unnecessary bureaucracy.

The additional complexity does not disappear; instead, it is made visible and actively managed. BCS supports us in transparently mapping requirements, budgets, responsibilities, and processes, helping to keep coordination manageable.

When is our Scrum model suitable?

Our approach is particularly suitable for organizations where multiple teams work on a shared, functionally broad product and where both planned product development and unplanned operational work must be handled continuously.

For smaller organizations or products with low complexity, this model is less suitable. If a single Scrum team with one Product Owner is sufficient, our approach would introduce unnecessary structure and coordination overhead.

As with Scrum in general, the context is what matters.

An important component is the mapping of our standards and processes. The DPO process is modeled in BPMN and defines when which steps are required, which decisions need to be made, and which stakeholders must be involved. Some process steps have since been automated.

This creates a unique feedback loop: we use BCS to coordinate our own product development. At the same time, the insights gained from our Scrum practice flow back into the further development of BCS. As a result, our software is not only used for Scrum but continues to evolve alongside our Scrum model.

Overall, Scrum has proven to be a flexible and effective framework in our software development, enabling us to continuously evolve a high-quality product like BCS. For us, the greatest benefit lies not only in agility, but in the combination of adaptability and structure.

Today, our focus is no longer on simply scaling Scrum to more teams. Instead, we are deliberately refining our Scrum model—with clearer standards, more reliable release planning, better support for Domain Product Owners, and stronger integration of our processes within BCS.

Our way of working directly feeds back into our product. What we need in our scaled Scrum practice flows into the further development of BCS. In this way, the product and the way of working evolve together.