The idea behind this repository is to explain the SCRUM Rituals and its most common anti-patterns and how to avoid them. I did an Introduction to Agile Presentation wherepart of the things I explain, these are included. I hope you enjoy it. 🤗

As the official guide of Scrum says:

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

🏁 Sprint Planning

🗣️ Daily Meeting

📝 Product Backlog Refinement

🎉 Sprint Review

🛡️ Retrospective

In the Sprint planning the Team decides what work will be done. (Product Backlog Items known as PBI). This agreement defines the Sprint Backlog and is based on the team’s velocity or capacity and the length of the sprint. In the Sprint planning we'll answer the next question:

• What can be delivered in the Increment resulting from the upcoming Sprint?

It's important to remember that only the DEV Team can assess what it can accomplish over the upcoming Sprint.

• The Team hasn't a clear Definition of Ready
• You think A is asked for but they asked for a B
• Setting unrealistic expectations
• Don't have a priorized Product Backlog
• The Product Owner decides how much work
• Not notifying vacations or absences

• Set a Definition of Ready
• Ask as much as needed to have all details of what's asked for
• Break tasks into smaller ones. Dicidi e vinci
• Save capacity during the Sprint to check the complexity of the next Sprint tasks
• Ask for a constant Product Backlog priorization.
• Be clear with your capacity
• Notify your vacations or absences so the capacity can be more accurate

The Daily Meeting is a maximum duration of 15 minutes meeting, though this may need adjusting for larger teams. To keep the meeting short, any topic that starts a discussion is cut short, added to a "parking lot" list, and discussed in greater depth after the meeting, between the people affected by the issue.

Each member should answer the questions: What I did yesterday? What will I do today? Is there anything blocking me?

• Off-topic conversations
• Technical conversations finding solutions
• Implementation details. Alert!!
• Reporting to the Product Owner
• Cross-conversations
• Monologs
• Cluelessness

• Encourage every one to interrupt if needed
• Cut things fast. Break wrong habits.
• Remain stand up so subconsciously the meeting will take less time
• Do we have to talk about something? Do it later
• Make a circle to combat the reporting symptom
• If a Team Member usually talks too much, time box each one
• Ask team members to prepare the Daily Meeting

The Product Backlog Refinement, also referred to as Product Backlog Grooming, is a method for keeping the Product Backlog updated, clean and orderly.

It's a good time to clarify details and make tasks satisfy the Definition of Ready.

A good practice is to have 2 Sprints worth of work.

• The tasks at the top of the Backlog have big estimations
• Tasks not estimated
• The Product Backlog contain items for longer than 2 month-ish
• The DEV Team is not challenging the Product Owner on which could be the best User Stories
• Long debates on each Product Item

• Use timers for each item, 5 minutes top. Give it an extra 3 min if everyone agrees
• Question Stick. Pass an object to your Team mates. Who has it have to ask for Product Item details
• Remove Product Items that have been longer than 2 month-ish

The Sprint Review is celebrated in order to inspect the Product Increment and adapt the Product Backlog if needed. During the meeting, the Scrum Team explain to the stakeholders what has been accomplish, what hasn't and incidents or difficulties the team had and how they did overcome them.

• Selfish Product Owner. She/he says: I did
• Cheating. Showing development with bugs or not finished
• The Team doesn't explain challenges
• It's called or treated as a DEMO
• The Product Owner is presenting all the results, no one else talks on the Team

• Each Team Member should present their User Stories
• Everyone should explain challenges or problems
• Use timers to do not exceed the time
• The Team should only present working software

The Retrospective is an opportunity for the Team to inspect itself and create a plan for the improvements with the actions derived from this meeting. The idea of the Retrospective is to discuss what went well, what could be improved and what will we commit to improve in the next sprint.

• Taking as personals some comments
• A Team Member explains to an outsider what happens in the retrospectives
• The Actions are not assigned to anyone at the end of the Retrospective (no owners)
• Managers/outsiders are coming to the meeting
• The Team doesn't review past actions
• Discussion dominated by one or two people

• Take Retrospective seriously
• Be honest with your workmates. Everyone should understand we are in the meeting to improve
• Encourage people to participate. Make everyone speak and give constructive feedback
• If there are no things to improve as a team, ask individually. What would you help go faster? What don't you like?
• To make the opinions more obvious, materialize them using post-it's or writing in a board
• Do the DOT Voting practice to decide which actions the team will do the next Sprint
• Assign owners to this actions