Example mapping is a great way to have a discussion about your user stories and can be used to make refinement sessions more interactive.
Read all about it here: https://cucumber.io/blog/example-mapping-introduction/
Just a site where I archive interesting reads I've encountered online
Example mapping is a great way to have a discussion about your user stories and can be used to make refinement sessions more interactive.
Read all about it here: https://cucumber.io/blog/example-mapping-introduction/
This article describes an interesting card game that will help you improve your refinement process: https://hackernoon.com/35-cards-which-will-improve-your-backlog-refinement-process-and-engage-every-team-member-54f929fdd282
If you need some inspiration for a fun retrospective, take a look at this board game:
Inspired by Carmen Guerra Jurado her holiday in Greece, it has:
The teams enjoyed it and results were fruitful! (Pun intended.) The game itself still needs some tweaking. But Monopoly better watch its back! 😆
Each team member writes down 3 statements. 2 of them are true, 1 of them is not true. The statements must be about the person himself.
Examples:
A person tells the 3 statements. The teammates may take turns guessing what is true and what is not.
More 2 Truths and a Lie ideas and examples can be found here: https://truthsandlie.com
The following text was copied from: https://www.scrum.nl/blog/building-team-manifesto/
Every time a new team is formed, it takes time to grow from a group of people to a well-functioning team. In their journey to become a high-performing team, they need a shared understanding of the principles and values of each individual and the team. The most important principles and values can be summarized in a team manifesto, a social contract among the team members. A team manifesto is always built by the team itself. It contains a set of norms, values and behaviors that forms a solid ground for collaboration within the team.
With every team I coach, one of the first things we do is building a team manifesto. Recently, I did this by using the Retrospective format ‘That guy, this guy’. The results were great! Therefore, I would like to share this workshop format with you.
A team manifesto ensures that the team coherence improves. It is a common understanding about the desired behavior within the team, and what it means for them to be a team. Since the team has ownership over the team manifesto, team members will behave according to it and encourage others to do the same.
Additional examples can be found here:
How To Kickstart A Great Scrum Team (10 practical things to do)
by Christiaan Verwijs
Since it’s such a tried-and-true format, there are plenty of articles on the Team Radar, with advice and emphasis added based on the author’s position and involvement with teams. Christiaan Verwijs of The Liberators approaches the subject from a facilitation perspective with a Scrum Master-y stance in 2017’s Retrospective: Do the Team Radar, while Petra Wille’s 2019 article The Secret Weapon of Retrospectives – the Team Radar over on Mind the Product is clearly written from a product managerial perspective. Use the best of both for your team’s next (radar) retrospective.
IDOARRT is a simple tool to support you to lead an effective meeting or group process by setting out clear purpose, structure and goals at the very beginning. It aims to enable all participants to understand every aspect of the meeting or process, which creates the security of a common ground to start from. The acronym stands for Intention, Desired Outcome, Agenda, Rules, Roles and Responsibilities and Time.
Before the meeting/process, prepare a Flipchart / Slide outlining all the points of IDOARRT. See below:
Intention – What is the intention, or purpose, of the meeting? In other words, why have it?
Desired Outcome(s) – What specific outcomes should be achieved by the end of the meeting?
Agenda – What activities will the group go through, in what order, to move toward the desired outcome?
Roles – What roles or responsibilities need to be in place for the meeting to run smoothly? Who is facilitating, and who is participating? Who is documenting, and who is keeping track of the time? What do you expect of the participants?
Rules – What guidelines will be in place during the meeting? These could relate to agreed group norms. They could also relate to use of laptops/mobiles, or practical rules related to a space. Let the participants add rules to ensure that they have ownership of them.
Time – What is the expected time for the meeting, including breaks,and at what time will the meeting end?
At the beginning of the meeting, introduce the IDOARRT, going through point by point. Invite participants to ask questions or make suggestions for changes. Once the group is happy with the plan, go ahead with the rest of the meeting.
10 Retrospective examples (in Dutch) from Paul Overmars can be found here: https://paulovermars.nl/10-retrospectives/
This is a resource for sharing retrospective plans, tips & tricks, tools and ideas to help us get the most out of our retrospectives. Retrospectives play a crucial role in software teams. It is time specifically put aside to reflect on how the team is performing and what can be done to improve.
https://retrospectivewiki.org/index.php?title=Retrospective_Plans
The retrospective timeline is a useful exercise for gaining a better understanding and a richer context for a particular retrospective. This means that this exercise becomes less useful when you do retrospectives more frequently and especially useful when doing a retrospective spanning longer periods or you run retrospectives less frequently.
Find the instructions here: https://www.thekua.com/rant/2006/03/a-retrospective-timeline/