A small presentation by Ashley-Christian Hardy on the basics of Scrum methodology, covering the basics of roles & responsibilities, events & ceremonies and scrum artefacts.
3. In this presentation I will cover…
Roles & Responsibilities
Events & Ceremonies
Artifacts
4. Product Owner
Responsible for
prioritizing the backlog
and breaking it down
with the team
High priorities
Low priorities
Sprint Planning
The PO presents the
priorities from the
backlog and along with
the team create some
sprint goals, which
everyone agrees can be
delivered which
becomes the sprint
backlog.
One Sprint: Repeat ‘N’ Times
The second part of the sprint
planning is where the team decides
how they will build the features.
Work is tracked
with a burndown
chart
Tracking
Daily
Scrum
The team has a daily meeting
where they discuss progress and
what is blocking (impediments)
The SprintSprint Review
The team demos what has
been “done” and the PO
accepts or rejects the work.
Everyone collaborates and
gives feedback on how to
move forward.
Sprint Retrospective
The team reviews their
process and how well
they work together.
They give feedback and
adapt the process
moving forward
It’s Done!
Potentially shippable
product increment
The Team
The team completes
the tasks in the sprint
backlog, consulting
with the PO and
stakeholders on
requirements and
“doneness”
The Scrum Master
The scrum master
facilitates for the team,
he facilitates the process
and is a servant leader.
He informs the
stakeholders and clears
any blocks for the team.
6. Product Owner
As the PO, my responsibilities are….
• Providing vision for the team, and clearly communicating this to the rest of
the team.
• Representing the users of the system.
• Managing stakeholders and their requirements.
• Owning and maintaining the product backlog.
• Making key decisions and prioritizes work for the team.
• Setting the acceptance criteria for each user story.
• Establishing the release plan goals, and maintaining the scope for each
release.
• Approving the release
• Communicating change and new functionality to the stakeholders.
• Attending the daily standup to LISTEN.
• Providing guidance and clarification when needed.
• Having complete knowledge on the system being developed.
• Promote continuous improvement methods.
• Commit to the self-learning of scrum.
• Promote standardized, repeatable processes.
• Observing, listening and evaluating to provide feedback.
• Shield the team from users, stakeholders and requirements.
7. Scrum Master
As the SM, my responsibilities are….
• To encourage face to face communication, the teams self-organization and
accountability.
• To be as transparent as possible, create an open environment in stand ups, reviews
and retrospectives.
• To be completely adaptable to change.
• Solving problems for the team, not waiting for who broke it or who should fix it.
• Helping the team to create information indicators such as burndown charts.
• Help the team report to management.
• Help the team to reflect and review continuously.
• Ensure the team maintains their scrum tools and adhere to the process.
• Reward and appreciate the team when they do well.
• Help the team take pride in what was delivered and celebrate success.
• Facilitate all meetings and ceremonies, as well ass collaboration with stake holders.
• Creation of a definition of done.
• Incentivizing team building activities.
• Continuously self-learn on scrum, be involved in the community and take back what is
learnt.
• Give regular feedback to the team, and help them to catalyze change.
• Protect the team from outside sources.
• Resolve conflicts
• Help the team to identify and remove impediments and obstacles.
8. Development Team
Developer QA DBA / Sys Admin UI/UX
Designer
As the DT, my responsibilities are . . . .
NOTE: The development team is not just a team of developers, it includes anyone who has to work on the
project. The development team can include: developers, QA, DBA, Sys Admin, Release Management,
UI/UX designers, Team Leaders, Analysts…..
• Prioritizing the sprint backlog
• Estimating the effort to implement a user story
• Identifying complexity of a user story.
• Splitting a user story into tasks
• Completing development / tasks to achieve sprint goal.
• Implementing test cases.
• Unit and initial acceptance testing
• Identification of any obstacles and raising to the scrum master.
• Self-organizing.
• Attending all the meetings and ceremonies.
• Communicating the status of the work on a daily basis.
10. Sprint Planning Daily Scrum
Attendees: Development Team, Scrum Master, Product Owner
When: Beginning of the sprint
Duration: Usually one hour per week of sprint; so 2 week sprint would have
a 2 hour meeting.
Purpose: The meeting to set up the success of the team. The PO will have
a prioritized product backlog. Each item is discussed and the group
collectively discusses the effort to complete. The development team then
forecasts and commits on how much can be completed to form the sprint
backlog.
Attendees: Development Team, Scrum Master, Product Owner
When: Once per day, typically in the morning
Duration: No more than 15 minutes. Can be done standing around the sprint
board or desks.
Purpose: The meeting is designed to keep everyone one in the loop on
progress, each team member answers:
• What they did yesterday
• What they will do today
• What (if anything) is blocking them
11. Sprint Review Sprint Retrospective
OR
Attendees: Development Team, Scrum Master, Product Owner
When: End of the sprint or a milestone
Duration: 30 to 60 minutes
Purpose: This meeting is the time when the development team has to
showcase what is built. This is the time for the team to celebrate their
success and get feedback from the product owner and stakeholders.
Work should be fully completed and demonstrable to keep quality high.
Attendees: Development Team, Scrum Master, Product Owner
When: End of the sprint
Duration: 60 minutes
Purpose: This meeting is the time when the development team reviews
and reflects on what they did and how they did it. The purpose is to
allow the team to improve their processes and culture, to understand
what went well and what didn't’t. The meeting isn't for complaints for
blaming – its for constructive improvement with an action plan on how
to get better.
12. Backlog Refinement
Attendees: Development Team, Scrum Master, Product Owner
When: During the sprint
Duration: 60 minutes.
Purpose: Although not an official ceremony, its something 99% of scrum
teams do. The purpose of this meeting is for the product owner and the
development team to review and refine the backlog. Its good practice to
discuss and re-discuss user stories the more and more the team learns
and have new ideas. It also ensures everyone is in line and knows what
is coming up.
14. Product Backlog Sprint Backlog / Goal
Burndown Chart Impediment List
A prioritized list of features the product owner wants to be
delivered. It is something that is constantly changing and
being evaluated. It is the responsibility of the Product Owner
to maintain it.
The sprint backlog / goal is the outcome of the sprint
planning meeting. It is a list of agreed on and committed user
stories to be completed in the sprint. This is owned by the
development team.
The burndown chart is a simple line graph that shows
progress of the sprint / project. It shows work completed
against an ideal trend. Using this its easy and quick to
identify any issues, and is easy to maintain.
This is a list of issues that the development team has raised
is blocking progress. It is the responsibility of the scrum
master to work through the list and remove all impediments.