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 nextSprint
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 theProduct Owner
on which could be the bestUser 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 theTeam
- 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