Scrum Rules

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