Always knowing what the customer wants with the agile project management solution Scrum

The solution – What exactly is Scrum?

Scrum requires the contractor and the ordering party to communicate regularly, at short intervals, in the form of feedback loops. “It works roughly as follows: Customers tell us what they want. We then define a period of time, referred to as the sprint, within which a particular sprint goal is to be achieved. What is important is that the end of each sprint yields a kind of mini version of what the customer has asked for. This version must be something that actually works and which the customer can then inspect. In this way, the customer can supply feedback at an early stage as to whether our development is progressing in the right direction or perhaps needs to be improved somewhat,” explains Jana Cervinka, Scrum master at PROMOS consult.

The mini versions provided are also referred to as increments and the procedure is based on the “minimum viable product” approach (see Figure 1). This approach offers the customer transparency regarding the current status and allows us to obtain their feedback early on so that we can take it into account in the next stage of development. Thanks to the ongoing comparison of the actual status with expectations, unnecessary developments are quickly identified, and the time saved can be invested in meeting requirements that bring real added value for the customer. As a result, subsequent change requests (CRs) for implemented features become unnecessary, meaning no costs are incurred in this way.

Those involved – Who has a role to play?

Scrum provides those involved in the project with a structured framework within which they can work step by step towards meeting the customer’s requirements. Amongst other things, this framework contains predefined roles that define the various tasks performed within the team. These include the roles of the product owner, the Scrum master and the developer team. The product owner has the goal of maximising the value of the product. He or she has overall responsibility for the product and decides what is to be implemented and when. This encompasses all the technical aspects of the project. He/she shields the team from outside enquiries and simultaneously acts as the contact person for the stakeholders. The Scrum master forms a link between the members of the Scrum team, aiming to increase efficiency by implementing the Scrum principles. To this end, he/she strives to optimise cooperation and establish an ideal working environment. Whereas the product owner decides what needs to be done, it is the development team who decide how to do it. This team’s main focus is on achieving the sprint goal. Cervinka explains the advantage of a clear division of tasks: “Shielded by the product owner, the team is able to work in a focussed and self-organised manner. A result that corresponds to the customer’s wishes can then be delivered very quickly.”

Product backlog – How and where do we compile the customer requirements?

In addition to the roles defined in Scrum, the framework structure also specifies “artefacts”. Cervinka explains: “Artefacts in the context of Scrum can be understood as work results. The most important artefact is the development result itself, which is available after every sprint. Another work result in Scrum is a type of logbook, which is kept in order to compile, prioritise and assess all of the customer’s requirements. This logbook, referred to as the product backlog, is a prioritised list of requirements that the product is expected to meet, and is continually extended and amended by the product owner. Using the product backlog, it is possible to accommodate customer wishes and also concentrate on the essential product features at all times during the project.” This way of thinking is supported by the way in which the requirements are formulated, which takes the form of user stories based on the following template: “As [role], I would like to [function] in order to [business value].” A user story in the area of product development in easysquare might read something like this: “As a tenant, I would like to register in the easysquare tenant app in order to view my operating cost statement.” The product backlog is not final and continues to develop over the course of the project (see Figure 2). The product owner regularly refines the user stories or modifies them in accordance with customer requirements.

Sprint planning – Do people really run in Scrum?

Depending on the project, a sprint has a constant duration of one to four weeks and begins with the sprint planning, a meeting in which the sprint plan is defined. The product owner presents the planned user stories for the upcoming sprint and the development team asks questions. In the course of the discussion, the user stories are fleshed out and the criteria for accepting the requirement are explained. Bearing in mind the prioritisation by the product owner and the complexity of the user stories, the development team decides how many user stories are to be included in the sprint plan. The user stories added to the sprint plan are final and are not changed during the sprint.

Daily Scrum – How do developers coordinate their work?

During the course of a sprint, the developers coordinate their work each morning in the daily scrum. They do so using the sprint task board, on which the current status of the development work is maintained. “When people think of software developers, they often imagine them working silently all by themselves. The meeting held every morning avoids such scenarios and allows the team to address problems, find solutions together and share the knowledge they have gained in their work. Our experience of applying this procedure has been entirely positive,” says Cervinka, looking back.

The sprint review – Have we achieved everything?

The sprint ends with the sprint review, in which the development team presents the user stories that have been implemented. The product owner checks whether the criteria for acceptance have been fulfilled and accepts the user stories. During the presentation, feedback on the requirements can be provided, which is then incorporated into the product backlog. “The sprint result – in other words the working mini version of the software – contains all user stories implemented to date and is made available to the customer,” says Cervinka.

Looking back – What can we do better?

After completing the sprint review, the Scrum team hold a retrospective meeting to reflect on the sprint. What has gone well and what can be improved? Positive experiences can be further enhanced in the future or may serve as orientation. If any problems have arisen during the sprint, those involved strive to analyse the causes and take measures to rectify or prevent these issues. The regular reflection on the product and the procedure applied at the end of each sprint lead to continual improvement in the project.

Conclusion – Everything hunky-dory with Scrum?

Scrum allows a reduction in the workload at all levels. As a result of intensively examining the customer requirements and getting the customer involved, the costs arising from erroneous developments are minimised. The product supplied to the customer then fully meets the customer’s requirements. Responding to changes is an integral part of Scrum, meaning that action can be taken promptly. The time gained is invested in developments that provide added value. Scrum is currently used at PROMOS in rental management, the app family and the EXAD 2.0 project.

redaktion@openpromos.de