What are some best practices for Scrum

Agile methods and Scrum - simply explained!

Nowadays everyone is talking about agile methods and especially Scrum in the corporate context. But often only a small part of the workforce has to deal with the new methods directly, be it through training courses or individual agile projects. The majority of colleagues have only a few points of contact. Since the methods are so often an issue, it helps to be able to juggle some terminology even as a colleague without an agile project, because inquiries tend to lead to embarrassed silence. I would like to give you a little help here. In the following there is a rough insight into the agile methods and Scrum, so that you can develop an understanding of Scrum in the future and classify the most important terms.

Agile project management: from waterfall to loops

But first of all: what are agile methods? This can best be explained in relation to the classic methods and a small example. Suppose you want to build a car. The classic methodology - or also Waterfall model called - is based on a long initial planning phase in which the project and the framework conditions are analyzed in detail and then the design of the car is detailed. Then the car is built and, at the end, it is tested whether the planned functionalities have been implemented. In situations with clear requirements and little uncertainty, the classic method offers an efficient route to a known goal. However, it is often not clear at the beginning which functionalities are exactly required. Or could you - without having seen the car - decide whether the front door length should be 1.10 m or, better, 1.40 m? However, you could only experience this product characteristic after the car has been completed. With the agile methods, exactly this challenge should be met.

The methods originally come from software development, but are now used in a wide variety of industries. In agile projects, the phases Analysis, design, development and testing run through several times in shorter loops (usually between 2 and 4 weeks) in order to make the complexity of the project more manageable. A product presentation is gradually sharpened through frequent feedback rounds with customers. That means, in our example, you could first design, implement and test the substructure of the car. This would be followed by another cycle in which the outer body would be built. As a result, the individual phases are shorter, you receive feedback more quickly and you can even open up changed framework conditions enter. Often situations and future influencing factors are unclear, so that new paths have to be explored and innovative approaches tried out at short intervals. In these cases there is no way to fall back on familiar techniques or best practices. The agile methods offer one here iterative approach on, i.e. the processing of a project in cycles.

Scrum: a first overview

Within agility there is now agile process models and Values ​​& principles. In this way, agility not only addresses specific operational issues, but also attaches greater importance to collaboration between people. The agile manifesto For example, it sets out various principles: reacting to changes is more important than following a plan. In addition, working with customers has a higher priority than negotiating contracts. Agile process models include, among other things Scrum and Kanban. In the following, Scrum will be examined in more detail as an agile process model.

Let's come back to our car example. It all starts with building a stylish and functional car as vision. The product vision is the target image towards which all activities are geared. However, the target image is still very complex and intangible, so it is divided into smaller, manageable packages. One can be guided by the question of who would like to use the car for what later. As a passenger on the back bench, for example, I would like to have enough legroom on long car journeys so that I can arrive safely on vacation. As a driver, I place more value on well-aligned mirrors to ensure a safe journey. The requirements of these users, which describe a certain functionality and its benefits, are also called User stories designated. With some prototypical users - too Personas called - a variety of functionalities can be recorded. For a better overview, the user stories can be thematically sorted in Epics - larger thematic blocks - are summarized. However, day-to-day work deals with the size / complexity of user stories and not with epics. These requirements are now included in a list and prioritized according to certain criteria. The added value of a requirement should be in the foreground as a criterion, but costs, resource availability, etc. also play a role. In Scrum, he takes over Product owner this task because he has the product vision in mind and can thus prioritize individual functionalities. As part of Scrum, the list of user stories is also made Product backlog called. The individual stories can then be written by a Development team implemented.

The process of a scrum loop

Over a certain period of time - the so-called sprint - the development work is focused on the most important entries in the product backlog. For this purpose, the development team sets up a joint meeting, the Sprint planning, determines which user stories from the general product backlog are to be implemented in the current sprint, and thus fills the sprint backlog. In addition, within this event, the user stories are divided into smaller tasks that are completed during the sprint.

A short update will be provided daily during the sprint (Daily Scrum) carried out within the team in order to synchronize the work and identify possible obstacles. At the end of a sprint, the results are shared with the customers and the product owner in the Sprint Review appraised. Here the Scrum Team receives direct feedback from the users. In addition, the Sprint retrospective the sprint process is analyzed and possible improvement measures are determined. This event is hosted by the Scrum Master moderated. Together with the product owner and the development team, it forms that Scrum team. The Scrum Master is an expert in the Scrum process model and supports the successful introduction and implementation of the process model. She keeps an eye on the methodological requirements and advises on operational activities. Here, however, not only the various events (retrospective, review, etc.) and role definitions (product owner, development team, etc.) have to be taken into account, but also possible conflict situations within the team and “externally”. After the sprint review and retrospective, a new sprint starts with sprint planning and a new loop begins.

Another essential aspect of Scrum deals with the principle of implementing a requirement as quickly as possible and then receiving feedback from customers. As soon as a first version of the product with the core functionalities has been developed, feedback from customers can be obtained. This first "simple" version is also called Minimum Viable Product (MVP), because a reduced but functional product is created here as quickly as possible. In each sprint, this product is then supplemented with additional functionalities. To achieve this, the user stories as sprint input on the one hand and the functionalities developed as sprint output on the other hand must be of a certain quality. The user stories are used during the Product Backlog Refinements concretized, estimated and prioritized based on their effort. As soon as they have certain quality criteria ("Definition of Ready“), They are accepted for implementation by the development team in a sprint. In relation to the sprint output: The functionalities developed by the team in a sprint are also subject to certain quality criteria ("Definition of done"). The aim here is to develop a set of functional extensions within a sprint that can be used directly by customers.

Need a little more input?

Finally, I would like to address an important concept in Scrum: appraisal. With Scrum, the effort involved in developing a user story is not specified in person-days or the like, but in Story points. These points are based on the relative estimates and therefore the comparison of different stories. Is one user story more or less complex than another? If a user story was rated with 5 points, should the current story receive more or fewer points? One methodology of relative estimation that the development team can use is Planning Poker. In this way, a large number of story points are “processed” within the sprint, which in one Burndown chart can be visualized. This allows the progress in a team to be made visible.

Have you now been able to get a first impression of the agile methods and Scrum? Would you like to have the terms of Scrum always at hand?

Glossary: ​​The most important terms at a glance

We offer here a glossary of the most important Scrum terms used in this article. These technical terms are explained in a comprehensible and well-founded manner and definitions are kept generally applicable. You benefit from our many years of experience with the use of the terms in various agile projects and can refer to the glossary in different contexts. Download the glossary and use it as a little spicker next to your PC. Or hang it up in your office as an overview for everyone to see. Your colleagues will thank you. Because even for colleagues who are experienced in Scrum, it is interesting to reread one or the other term.

Did you have any questions while reading or are you curious about the practical implementation? You are welcome to contact me for a non-binding conversation. I look forward to our exchange and look forward to your perspectives and experiences.

Stefanie Schuster studied cultural studies and business administration at the University of Mannheim. For three years she has been working as an IT consultant for various companies in the insurance industry. At viadee Unternehmensberatung AG, she supports her customers as a business analyst in project and process management. She is particularly interested in implementations in an agile environment and in successful communication and cooperation between various stakeholders. As part of process management, she deals with the technical modeling of business processes. For Ms. Schuster, the key points in IT consulting are listening to customers and understanding the challenges. Then a solution can be worked out together.