#SAILBOAT RETROSPECTIVE MIRO HOW TO#

I think the description of the titles is self-explanatory. It allows us to share what we learned during the sprint, what we loved in it, what we lacked and longed for. We have differentiated sad and mad as „negatives” and glad as „positives”.ĤL: Learned/Loved/Lacked of/Longed for - A bit more complex one. Sad / Glad / Mad - Also pretty straightforward, but a bit different than the previous one.

Ideas for improvement are also typed in the front, not emerging from the discussion. Good/Bad/Improve - In my opinion, this one is the most common and boring. Even if they seem similar, the small differences might make a difference in the phrase of the card. In Codetain we can make changes with the hosting shift trigger and everyone can use his favorite pattern. Diversity in the retro patterns is crucial to not get bored and tendentiously. The case here is to not choose one default one and do it until everyone will get sick of it. There are many patterns available on the internet. This makes people responsible for one of the retros, which is creating a will to make it as good as possible. What we do in Codetain is the retro hosting shift, where everyone will host a retro at some point and it is completely up to a hosting person which type of retro will be used. The second one is building up confidence and ownership. This allows us to be 100 % transparent and leads to the possibility of changing things that are not even raised on other teams. In Codetain we reached a level when people can say basically everything, they can argue during retro and still be good friends after that. It is not going to happen on the first retro, but after some time if the team is participating actively, it allows them to say more without hard feelings. Building up a strong team on retro.īut how can you build up a team in a meeting for a sprint summary? Twofold, firstly it lets people express their thoughts and feelings and open towards themselves. I think that there is one more thing that is not measurable and not taken into account in listing retro outputs - it is building up team chemistry and will for improvements. What is the purpose?Ī retro is an opportunity to summarize the sprint and discuss some pain points in the team, to appreciate a team member, or just to raise an idea.

Just do it somewhere after the sprint review - do not leave it for later. Retro done in the following sprint might cause confusion, because we are talking about the previous sprint and some topics can be mixed up or just be forgotten. It is a great spot to summarize all the good and bad things in the finished sprint and leave enough space to include potential improvements in the upcoming sprint. This is the spot between the end of one sprint and the beginning of the next one. Retro should be performed by the whole scrum team once a sprint - after the Review.

#SAILBOAT RETROSPECTIVE MIRO HOW TO#

I will tell you why it is crucial to have a retro once a sprint and how to do it properly and milk it for all it's worth.

Very often they are not performed properly and they give no outcome. I’ve heard many times that the retrospective is one of the useless meetings in the sprint.

Sailboat retrospective miro