4. Scrum is a framework for managing software development.
Jyaasa : We Design, Build and Develop Products
What is Scrum?
Scrum framework for completing complex project
Scrum is an iterative and incremental agile software
development framework for managing product development.
5. Jyaasa : We Design, Build and Develop Products
Scrum planning meeting
Timebox: Eight hours for a four-week sprint, proportionately
shorter for shorter sprints
Attendees: The complete Scrum team, including all roles
Most important: Team capacity and DoD
6. Jyaasa : We Design, Build and Develop Products
Purpose of Scrum planning meeting
A Sprint Goal
A Sprint Backlog
7. Create a recursive calendar invitation include all team members
including development and QA.
Meeting invitation for agile sprint planning should be from the
Product Owner.
Jyaasa : We Design, Build and Develop Products
Sprint planning Meeting Best Practices
Include agenda in the invitation, add the user stories link which
should be included in the sprint
8. Always included more User stories to be included in the sprint then
the team’ capacity.
Make sure the User story you are proposing from the sprint should be
really defined well, all the use cases, functional requirements and
condition of satisfaction are in detailed level and, at least, grooming
once with some senior team members.
Jyaasa : We Design, Build and Develop Products
Sprint Planning Meeting Best Practices
Order a tea/Coffee with something sweet, sometimes a coffee bribe
does work or, at least, it keep the developers or QA not to fell a
sleep.
9. Jyaasa : We Design, Build and Develop Products
Sprint Planning Meeting Rules
Remember the sprint planning meeting is run by scrum master and
he has the highest authority.
PO role in sprint planning meeting is only as a contributor, (s)he
make active contributor in answering the question if the team have
and explaining the user stories to the team.
Scrum master is the timekeeper, leader, facilitator, and coordinator of
the agile sprint planning meeting
10. Jyaasa : We Design, Build and Develop Products
Sprint Planning Checklist: Product Owner
Define Sprint Scope
Define each User Story items in detail
Prepare notes or include them in the agenda the thing concern, the
question for a particular user story so the team can come prepare
and have those answers before the before.
Make sure backlog is in priority order
Describe definition of done for each user story and for sprint
11. Making sure video, audio conference is reserved and working
Pre-order coffee and light refreshment, “no coffee no code”
Enough post-it notes and markers, whiteboard etc.
Available capacity for the team (team members holidays, public
holidays, etc)
Keep tracking the team’s velocity vs the amount of work committed
by the team
Jyaasa : We Design, Build and Develop Products
Sprint Planning Checklist: Scrum Master
12. Jyaasa : We Design, Build and Develop Products
Ask questions to clear any ambiguity or else “speak now or hold your“
Do not commit more than you can not deliver
Remember to think of your personal availability for the coming sprint.
Taking part in technical discussion during estimation or planning poker
Sprint Planning Checklist: Development Team
13. Jyaasa : We Design, Build and Develop Products
Input
- Team Capacity
- Groomed Product
Backlog
- Business Conditions
- Current Product
- Definition of Done
- Sprint Planning Meeting
- Tools And Techniques
- Planning Poker
- Expert Judgement
- Brainstorming
- Knowledge Sharing
- Collaborations
Output
- Sprint Goal
- Backlog item
solutions
- Sprint Backlog
Summary
14. Jyaasa : We Design, Build and Develop Products
Daily Scrum
Timebox: Fifteen minutes is standard,
irrespective of the duration of the sprint length
Attendees: The complete Scrum team, including
all roles
Most important: To speak about any
impediments
15. Remain Standing
3 questions agenda
Have your project management tool visible
It’s a collaborative effort
Plan the meeting around the team
Jyaasa : We Design, Build and Develop Products
Best Practices for Daily scrum meeting
16. Waiting around your team
Introducing new idea
Letting people ramble
Jyaasa : We Design, Build and Develop Products
Avoid
17. Jyaasa : We Design, Build and Develop Products
Scrum Review meeting
Timebox: Four hours for a four-week sprint,
proportionately shorter for shorter sprints
Attendees: The complete Scrum team, including
all roles, plus any other stakeholders who are
interested in the project success
Most important: Demo of working software and
assessing the feedback
18. Jyaasa : We Design, Build and Develop Products
Scrum Retrospective
Timebox: Three hours for a four-week sprint, proportionately
shorter for shorter sprints
Attendees: The complete Scrum team, including all roles; the
product owner's attendance is optional
Most important: To brainstorm and agree
on what is working and what is not
19. Jyaasa : We Design, Build and Develop Products
Problems
Boring Repeat Same Problem
20. Jyaasa : We Design, Build and Develop Products
21. Jyaasa : We Design, Build and Develop Products
Team is not a group of people
who work together,
Team is a group of people who
trust each other.
Simon Sinek
22. Jyaasa : We Design, Build and Develop Products
Questions
Hinweis der Redaktion
Hirotaka Takeuchi and Ikujiro Nonaka introduced
Attendees
Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment
Ask to team about the purpose of Scrum planning meeting
Teams typically do this as a result of pressure from management, especially if they are new to Scrum. They want to perfectly estimate each task because they want to be able to get an accurate estimate to management.
But that's not the goal of the sprint backlog in sprint planning meetings. The goal of sprint planning is to select the right set of product backlog items to work on during the sprint, and to feel that each has been discussed enough that the team is prepared to work on it.
Retrospectives are always conducted the same way.
No action is taken on retrospective action items.
People lose trust in the retrospective.
People see it as a blame game.
Beyond the team level, impediments are not getting resolved.
Retrospective of retrospective