Scrum is a process framework/methodology
Scrum requires Agile mindset
A Scrum team consists of a Scrum Master, a Product Owner, and Developers (members of the DevTeam)
Every Sprint is of same duration
Every Sprint is four weeks or less in duration
There are no breaks between two Sprints
The intention of every Sprint is “Potentially Shippable” deliverable
All meetings/ceremonies are time boxed
Every Sprint starts with Sprint Planning Meeting
The Sprint Planning Meeting facilitated by Scrum Master
The Sprint Planning Meeting is attended by Scrum Master, Product Owner, DevTeam members, and stakeholders
The Sprint Planning Meeting produces committed Sprint Backlog
In Sprint Backlog, the Product Owner defines Sprint Vision
The Sprint Planning Meeting has two parts.
The Sprint Planning Meeting is Timeboxed to two hours / week of Sprint duration
In Sprint Planning Meeting part one, Product Owner offers INVESTable PBIs to DevTeam and encourage them to commit for the current Sprint
In Sprint Planning Meeting part one, Product Owner and DevTeam negotiate the scope of Sprint commitment
In Sprint Planning Meeting part two, DevTeam break down contents of Sprint Backlog into SMART tasks
No additional stories to be added into Sprint Backlog after the Sprint Planning Meeting
No story deleted after the Sprint Planning Meeting from Sprint Backlog
Every day of team has Daily Standup at same time of day
The Daily Standup is not a status meeting but information sharing and asking for help meeting
The Daily Scrum is timeboxed to 15 minutes
In a Daily Standup, all team members remain stand up.
In the Daily Standup, every team member answers three questions only. No discussions.
All members of the team attend daily standup
If required after Daily Standup, team members may break into smaller groups
The Acceptance meeting is not an official meeting in the Scrum Guide.
The Acceptance meeting does not have time box or cadence. It is an impromptu meeting.
In an Acceptance meeting, one or more Developers and Product Owner meet.
Developer/s present a story and requests Product Owner to accept it as per criteria defined in Acceptance Criteria of this story.
Developer/s presents stories which have met Definition of Done (DoD).
The Product Owner may accept a story or decline the request
If story is accepted, it is marked as Done Done
If a story is not accepted, it remains in Sprint Backlog and DevTeam continue its effort on the story till it is accepted by the Product Owner in current Sprint or it goes back in Product Backlog for refinement after current Sprint is over.
The Sprint Review Meeting is conducted at last day of Sprint before Demo and Retrospective
The Sprint Review Meeting is for stakeholder feedback on the increment of current increment as well as product
The Sprint Review Meeting is facilitated by Scrum Master
All members of the team attend the Sprint Review Meeting
The Sprint Review Meeting may result in PBIs and/or items to be discussed in Retrospective
The Sprint Review Meeting is time boxed into two hours per week of Sprint duration
The Demo is not an official meeting in the Scrum Guide but most of the teams do it separate from the Sprint Review Meeting
The DevTeam demonstrates (show and tell) the delivery of current sprint to stakeholders
The Product Owner makes a call - Which PBIs to be demo-ed
The Demo may result in PBIs and/or items to be discussed in Retrospective
All stakeholders are invited to attend the Demo
Every Sprint includes Sprint Retrospective for the team to inspect and adapt
The team decides what to be leaked beyond four walls of the Retrospective meeting room.
Follow the Prime Directive of Retro
A Retrospective is strictly for the team. Only pigs are allowed, no chickens
In the Retrospective loop back the action items of previous Retrospectives
In the Retrospective conversation centered around three questions
All team members attend every Retrospective
Scrum Master is not a master of team but Scrum
No one reports to Scrum Master
A Scrum Master facilitates ceremonies
A Scrum Master is a Servant Leader
A Scrum Master works with only one Scrum Team
A Scrum Master is full-time role
The Scrum Master enforces time boxes for Scrum ceremonies and Sprint
A Scrum Master shields the team from interruptions
A Scrum Master is empowered to facilitate to tackle intra-team impediments
A Scrum Master is expected to work diligently to tackle organizational impediments
The Scrum Master has accountability to create and maintain the team’s Sprint burn down chart
The Scrum Master coaches the team to enhance effectiveness
The Scrum Master encourages the team to enhance efficiency and productivity by automation and better engineering practices
A Scrum Master continuously works with team to reflect
A Scrum Master has final authority within the team on the correct way to use the Scrum framework
A Scrum Master does not get involved in technical matters
The Product Owner owns Product Backlog
The Product Owner is accountable to keep healthy Product Backlog
All work to the team routed through the Product Manager
A team has only one Product Owner
No one in the team report to the Product Owner
The Product Owner is the go to person about product vision, goal, and functionality
The Product Owner accepts PBIs through out the Sprint
The Product Owner can cancel a Sprint midway
The Product Owner is always available to the team
The Product Owner keep on providing details on the PBIs as sought by devTeam
The Product Owner assigns business value to PBIs
The Product Owner interacts with DevTeam and stakeholders to keep Product Backlog DEEP enough to DIVE
The Product Owner has system analyst and business domain like expertise to understand pragmatic technological and functional realization of the product vision and goals
The Product Owner represents team in Demo
The Product Owner is accountable to refine Product Backlog on continuous basis
The Product owner do not add or delete items in Sprint Backlog in middle of a Sprint
The Product Owner owns Release burn down chart
In a DevTeam there is only one role - Developer
The DevTeam size is between 5 to 7 people
The DevTeam members are in continuous conversation with each other beyond Scrum ceremonies
The DevTeam estimates PBIs
The DevTeam strives to keep Technical Debt minimal and stable
The DevTeam commits in Sprint Planning keeping in mind the historical facts and current factors
The DevTeam is responsible to potentially shippable increment at the end of each Sprint
The DevTeam keep Product Owner in loop with respect to Technical PBIs
The DevTeam strives for automation in every aspect of development and maintenance
A DevTeam member can describe product with end to end functionality
A DevTeam member can describe product's high-level architecture
A DevTeam member actively seek to help of the team mates
A DevTeam member commits to do whatever it takes to reach each and every Sprint goal
A DevTeam member volunteer for a new task from the Sprint backlog as soon as it completes the current in hand
A DevTeam member is willing to learn any skill needed to help team
A DevTeam member work with all the team members to expand the Definition of Done
A DevTeam member seek direction for product vision and scope from the Product Owner
A DevTeam member never direct any other individual team member which task to work on next
Product Backlog is a ranked list of PBIs
Any one in the universe can add PBI to a Product Backlog but Product Owner prioritize
Product Backlog is an evolving list
Product Backlog is accessible to everyone
Sprint Backlog is a subset of Product Backlog to signify commitment of team for the current Sprint
Contents of Sprint Backlog are suggested by Product Owner but finalized by DevTeam
The order of delivery of items from Sprint Backlog is discretion of DevTeam
In the end of a Sprint, Sprint Backlog should be empty
Sprint Backlog is accessible to everyone
PBI is one which adds value to the Sprint deliverable directly
PBIs keep on evolving with rapid bursts when in Product Backlog but once in Sprint Backlog, evolution is much controlled
Most of the time PBIs are written as user stories
Each PBI has acceptance criteria
The top PBIs are small enough (effort) that several can fit into a single Sprint
PBIs are invitations to conversations, not detailed specifications
Defects/bugs are PBIs
Scrum Board has four columns - Product Backlog, Sprint Backlog, Doing, and Done
Scrum Board is visual representation of work - To Be, Doing, and Done
Scrum Board helps to visualize and enforce WIP limit
Burn down chart is a graphical representation of remaining work in the current Sprint
Burn up chart is a graphical representation of completed work in the current Sprint
Burn up/down chart is updated daily
PBIs are 3Cs and INVESTable because of SMART tasks to make Product Backlog DEEP enough to DIVE
Posts
