Mad Glad Sad Retrospective

The Mad Glad Sad Retrospective is a format to gather data in the Scrum Retrospective meeting.

Here I am going to explain how you can use the Mad Glad Sad activity in your Retrospective meeting. I will describe in detail in which situations you should use it, how you introduce it to your team and what pitfalls you should look out for.

The Mad Glad Sad exercise clearly belongs to the second phase of the five phases of a Scrum Retrospective meeting. These five phases are:

  • Setting the stage
  • Gather data
  • Generate insights
  • Decide what to do
  • Close the Retrospective

If you are not familiar with these five phases of an Agile Retrospective then I recommend to first read my blog post series about the five phases of a Scrum Retrospective. This will help you to get an overview and set the Mad Glad Sad activity in context to the other parts of a Scrum Retrospective session.

Ok, now let’s get down to it.

Mad Glad Sad Retrospective

The goal of the Mad Glad Sad activity is to gather data about the sprint.

Within the gather data phase you go through following steps for the Mad Glad Sad Retrospective:

  1. Explanation
  2. Silent writing
  3. Assemble and group
  4. Pick a topic

Let’s have a look at each step in more detail.

Step 1: Explanation

You begin the exercise with an explanation. Therefore you draw a table with three columns on the whiteboard and name them Glad, Sad and Mad.

Then you explain the team that they should grab some sticky notes and write down silently what made them Mad, Glad or Sad in the previous sprint. They should use for each item a separate sticky note and only need to write down some keywords rather than full sentences.

You also tell them to take 3 minutes of time to write down the points. If somebody is done earlier they should stay seated and wait until everyone else is finished. This will help other people to not get interrupted in case they take a bit longer when writing down their points.

It is a good idea to put the columns Mad and Sad next to each other, because sometimes it is not clear whether a negative experience made you mad or sad. Therefore a person, who had both feelings about a certain event, can place the sticky note in the middle of those two columns.

Step 2: Silent Writing

3 minutes of silent writing is usually enough. But you can shorten or extend the time a bit depending on how many participants are already finished. This is usually just a gut feeling and changes from team to team and Retrospective session to Retrospective session.


If you know from experience that people tend to write down too many stickies, then you can limit the number of stickies per person.

For instance you can tell them upfront to create a maximum of five sticky notes. So they focus on the five most important items from the previous sprint.

On the other hand, if you are dealing with a non-active group you may encourage them to create a minimum amount of sticky notes. For instance, you can ask them that you would like to see at least three stickies per person.

And you can add, that you think that everybody in the group had at least three situations when he or she was happy or sad about anything at work.

In such a situation I also realized that most of the people just write down exactly three items. So, therefore I hardly ask for a minimum amount, because this often limits other persons to think further after they created three sticky notes.


I often get the question whether or not the scrum master should participate in the silent writing.

My opinion about this is the following: If I know the group very well and I was actively involved in the work of the sprint, then I do participate.

However, this is tricky, because it is hard to wear two hats at the same time — one as participant and another as facilitator. Therefore, in general I don’t participate in the activity and focus on the role as facilitator.

Step 3: Assemble and group

When everyone is finished you explain that everybody, one after another, should walk up to the board and put their stickies on the board. While placing the sticky note on the board the person should explain to the group what each sticky means.

Then you ask for a volunteer to start. If nobody is eager to start, just ask one random person whether he or she is up for it. Until now nobody said “No” to me, when I asked this question.

If there are similar topics, then these topics should be grouped together. You want to have the same thought on the board at the same place.

I have seen that sometimes people are very focused on their explanation and therefore forget to group similar topics together. That’s when you as the Scrum Master assist to cluster similar stickies on the same place.


People can ask clarifying questions when a person is explaining his or her sticky to the group.

However, the role of the Scrum Master is to make sure that these questions don’t trigger a whole discussion. For instance, when people are discussing reasons why a certain event occurred or even offer solutions, you just ask them politely to hold their horses.

At this point we just want to gather the data and we will pick the most important topic for a deeper discussion in the next step.


After a person is finished with putting their stickies to the board you thank them for their effort. It is important to value everyone’s contribution and also say it out loud in front of the whole group. This helps to build a good culture and encourages to really put effort in the exercise.

Especially when somebody gives constructive feedback or opens the door to discuss a sensitive topic it is fair to thank him for his honesty.

Because in the end this is exactly what you want to achieve with this exercise—talk in a safe team setting about the hidden conflicts within the team. And if somebody has the balls to start such an uneasy discussion the least thing the facilitator can do is to thank that person.

Step 4: Pick a topic

At this point we have all the ideas grouped by similar topics on the board.

Now you walk up to the board and give a summary by stating the obvious.

For instance, you describe that there are many stickies in the glad column and that this is in general a good sign.

Or you say that it is obvious that the major bug the team had in the software last week made a lot of people sad.

If there is a particular topic that stands out, then you decide that this is the topic you are going to pick for a more in-depth discussion in the group. In such a case there is no need to consult the team, but you take the decision for the team.

On the other hand, if there is no particular topic that stands out, then you can use dot-voting to select a topic.

Dot-Voting is a great tool to come to a quick, democratic decision about a certain set of options.

In this case the team should vote on what is the most important topic to discuss. And the topic with the most dots will win and will get discussed in more detail in the next phase.


First you explain to the group that everybody gets for instance three dots and can put those dots on the stickies on the board. People can put all their dots on the same topic or they can distribute them over multiple topics as they wish.

Therefore, everyone assembles in front of the board and places the dots on the stickies. This shouldn’t be done one after another, but rather at the same time. It is faster and keeps the energy level up.

Waiting time in a Retrospective meeting—or in any meeting in general—is bad and just distracts people. What happens is that they lose their attention and focus.

You also explain to the group that if they vote for a topic, which consists of multiple stickies that have been grouped together, then they should put the dots on the top-most sticky of that cluster.

In general it does not matter whether the dots are put on the top-most sticky or not, because it gives the same results as the votes are summed up. It is just easier for the Scrum Master to count the dots when they are on the same sticky.

When everyone has placed their dots, you ask the group to sit down again. Then you sort the stickies and put the topics with the most amount of dots to the top. While doing that you comment on what topics has the most dots and how many votes each topic got. This is just to keep the attention of the group.

At this point you created with the group a prioritized set of topics and therefore you complete the “Gather data” phase.

The next phase is to generate insights about the most important topic from your list. Use the Retromat to find some possible activities for the next phase or read this post to get some ideas.

Required tools

For the Mad Glad Sad Retrospective there are following items required.

First of all you need sticky notes—quite a lot of them, because you want to capture each thought on a separate sticky.

You might even bring stickies in different colors and instruct the team to use different colors for the different columns. For instance, green stickies for the Glad column, blue for the Mad and red for the Sad column.

Then you need a board where they stick. A whiteboard works quite well, but anything made out of glass is ok here. If there is nothing else, you can use the window as your board and place the sticky notes there.

Bring a set of markers instead of pens, because the group should be able to read the text on the stickies from a few meters away. Have at least one marker per person.

When to use Mad Glad Sad

The Mad Glad Sad Retrospective is a very well known and easy format and works in a lot of situations.

It works especially well, when you had a lot of unusual events happening during the Sprint, because then it generates a lot of results from different viewpoints of the participants.

However, if the team had a “boring” sprint without any special events, then this is not the recommended format. Because then there is nothing that made the team particularly mad, glad or sad and you will end up with some “artificial” results.

For instance, if the sprint was working out according to the plan, there was no downtime of the application, no serious bugs, , then what should you write on the stickies?

For such situations the Start Stop Continue Retrospective is usually a better fit.

However, you can steer the group in a specific direction by modifying the original question for the Mad Glad Sad session.

For instance, let’s say your team has a lot of dependencies with another team—let’s call it Team B. Team B is not delivering as planned and this results in a lot of blockers and frustration within your team.

As this is the biggest obstacle for your team at the moment, then in the Retrospective you can ask your team: What made you Mad, Glad or Sad in the cooperation with Team B?

This way you can steer your team and put the focus on a very specific topic instead of making it generic. This also delivers better results for the next phase.

Ok, that’s it for today.

Let me know in the comments, which format you prefer the most. When did the Mad Glad Sad Retrospective work out well and in which situation do you think it should not be used? Please share your thoughts below!

Well then, stay sharp and see you around. HabbediEhre!

Scrum Retrospective 5 – Close The Retrospective

This is the fifth and last post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 5— Close the Retrospective.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage.

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

In the previous four phases we have decided what we are going to do about the problems we identified earlier. Based on that we have created action items to improve our process.

Now, let’s finish off our Retrospective with the last phase.

Close the Retrospective

The goal of this last phase is to sum up the results of our Retrospective and generally leave a good feeling behind for the participants of the meeting.

Everyone should leave the room with the feeling that we achieved something useful and that the meeting was worth it.

How do we do this?

I usually take following steps:

  1. Sum up the results
  2. Perform a Retrospective of the Retrospective session
  3. Thank everyone and let them go

Step 1: Sum Up the Results

You want to recap the whole meeting in just a few sentences and remind everyone what problem we have tackled, how we are going to solve it and what we achieved in this meeting.

I keep this very short, like two or three sentences. And I use this recap as the introduction for the next step.

Step 2: Perform a Retrospective of the Retrospective Session

Here you would like to have an input from all participants what they liked about the Retrospective and what could be improved.

There are again a couple of different formats of how you can do this.

For instance, you can ask everyone to name one thing what they learned in this Retrospective. Then you give the word to each participant in the group. This way 

Another option is to ask everyone to write down on a sticky note the one thing they like and one thing they would change about the Retrospective. Then everyone, one after another, puts the stickies on the board explaining what they mean.

With these activities you generally put the team in a spot to celebrate the results of the retrospective. By letting everyone explain their feelings about the meeting you make the results even more important for the team.

In my experience this bonds the team closer together and adds to the team pride. At the end of this step the participants are mostly in a good mood and that´s exaclty how you want the people to leave the room.

Step 3: Thank Everyone and Let Them Go

At this point you can end the Retrospective and let the team go back to their work place and continue with their tasks.

Therefore your final step is to thank everyone again for their time and their effort and close the meeting.


Ok, now I have walked you through the five phases of a Scrum Retrospective.

Keeping these phases in your mind while planning your next Retrospective will give you an organized way of approaching and structuring the session.

The tips I have been describing for each phase should help you to become a better Scrum Master. And the suggestions in each section should help you to avoid some common pitfalls.

But there is a lot more to learn, when you want to become better in leading a Retrospective meeting. As menioned at the beginning of the post, I highly recommend the book Agile Retrospectives – Making Good Teams Great.

It contains a tremendous amount of useful experience provided by the experts Esther and Diana. They walk you through a virtual Retrospective meeting with a virtual team and give you a lot useful insights with many example situations you might face.

In addition the book also contains a list of possible activities for each phase. These activities will help you to keep your Retrospective meeting diversified. They will also help you to avoid that your team gets bored by doing the same activities over and over again.

I can tell you from experience that, when you have read this book, you will be much more confident when planning and hosting a Retrospective session.


Another great online resource to get inspired with ideas for activities for the Retrospective meeting is the Retromat. It contains more than 100 activities and they are categorized in those five phases. You can even choose from a couple of different languages.

The Retromat is a tool I use quite regularly when I plan a Retrospective meeting, because it gives me a lot of ideas for specific activities that can help my team to become even better.

If you know any other great resources that are helpful when preparing a Retrospective meeting, please share them in the comments.

Ok, that’s it for today. I hope you have enjoyed this series of blog posts about the 5 phases of a Scrum Retrospective.

Stay tuned, and HabbediEhre!

Scrum Retrospective 4 – Decide What To Do

This is the fourth post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 4— Decide What To Do.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

Until now we have covered the first 3 phases. After Phase 1—Setting The Stage we spend a considerable amount of time in Phase 2—Gather Data to identify the most crucial problems of the team.
Then I covered Phase 3—Generate Insights in my previous post. At the end of that phase we had a list of possible root causes and potential solutions for a problem.

Now, let’s go on with Phase 4 and decide what we are going to do about the problem.

Decide What To Do

The goal of this phase is to create action items to improve in the next iterations.

You identified a list of possible root cause of the problem and potential solutions. Now you want to decide what you want to do differently in the next Sprint.

Therefore you create a list of action items what you exactly want to do differently.

When creating action items there are a couple of things you want to keep in mind:

  1. Make action items actionable
  2. Make action items small
  3. Don’t pick too many action items
  4. Make action items visible

Let’s look at each bullet point of this list a bit more closely.

1) Make action items actionable

You want to phrase your action item in a way that it is completely clear what needs to be done. Be as specific as possible. It shouldn´t require a discussion with the team whether an action item can considered to be completed or not.

An example for a bad action item is “Improve team collaboration”. Phrasing it like this does not tell you what you need to do exactly. It leaves a lot of room for interpretation.

A better example would be “Pair programming on Monday and Wednesday from 10:00 to 12:00”. This tells you exactly what you need to do and when you need to do it. And only if you have really worked together in pairs for those two hours it is clear to everyone in the team that you can mark the action item as completed.

2) Make action items small

You want to make action items small enough so that they don´t have an impact on the amout of planned work for the upcoming Sprint. At this point in the Retrospective you don’t want to commit to work on a big action item.

Planning and prioritizing is done in Sprint Planning, but not in the Retrospective meeting.

If the action item requires a couple of days effort to be completed, then it is definitely too big.

For instance, “Implementing 2-factor authentication for the web application” is too big for an action item of a Retrospective.

If your team is sure that they want to work on that with high priority, then the action item might be “Create a user story for 2-factor authentication and put it on top of the backlog”.

Big action items contain the risk that they are not worked on or cannot be finished in the Sprint. Or something else might be considered more important in the next Sprint planning.

If that happens regularly, then your whole Retrospective meeting has become just a meeting where you commit to things you wish to improve instead of actually improving them.

Having small action items makes sure that they will be completed. Then your team will be consistent in making sure that action items are always finished.

3) Don’t pick too many action items

If you have too many action items it is likely that the team will forget about some of them. It is easy to remember 3 things, but it is a lot more difficult to remember 7 or even more things.

Therefore I make sure that my team creates a maximum of 3 action items per Retrospective so we can keep the focus on the few most important items.

4) Make action items visible

Another method, which proved to work very well, is to make action items visible to the team.

You place the stickies with the action items at a place where the team can see them. Usually I put them on the physical scrum board, which is at the team area. Additionally, you can use some “screaming” colors, like pink or orange, so that they stand out on the board.

Then, a couple of days after the Retrospective meeting, when you see that an action item is not marked as done yet, you can ask the team during Standup about the status. You make the action item “visible” in their mind by pointing it out during the Standup.

So, by making the action items visible to the team in different ways, you can do your best to make sure they will be worked on and completed until the end of the Sprint.

Try-Measure-Learn Loop

There is one more important thing, which you should keep in mind when creating your action items:

Make clear to the team that you are dealing with complex problems here.

Each problem does not have just one root cause and exactly one solution. There might be a combination of circumstances, which lead to your specific problem and therefore there are also multiple things you need to do in order to solve it.

So mostly there is not one obvious thing what you can do to fix the problem. Make clear to the team that Scrum is an empirical approach—you are working with a try-measure-learn loop.

If you have identified a possible solution, you cannot be sure whether this solution might really work. But you can decide to give it a try for a couple of Sprints and measure its outcome.

Then based on what you measure you can learn that this is a good solution and you keep it. Or you might measure bad results and decide to drop that solution, because it didn’t help to fix the problem.

If this is not clear to people, I noticed that some respond very negative to certain action items.

For instance, imagine you have a big issue and you have an action item to tackle that problem. Then, one simple action item is often just a drop in the ocean. This means that even if it is completed it will not have a big impact.

Therefore it is not surprising that some people will react like “That’s not gonna help anyway! We are just wasting our time here with trying to solve a problem we cannot tackle anyway”.

So, making clear to the team that we are working with a try-measure-learn model is a good way to make clear that this is just the first step in the hopefully right direction. This might shift their mind to a more positive attitude regarding the created action items.

Last Step

Ok, so at the end of this phase we have created a few, small, actionable items to improve our process. Now we can continue with the last phase.

You find continue reading about the last phase here: Phase 5—Close the Retrospective.

Meanwhile, if you have any additional remarks about action items, then please share them in the comments section below.

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 3 – Generate Insights

This is the third post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the Phase 3— Generate Insights.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage.

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

We have covered Phase 2 —Gather Data in my previous post. At the end of that phase we had a list of subjects for further discussion.

Now, let’s go on with Phase 3 and generate some insights from those subjects.

Generate Insights

The goal of this phase is to dive deeper in at least one of the subjects from the previous phase. We want to uncover the root cause why certain things happened. And then we want to find options for a possible solution.

We can split this phase up in two steps.

At first we decide which particular subject we want to select. So we have a focus point on one specific subject rather than talking about multiple topics at the same time.

In the second step we dive deeper into the selected subject to find the root cause.

Step 1: Decide for a subject

The decision, which is the most important or valuable subject to pick is sometimes obvious. Often there is a topic, which bothers the team the most. So you as a Scrum Master will obviously decide for that particular subject.

For instance, if the application, which is managed by the team, had a big outage during that sprint, then this is probably the most important topic for the team.

In case the team didn’t already have a separate Blameless Post Mortem for that outage, you as the retrospective leader will obviously decide for that topic.


But sometimes it is not so obvious. In such a situation I usually make a pre-selection of possible candidates and then ask the team to vote.

The pre-selection is just done to make the voting easier, because there are often some subjects that you don’t need to dive in deeper.

For instance, if somebody mentioned that he is so happy that he finished his Professional Scrum Master certification, then this is really great to share within the team. But you probably don’t want to dive deeper into that subject.

After the pre-selection I usually use dot-voting, which works as follows.

Everybody gets a set of virtual dots and can place them on the sticky notes on the board. The sticky note with the most dots wins.

For instance, everyone gets 3 dots. Then they can go to the board with the sticky notes and place their dots there. Afterwards you count the dots and the topic with the most dots will be selected.

Ok, now as we have a selected topic, we can dive deeper.

Step 2: Dive deeper

The goal of this step is to find the root cause of the selected problem.

There are different activities to get to the core of a problem. The retromat can help you to find a lot of possible activities.

My favorite options are to have a discussion with the team or to use the 5 Whys activity. Let’s have a closer look at both of these options.

Facilitating a discussion

Having a focused discussion on a specific issue is a very natural and simple approach.

I have made the experience that people, especially very analytical persons like software developers, don’t like to participate in “weird” activities. One developer once asked me why we are doing these “Montessori” games while we could use our time much more effectively by writing some code.

So I tend to keep the amount of unknown activities low—especially with a team, which is not very familiar with retrospective meetings. Therefore just having a discussion feels very natural to everyone involved, because you have discussions all the time. And a good discussion can create very good results as well.

In order to have a good discussion you need some facilitation skills.

During a discussion some people might be very outgoing and talking and talking and you can hardly stop them. Some other people like to stay in the background and don’t say much. They just give their opinion when you ask them directly.

As a good facilitator it is your job to notice such behavior and do something about it.

For instance, you might interrupt the talking Mary and throw the ball to introvert Tom like this: Thank you Mary for your opinion. Now, Tom, you didn’t say much. What do you think about it?

Another thing I tend to do during discussions is to make some notes about the most crucial points that are discussed. I try to identify possible reasons for problems and possible solutions.

Then I put them on the wall, so the group can use that information in the next phase to take a decision.

To be honest this is very hard to do. Because on the one hand you need to facilitate the discussion and on the other hand you should make notes.

While practicing you will get better over time, but at the beginning I think it is not necessary to make notes. It is more important to properly facilitate the discussion.

Ok, so having a good discussion is a nice way to find the core of a problem. Another option to achieve the same result is the 5 Whys activity.

5 Whys

The 5 Whys activity is a method to drill down to a problem by repeatedly asking Why?

The name comes from the fact that often you often find the root cause of a problem with the fifth answer.

For example, let’s imagine the team struggled with an outage of their product during the sprint. And we want to identify the root of the problem with the 5 Whys activity.

Why was there an outage? Something went wrong during deployment and so the application didn´t start anymore.

Why went something wrong? Because Tom, who started last month, made a mistake. He did it the first time and didn´t have the experience.

Why did he do it the first time? Because Mary was on holiday so somebody had to do it. Unfortunately he didn’t get a proper training before that.

Why was there no training? Because it is not part of the onboarding process.

So we identified the root cause of that problem. And the solution might be to add a proper deployment training to the onboarding process.

So by repeatedly asking Why? you can drill down to the core of a problem. And after identifying the root cause you can look for possible solutions.


Ok, let’s quickly recap the important things of the Generate Insights phase.

The goal of this phase is to drill down to the root cause of a specific problem and find possible solutions.

In the first step we decide on a specific subject, which we want to analyze. For instance by using dot-voting.

In the second step we dive deeper. Among a list of possible options I prefer to have a discussion or use the 5 Whys activity to get to the core of the problem.

When you are done with one problem and there is enough time left for your retrospective you can also try to tackle another subject.

Ok, so at the end of this phase we have analyzed the root cause of at least one specific problem. Now we can continue with the next phase.

You can read about the details of the next phase here: Phase 4—Decide What To Do.

Meanwhile, let me know in the comments about your favorite activities for the Generate Insights phase. Maybe you have something you absolutely love to practice with your team?

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 2 – Gather Data

This is the second post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the most crucial ideas for Stage 2—Gather Data.

If you haven´t read the previous post in this series you can find it here: Stage 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

Ok, let’s get to the meat.

Gather data

The goal in this phase is to bring the facts of the sprint to the table, so that every participant has the same picture of what happened during the iteration.

I usually split this phase up in two steps. First I announce the hard facts and statistics based on the data the team generated during the sprint. Secondly, we want to get the insights and personal opinions from each individual to generate a complete picture.

Step 1: Hard facts

The idea of this step is to make the status quo transparent, based on the facts you already have. This type of data is usually generated during the sprint and does not reflect any personal opinions, but hard facts.

It is the responsibility of the Scrum Master to get this information before the meeting starts. Even though the Scrum Master doesn’t have to get the data by himself, he is responsible to make sure the data will be available for the meeting.

This data includes: the sprint goal and the amount of planned and delivered story points. Next to that it also includes any other hard facts, which are measured during the sprint.

Sprint goal

First of all I name the sprint goal and we figure out whether we did achieve our plans. Most of the time it is obvious whether or not we made the sprint goal, but sometimes there is a short discussion within the team. This is fine, because I want a collaborative decision if we did or did not make it.

I use this information also to keep track of how the team is doing over time. And you can mention in the retrospective that the team achieved the sprint goal for instance 5 times in a row.

Story points

I mention how many story points we initially planned for the sprint and how many were successfully finished.

Here it is a good idea to have an excel sheet with historical data prepared and show in a graphical overview how the team is doing over time. Keeping this historical data in a diagram can give you insights easily in how the team grows over time, is more productive, finishes more work etc.

Other measured data

You can mention at this point any other important data, which has been measured during the sprint.

For instance, if your team struggles with too many open bugs and too little of them are solved and closed during the sprints, then this is important data to keep track of. This data is usually available easily by having a look at the bug-tracking tool you are using.

In such a case you can announce the amount of open bugs before and after the sprint.

If your team has constantly problems with the high amount of incidents during the sprint, which prevents the team from making good progress with the planned user stories, then this is also important data to keep track of. This data is also usually available in a bug-tracking tool and you can bring this data to the group here as well.

Basically any interesting data, which is measured and might be important to the team, is welcome at this point to share with everyone. This is because it helps that everybody has the same picture of what happened during the sprint.

Data you don’t want to show

But there is also some type of data, which you don’t want to show to the team. This is any kind of data, which might put a specific person on the spot—unless you specifically intend to do so.

For instance, showing how many story points were delivered by each person brings the lowest-scoring person in an uncomfortable situation and doesn´t help the team. Therefore this should be avoided.

You should also make sure to just bring data, which has been measured and therefore is a fact. Don´t bring data, which you think is a fact, but actually is just your personal opinion.

For instance if you know that people didn’t do as much pair programming as initially planned, but you didn’t measure how often they actually worked together in pairs, then don’t mention it at this stage.

At this point it is important to just give the hard facts, which have been measured, to the team so that everyone knows what was going on in the sprint.

Step 2: Personal opinions from each individual

When the hard facts are on the table, the second step in the Gather Data phase is to collect the personal opinions and feelings of each individual.

Here it is important that everyone has a voice. Therefore I always use a format, which gives each individual some time to think on his own and express his or her own opinion.

Silent writing

In order to achieve this I always use a couple of minutes of silent writing, where each person writes down the items on sticky notes. So everyone has to think about his or her own experience, feelings and events during the sprint.

If you don’t use sticky notes, but just start a discussion where everyone shares his or her thoughts, then you usually end up with a very unbalanced set of data. Because more confident people will take over the floor and express their opinions while other participants won´t be able to contribute their thoughts.

Especially if there are a few introverts in the team, these people are not going to speak up while for example the senior developer taking over the floor. Even though the opinion of the introverts might be very valuable, they want have the chance to contribute them to the discussion.

Therefore, for the gather data step I always use a format, which starts with a few minutes of silent writing followed by a round of explanation, where each person explains his or her stickies to the group.

Formats for the gather data step

There are many different formats for the gather data step out there, which basically all work the same way with just slight differences in asking the questions. For instance, there is the Start Stop Continue format, or the Mad Glad Sad retrospective, or you can use the Sailing Boat.

Some of these formats work better than others in different situations. For instance, if the sprint went really well and there is almost nothing to complain, then the Start Stop Continue retrospective is a good way to generate some ideas for improvements.

If you use the Mad Glad Sad retrospective to gather data when a sprint worked really well, then it will basically work, but in my experience you will get much better results using the Start Stop Continue format. If you want to know more about that check out my post about the Start Stop Continue retrospective.


Ok, let’s quickly recap the important things of the Gather Data phase.

The goal of this phase is to bring all relevant data to the table so that every participant has the same information about the sprint.

This data consists of the hard facts, which have been measured during the sprint. These are the Sprint goal, the amount of planned and delivered story points and any other relevant facts, which have been measured.

The second step is to get the opinions and feelings from each individual by a few minutes of silent writing. After that each individual presents them to the team and clarifies what he means.

At that point you have all the important data ready and can continue with the next phase, which is Phase 3—Generate Insights.

You can read about the next post in this blog post series here: Phase 3—Generate Insights.

Meanwhile I would be interested in formats you mostly use to Gather Data in your Scrum retrospective. Leave a comment if you have any interesting insights, which formats work well in specific situations!

Ok, that’s it for now. See ya in a bit, and HabbediEhre!

Scrum Retrospective 1 – Setting The Stage

This is the first post of my blog post series about the five phases of a Scrum Retrospective. I will cover the most crucial ideas for Phase 1 — Setting the stage.

These five phases are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Setting the stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each of the retrospective meetings, which I lead as a Scrum Master.

In this post I will explain what the leader of an agile retrospective needs to know and should do in order to have a successful start of the retrospective meeting.

Setting the stage

The goal of the first phase is to bring the mind of the team to the retrospective meeting so they have their focus on the work at hand.

You want to set an environment where everybody feels save to speak. Everyone should be in a state that he feels like he wants to contribute his thoughts and ideas as much as possible.

People have been working on other tasks just a few minutes ago before they had to stop and go to the retrospective meeting.

Their mind is still filled with the thoughts of their previous task. For example, one colleague might still be thinking hard on how to solve that bug he is currently working on.

The goal for you as the leader of the meeting is to bring the focus of the team to the work at hand.

What, Why, When

In order to set the stage for the meeting you are starting with a short introduction giving some facts about the meeting itself.

You mention the goal of the meeting, which is to reflect on the previous sprint. And you announce the available time for the meeting, giving the participants an outlook on what they can expect how long they will be locked up in this meeting room.

For instance you might say something like this:

Here we are again at the end of our sprint—this time we completed sprint number 56. Let’s look back together and figure out what went well and what didn´t so we can improve our process and become even more productive. Now it´s 4 minutes past 2, so we have exactly 56 minutes to come up with some results.

After this announcement you should have the groups attention.

I learned that there is another important part of Setting the stage, which is to get everybody to say a few words.

Get everybody to speak up

At the start of a retrospective it is important that everyone says something out loud. If you speak out loud at the beginning of the meeting the chance that you are going to join the follow-up discussion increases drastically.

I couldn’t find where I have read about this fact, but I remember that it was packed with some awesome statistics. Since then I always perform this little exercise at the beginning of a meeting.

There are a couple of possible activities in order to give everyone the chance to speak up.

I usually just ask a simple, open-ended question and ask the people to answer shortly one after another going around in a circle.

The question might be: How do you feel about the previous sprint on a scale from 1 to 5?

Another example is to ask the participants to state in one sentence what they want to get out of this retrospective meeting.

And another example might be: Tell us how you feel about the previous sprint in maximum of 3 words!

The retrospective leader has to make sure that the statements are really short, which means just a few words. You want to avoid that people start a discussion at this stage. You just want to get everybody to speak up to generate the mind-shift and enable maximum contribution of everybody in the next phases.

When everyone has put some thoughts to answer the question then the group should have the focus on this meeting. Everyone has put his previous task on hold and put his attention to the work at hand. The mindset of the group is in a state of getting some work done.

Next: Phase 2

At this point you are finished with Setting the stage and you move forward to the next phase, which is: Phase 2—Gather data.

You can read about the next post in this blog post series here: Phase 2—Gather data.

Meanwhile I would be interested in how you kick-off your Scrum retrospective meeting and what you do differently. Do you have any interesting insights, which you can share in the comments?

Ok, that’s it for today. See you in a bit, and HabbediEhre!

Scrum of Scrums

The Scrum of Scrums is a meeting on inter-team level with the purpose to surface dependencies between teams and align their collaboration.

In this article I would like to give you insights on how we implemented Scrum of Scrums at LeaseWeb.

I am going to show you a practical example.

I am not going to tell you about the theory behind it, because you can find such information in other places on the Internet.

I want to give you some practical insights on how Scrum of Scrums can be implemented, what tools we are using and the benefits and downsides we get out of it.

However, before we start, I would like to explain in a few sentences what Scrum of Scrums actually is.

Scrum of Scrums

The Scrum of Scrums has a similar purpose as the daily standup in a Scrum team. The difference is that the Scrum of Scrums is done on an inter-team level. This means, that a representative of each Scrum team is joining the Scrum of Scrums.

Similar as in the daily standup of a Scrum team, in the Scrum of Scrums each team representative has to answer three questions:

  • What impediments does my team have that will prevent them from accomplishing their Sprint Goal (or impact the upcoming release)?
  • Is my team doing anything that will prevent another team from accomplishing their Sprint Goal (or impact their upcoming release)?
  • Have we discovered any new dependencies between the teams or discovered a way to resolve an existing dependency?

If you want to learn more about the Scrum of Scrums, then I recommend to have a look at the Scrum@Scale guide. That´s also the place where the three questions come from.

The Scrum@Scale guide has been published recently (February 2018) by one of the fathers of Scrum, Jeff Sutherland.

This is definitely a good starting point to learn more about scaling Scrum.

Ok, let´s have a look on how we implemented Scrum of Scrums at LeaseWeb.

Scrum of Scrums implementation

I have been working at LeaseWeb for a couple of years. To give you a more practical insight, I would like to explain how we implemented the Scrum of Scrums at LeaseWeb.

12 Scrum Teams

At LeaseWeb there are 12 Scrum teams. Each team is responsible for a certain service or product and naturally there are often dependencies between the teams.

For instance, when building a new feature a couple of teams might be involved and have dependencies with each other. To realize the new functionality several teams have to make changes in their product. Therefore close collaboration is required. And that´s why Scrum of Scrums has been implemented.

Big board in the hallway

We have a big board in the hallway, where everyone can see it when walking by. So, if people from other departments are interested what the development teams are currently working on, they can have a look at this board.

And the board is really big, actually it is a whole wall. If you want to know the dimensions, then I would say it is about three meters high and six meters wide. It is quite an impressive view when you enter the floor of the development department.

The board is basically a big table with columns and rows. There are columns for the current sprint n, the next sprint n+1, sprint n+2 and sprint n+3. In addition there are also columns for the next  months and the next quarter.

While the columns are used to display the time, each team gets a separate row in the table and fills it with cards.

The cards

The cards contain information on a high level on what each team is doing the current sprint as well as what the teams are planning to do in the upcoming sprints.

The level of detail is higher in the current sprint and obviously decreases the more you plan in the future.

So it is totally fine to just have one card in the next quarter column, which has for instance promo written on it. This should indicate that the team plans to work on a promotion feature in the next quarter. But it is important to understand that this is the high-level plan from todays perspective. It is not written in stone and it might change – in fact it is very likely to change, because it is very difficult to plan ahead for such a long time.

However, the team should have a more detailed plan on what they are working in the upcoming sprint, especially if they have dependencies with other teams. So they can coordinate and resolve those dependencies as good as possible.

But even though the plans might change in the future, it is good to have the card on the board, because it triggers discussions with other teams and stakeholders on what is the most important thing to work on and where do we have inter-team dependencies.

The cards are magnetic and stick on the board. You can write on them with a whiteboard marker and after cleaning you can reuse them again. We also use different colors for different projects or epics. You can find those magnetic cards on Amazon and also the lines you can use build the table on the board can be found here.

 The Scrum of Scrums meeting

The Scrum of Scrums meeting itself happens once a week and is timeboxed to 15min.

A representative of each team explains what the team is doing in the current sprint and the plans for the upcoming sprint – answering the three questions, which I mentioned above. As there are 12 teams it is crucial to keep it short and don´t get into details.

In general, the focus during the explanations are the dependencies with other teams. All other details are left out.

In case there are no dependencies with other teams, then the most important goals of the team are mentioned. I usually name the sprint goal of my team there as well. Nonetheless, as I already said, the key is to keep it short.

If there are any questions during the explanation, then those are answered right on the spot, if the answer is short. In case the answer needs a more detailed explanation, then the answer is postponed after the Scrum of Scrums and people, who are interested stay after the end of the meeting to hear and discuss the details.

If the answer triggers a discussion during the Scrum of Scrums, then any of the present Scrum Masters is allowed to interrupt the discussion, and asks the participants to discuss the topic after the meeting. That´s how it is possible to keep the timebox of 15min – even though there are 12 teams.

Benefits and downsides

Let´s start with the downsides of having a Scrum of Scrums meeting.

Well, everyone is busy with his own work and has a tight schedule and there comes another meeting what you have to attend. And even though it is just 15min you need some time to prepare the board. In addition, you need to interrupt your normal work and therefore also loose some focus time, because of the content switch – before and after the meeting.

    But next to that there are also quite some benefits of having the Scrum of Scrums in place.

First of all, having this formal process in place, which forces you to think and explain what you are working on and what you are planning to do.

    And just by that you might encounter impediments with other teams earlier. So you are able to work on resolving them, before those impediments become a blocker within your team. This is going to save your team a lot of hassle, nerves and time.
    Another great benefit is that you hear what other teams are working on.

And you might have better insights why they are not able to work on the tasks your own team depends on.This gives you a better understanding of the overall direction the whole department is going and the goals the teams are working towards.

The Scrum of Scrums also fosters collaboration between teams.

I recall multiple occasions that after the meeting I went to other teams to ask for their help or somebody came to me with information I didn´t know yet.

For instance, my team planned to work on a new backup solution, which I explained briefly during the meeting. Afterwards another Scrum Master poked me and told me that his team already has something similar in place.

Finally, the two teams ended up working together on a solution and with the knowledge provided from the other team it was way easier for my team to implement a good solution.Without the Scrum of Scrums we would have probably worked on it by ourselves and present the solution after the sprint. And only then we would have figured out that we already had the knowledge and infrastructure in the department and we just did the work twice.


In this article I gave you an overview on how we implemented Scrum of Scrums at LeaseWeb. I have explained what tools we are using and what benefits and downsides we get out of it.

Do you have Scrum of Scrums in place in your company as well? What are the differences compared to the implementation at LeaseWeb?

Or you don´t have Scrum of Scrums in place in your company yet and you plan to implement it? Let me know how it works!

Ok, that´s it for today. Stay tuned and HabbediEhre!

Nexus – the scaling Scrum framework

Nexus is a framework, which builds on top of the scrum framework and is designed for scaling. It focuses on solving cross-team dependencies and integration issues.

What is Nexus?

The Nexus framework has been created by Ken Schwaber, co-creator of the Scrum framework.

Similar to the scrum guide, there is also the Nexus guide, which contains the body of knowledge for the framework.

It has been released by in August 2015.

You can find the definition of Nexus in the Nexus guide as follows:

Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus framework is a foundation to plan, launch, scale and manage large product and software development initiatives.

It is for organizations to use when multiple Scrum Teams are working on one product as it allows the teams to unify as one larger unit, a Nexus.

Scrum vs Nexus

Nexus is an exoskeleton that rests on top of multiple Scrum Teams when they are combined to create an Integrated Increment.

Nexus is consistent with Scrum and its parts will be familiar to those who have worked on Scrum projects.

The difference is that more attention is paid to dependencies and interoperation between Scrum Teams.

It delivers one “Done” Integrated Increment at least every Sprint.

New Role “Nexus integration team”

The guide defines a new role, the nexus integration team.

It is a Scrum team, which takes ownership of any integration issues.

The Nexus integration team is accountable for an integrated increment that is produced at least every Sprint.

If necessary, members of the nexus integration team may also work on other Scrum Teams in that Nexus, but priority must be given to the work for the Nexus integration team.

Event “Refinement”

In Nexus the refinement meeting is formalized as a separate scrum event.

In the cross-team refinement event Product Backlog items are decomposed into enough detail in order to understand which teams might deliver them.

After that dependencies are identified and visualized across teams and Sprints.

The Scrum teams use this information to order their work to minimize cross-team dependencies.

Event “Nexus Sprint Planning”

The purpose of nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint.

Appropriate representatives from each Scrum team participate and make adjustments to the ordering of the work as created during Refinement events.

Then a Nexus Sprint Goal is defined, an objective that all Scrum Teams in the Nexus work on to achieve during the Sprint.

After that the representatives join their individual Scrum teams to do their individual team Sprint Planning.

Event “Nexus Daily Scrum”

The Nexus Daily Scrum is an event for appropriate representatives from individal Scrum Teams to inspect the current state of the Integrated increment.

During the Nexus Daily Scrum the Nexus Sprint Backlog should be used to visualize and manage current dependencies.

The work identified during that event is then taken back to individual Teams for planning inside their Daily Scrum events.

Wrap up

This is a very highlevel overview about Nexus, you can find more information in the Nexus guide or in this nice introduction.

I am practicing Scrum for quite a while now, but I have never heard about Nexus before. Only last week I stumpled upon it on the Internet.

Therefore I also don’t know anybody who is actively using the Nexus framework in their daily work.

But from this point of view it looks like Ken Schwaber did a very good job again when defining this framework.

I hope that I will have the chance some time to work with Nexus in real life. Of course, for that you need to have the environment where it would make sense to give the Nexus framework a try.

Ok, that’s it for this week. Have a good day and HabbediEhre!

Acceptance criteria – an easy way of defining scope

Acceptance criteria are a straight-forward way of describing, what needs to be in place before a task can be marked as done.

You might have experienced the following situation: you are in a refinement meeting and you just finished discussing a certain task. Now the team is about to estimate the effort of the task using planning poker: The poker cards for estimation show values between 3 and 13 story points!

So some people in the team think the task is more than four times as much effort to implement than other team members.

Discussing the estimation difference the team realizes, that team members had a completely different scope of the task in their head. That’s why there were such big differences in the estimation.

Unclear scope of task

I have been in many discussions, where people talk about what is the scope of a certain task. Although the description of the task is long and detailed, it is not clear what exactly needs to be delivered as part of the task.

This is especially uncomfortable, when the discussion is started during the sprint by the person, who is working on the task. Is this also part of the task?

When somebody creates a new task in the backlog, then this person has his own view on the topic. Sometimes the description is just 1 sentence and sometimes it is a whole page. Coming up with the right amount of description is not easy.

Problem of task description too short

When creating a task some people try to keep the description of the task as short as possible. They think that only the members of the team have to understand the scope of the task. And as the team will discuss the scope of the task in a refinement meeting, the details will be talked through anyway. So there is no need to have a detailed description, right?


Not all people are always present in those meetings, team members might be on holiday or are just not paying attention. Or it is also completely normal that people might forget about some details of scope discussions.

Therefore writing down the most important things in the task description is clearly a must for a proper backlog item.

Problem of task description too long

Then there are some people, including myself, who tend to write too long descriptions of tasks. The idea is to make the scope of the task understandable to everybody, even for non-technical people. This results in a long text, explaining the purpose, dependencies to other teams, things, which are out-of-scope, etc.

The problem is, that it is not clear what is part of the task and what is just there for clarification. Different people might interpret the description differently, because they have different backgrounds. And some people might not even read the description, because it is too long.

Finding the right balance of clear-enough description versus too-detailed description is not simple.

Adding acceptance criteria to a task

On top of having a title and a description, you can also add acceptance criteria to a task.

Acceptance criteria is a list of conditions, that a software must satisfy to be accepted by the stakeholders.

They define what a software should do, without specifying implementation details. So they don’t state how the software should do it, but only what the software should do.

Acceptance criteria should be relatively high-level while still providing enough detail to be useful.

They should include functional criteria, non-functional criteria and performance criteria.

Functional criteria

Functional criteria define how the software should work. It define the business processes in a software. For instance “the user can search servers by brand and type“.

One format for defining functional criteria is the Given/When/Then format:

Given some precondition When I do some action Then I expect some result.

Non-Functional criteria

Non-functional criteria define conditions for non-functional requirements. For instance, “the search button complies with the design of the search button on the front page“.

Performance criteria

In case performance is critical, then adding criteria defining performance thresholds make sense. For instance, you can add requirements for the maximum response time of a certain API call.

Benefits of acceptance criteria

Acceptance criteria make it clear in just a simple and usually short list of conditions, what should be done as part of the task. Therefore they are very helpful for the team to understand the scope of a task.

You can see the benefits of acceptance criteria during refinement meetings. Everybody is on the same page, when it comes to the estimation of the task.

Next to that, acceptance criteria are also very helpful for the tester. They make the job of the tester a bit easier, because he/she has a starting point on what needs to be tested.

Disadvantage of acceptance criteria

The downside of acceptance criteria is that everyone might rely on that list made by the creator of the task, without rethinking if the list is correct or complete.

If you don’t have acceptance criteria yet, then just give it a try for a few sprints and see how it goes.
In my experience it helped the team to make tasks much more clear, with just a little bit of more effort during the creation of the task.

Ok, that’s it for today.

I’m curious if you define acceptance criteria for each task and whether you find them helpful or just overhead. Let me know in a comment!

Stay tuned and until next week. HabbediEhre!

Scrum does not work for us

Coming up with a good estimation for a complex task is possible – even if you don’t know the possible options to complete a task.

We tried scrum in our company, but it does not work for us. Our tasks are so complex and unpredictable, that a single task estimated for two hours might take even two weeks to finish.

Do you think like this as well? Or did you hear such arguments from other people?

Recently I went for a beer with my houseboat neighbor and we ended up talking about work. He is a physicist, works in research and has his own company. Actually, he is building a simulation software to simulate the behavior of certain fluids under high magnetic fields.

We also talked about scrum and he told me, that they try to use scrum in their daily job as well, but it does not work for them.

Everything they do is completely new. It is very likely that nobody else has ever done those things before. That’s why you cannot estimate or predict how much effort such tasks will take.

He said: “It can take two hours, or it can also take two weeks!”

This triggered me to think: where can you apply scrum and for which type of work does it not make sense?

Well, this question reminded me on the Stacey complexity model, which says scrum works for all complex tasks.

So, scrum does definitely work also for those type of tasks.

In fact, the real question to this problem is: Why is estimating the effort so difficult for complex tasks?

What is a complex task?

The reason why some tasks are considered to be complex is that it includes a lot of unknowns. You have no clue on how to accomplish the desired result.

You probably have multiple options to choose on how to solve the problem. And you don’t know, which one is the best.

Or, even worse, you might not even know, which different options you have.

Refinement meetings

So what you are going to do to make the path to the solution more clear?

First of all, discuss the task with experts. Those experts you can probably find in your team. Just plainly discussing the problem helps a lot to identify what exactly needs to be done.

In scrum those discussions take place in refinement meetings. In these meetings the whole team gets together to discuss certain tasks in order to get a rough overview of the effort.

Well, actually refinement meetings are NOT part of the official five scrum events, but a lot of teams have refinements (also called grooming sessions) to estimate the size of tasks.

Still, although the refinement meeting is not an official scrum event, the scrum guide describes the refinement as an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

In these meetings the team sits together and discusses what needs to be done and how much effort it will take. When the scope is clear enough for the team, then the size of the tasks are estimated.


The point of the meeting is to get a rough overview on WHAT needs to be done for a certain task. You should not discuss all the details HOW you are implementing it, but just WHAT needs to be done at a high level.

Do not spend too much time on discussing details, a healthy amount of uncertainty is fine. Clarifying the last bits and pieces can be done in the sprint planning meeting. The goal of refinement meeting is to get a rough estimation of the task size.

Anyway, for difficult tasks the team can discuss the different options to complete the task. And then the team decides, which path is the best and will be chosen.

For difficult tasks do not leave this decision up to the person, who picks up the task in the sprint. Try to find the best path together and avoid one person struggling to find the best option by himself.

This might save you from wasting a lot of time, because multiple brains more likely pick the option, which is really going to work.

When the possible options are not clear

Sometimes though you might be in a situation, where you cannot even identify the possible options for solving the task.

For such cases I think it is a good idea to create and work on an investigation task one sprint before you actually start working on the task itself.

The scope of the investigation task is to research the different possible options for the solution.

Such an investigation task should be time-boxed. This means, you define upfront, that you will only spend for example half of a day to research possible options. 

Time-boxing the investigation task helps to avoid spending too much time on the research. The aim is not to build a fully functional prototype, but just identify the options for a solution.

After you have completed the investigation task you should have an idea of the possible options. Then you can bring those options again in the next refinement meeting and the team can together discuss and decide, which is the best one.

If the team has identified the best path to go for solving the difficult task, it will be possible to come up with an estimate of the size. The estimation is done as usual with planning poker in the refinement meeting.

Let me wrap it up

Estimation of a difficult task is done during refinement meetings. There you define the scope of such tasks and you split it up in smaller, manageable parts.

This is done by the whole team together.

In some cases this is not working, because the task might be too complex. You might not know, how to solve it and which possible options you have for completing it.

In such cases, it helps to create an investigation task, where you spend a limited time to research different options for solving the problem.

After you have some more insights you share the knowledge with the team in the next refinement session. There the whole team will again discuss and estimate the task together.

Do you have refinement meetings in your team? How do they work out? Let me know in a comment if your team sometimes struggles with difficult tasks and how you handle it?

Ok, that’s it for this week. Take care and HabbediEhre!