Here is a list of all the rules of Scrum that we have been publishing lately.
Also, check out our Scrum Team Assessment to learn how well your team is doing Scrum!
The Basic Scrum Process
-
Every Sprint is the Same Length
-
Every Sprint is Four Weeks or Less in Duration
-
There are no Breaks Between Sprints
-
The Intention of Every Sprint is “Potentially Shippable” Software
-
Every Sprint includes Sprint Planning
-
The Sprint Planning Meeting is Timeboxed to 2 Hours / Week of Sprint Length
-
Every Sprint includes Sprint Review for stakeholder feedback on the product
-
Every Sprint includes Sprint Retrospective for the team to inspect and adapt
-
Review and Retrospective meetings are timeboxed in total to 2 hours / week of Sprint length
-
There is no break between Sprint Review and Retrospective meetings
-
The Daily Scrum is timeboxed to 15 minutes
-
The Daily Scrum occurs every day at the same time of day
-
Team Members answer only three questions at the Daily Scrum (no discussion)
-
The scope of work for a Sprint is never expanded mid-Sprint (interruptions)
-
All stakeholders are invited to attend the demo portion of the Sprint Review
-
PBIs have their effort estimated collectively by the team who will be implementing them
-
The Scrum Team is no less than five people and no more than eleven people
-
The Scrum Team includes the Product Owner, ScrumMaster and the Team Members
-
The Scrum Team does not include any other people (e.g. a manager who doesn’t do tasks)
The rules of Scrum related to the Product Backlog
-
No two Product Backlog Items (PBIs) have the same position in the Product Backlog (ordered)
-
All PBIs are related to a single product (or system)
-
PBIs are ordered by expected Value (ROI, NIAT, etc)
-
PBIs are “slices” through our system (features or functions)
-
PBIs are written as User Stories (“As a ___ I can ___ so that ___”)
-
The top PBIs are small enough (effort) that several can fit into a single Sprint
-
PBIs are invitations to conversations, not detailed specifications
-
Known defects (external quality) generally are ordered at the top of the Product Backlog to be fixed in the next Sprint
-
The Product Backlog is refined to ensure it is ready for every Sprint Planning meeting
-
Any stakeholder (e.g. Team Member, salesperson, client) can suggest a new PBI
-
The Product Backlog is easily visible to every stakeholder (e.g. cards on a wall or an electronic tool with open access)
The rules of Scrum related to the Team Member Role
-
I use Scrum as a tool for product development
-
I am truthful about the internal quality of my product (technical debt)
-
I work with only one Scrum team
-
I am a full-time member of that team (no non-Team Member duties)
-
I know my product well and can quickly describe its high-level purpose
-
I know my product well and can quickly describe its high-level architecture
-
I actively seek to help my team mates
-
I commit myself to doing whatever it takes to reach each and every Sprint goal
-
I volunteer for a new task from the Sprint backlog as soon as I complete a task
-
I share my obstacles (technical, tools, process, teamwork, personal) every Daily Scrum
-
I am willing to learn any skill needed to help my team
-
I work with all the team members to expand the Definition of “Done”
-
I take direction for product vision and scope from my team’s Product Owner
-
I live the values and principles of the Agile Manifesto in my team
-
I attend every Sprint Planning meeting in person
-
I attend every daily Scrum Meeting in-person
-
I attend every Sprint Review Meeting in-person
-
I attend every Sprint Retrospective Meeting in-person
-
I never tell any other individual team member which task to work on next
-
No member of my team reports to me
-
I do not track my hours or my “actual” time on tasks
Rules of Scrum related to the ScrumMaster Role
-
Your ScrumMaster is truthful about the condition of the team and the Scrum process
-
Your ScrumMaster believes that Scrum will help the team improve
-
Your ScrumMaster uses the Retrospective to help your team improve its processes and teamwork
-
Your ScrumMaster works with only one Scrum Team
-
Your ScrumMaster has no duties outside of the ScrumMaster duties
-
Your ScrumMaster knows Scrum well and can explain it both quickly and in detail to others
-
Your ScrumMaster has final authority within the team on the correct way to use the Scrum Process
-
Your ScrumMaster can enforce timeboxes within the team (e.g. meetings)
-
Your ScrumMaster is allowed to communicate directly with any stakeholder of the team
-
All people outside the team know that it is the ScrumMaster’s job to shield the team from interruptions
-
Your ScrumMaster is empowered to immediately remove in-team obstacles
-
Your ScrumMaster is expected to work diligently to remove organizational obstacles
-
Your ScrumMaster has the bandwidth and capacity to respond within minutes to the team’s questions
-
Your ScrumMaster consistently avoids doing hands-on technical work with the team
-
Your ScrumMaster never tells the team how to solve a technical problem
-
Your ScrumMaster helps the team expand the definition of “done”
-
Your ScrumMaster creates and maintains the team’s Sprint burndown chart
Rules of Scrum related to the Product Owner role
-
Your Product Owner is truthful about the condition of the product (its value scope and costs)
-
Your Product Owner uses the Sprint Review to help the team continuously improve the product
-
Your Product Owner has no duties outside the Product Owner duties
-
Your Product Owner is knowledgable about the product and the business
-
Your Product Owner can veto the inclusion of an idea on the Product Backlog
-
Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting
-
Your Product Owner is allowed to communicate directly with any stakeholder of the Team
-
Your Product Owner is the sole and final decision-maker for when the Team’s work is released to production, users or customers
-
Your Product Owner knows if the estimated financial return of the work of a Sprint is higher than its estimated cost
-
Your Product Owner has the bandwidth and capacity to respond to the Team’s questions within minutes
-
Your Product Owner never does hands-on technical work with the Team
-
Your Product Owner never tells the Team how to solve a technical problem
-
Your Product Owner always lets the Team freely decide how many Product Backlog Items to do in a Sprint
-
Your Product Owner never interrupts the team mid-Sprint with new “high priority” Product Backlog Items
-
Your Product Owner puts known defects at the top of the Product Backlog
-
Your Product Owner creates and maintains the Team’s product or release burndown chart
Affiliated Promotions:
Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!














Pretty good summary of Scrum rules. Few more that could be added around
* Team members are cross functional
* No hierarchy or classification among(BA, Architect, etc) team members
* There is one DOD
Venky, what’s a DOD. I’m not familiar with that acronym outside of Department of Defense.
DOD = Definition of “Done” — This is a way of helping a team and its stakeholders understand the gap between what the team delivers every Sprint vs. what would be necessary to have the product increment in a shippable state every Sprint. The DoD usually focuses on quality, non-functional requirements, and non-development activities that are performed to prepare for deployment/delivery.
The Scrum Team is no less than five people and no more than twelve people!
Nope.
The dev. team cannot be more than nine people (as per scrum guide). When we add SM and PO, we find eleven, not twelve!
Emin, Thanks for your comment. You are right. This was written before the current version of the Scrum Guide and when the size of the team was loosely defined and the recommended range was 7 +/- 2 for the dev team. The number 12 comes from research on high performance teams as a maximum size to allow the team to “gel”. Usually, a team of 12 people should be split into two smaller teams of 6 each… but not always. Thanks for the clarification.
Hmm. It says eleven.
THE RULES OF SCRUM: I DO NOT TRACK MY HOURS OR MY “ACTUAL” TIME ON TASKS
We have to create a Sprint Plan by creating tasks for related PBIs. After that, we “estimate” efforts for all the tasks, in terms of hours.
Why we do this?
We are in need of to measure the plan so the team can “manage” the sprint.
The team plans the sprint by tasks. What if any change in the development time of a particular task? How the team can manage this change? Even, how the team can identify the “change”?
E.g., a task estimated for 10 hours for development and we see it is its 15th hours. What this is implying to us?
This is a problem which the team has to see and solve.
If the team fails on to done a single task, it cannot done the PBI and it cannot meet the sprint goal!
We have to see if any unforseen change happens during the sprint. If it happens, we need a tool or mechanism to identify it. So, that is the measurement of the planned & actual time of a task.
Advanced and highly experienced teams may not track the hours of task, because they have enough experience to identify and solve any deviance in the tasks.
But, for new or not-yet-advanced teams, it is a “must” to track and manage task-based risks…
The original versions of Scrum definitively dis-allowed tracking actual time on tasks. When I took my CSM from Ken Schwaber back in 2003, he had a slide in his deck that said:
I have worked with many dozens of Scrum teams and NEVER found that tracking actual time was useful for the team itself. The problems you describe should be handled by the team members collaborating, doing creative and innovative problem-solving, and letting the team self-organize. Sometimes tracking actual time is useful for the organization (e.g. opex vs. capex).
Mishkin,
There are two aspects of tracking time:
1. Measuring working time to know how much the team worked!
2. Measuring task duration; actual against planned to find out if any variance occurs and identify problems.
#1 is, of course, useless in Scrum. We need the goal to be achieved, that is enough.
What do we do by creating tasks and estimating task duration by hours?
Regarding Schwaber’s “Agile Project Management with Scrum” book, Page #12,
title “Sprint Backlog”:
“The Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality. The Team compiles an initial list of these task in the second part of the Sprint planning meeting. TASKS SHOULD BE DIVIDED SO EACH TAKES ROUGHLY 4 TO 16 HOURS TO FINISH. TASKS LONGER THAN 4 TO 16 HOURS ARE CONSIDERED MERE PLACEHLDERS FOR TASKS THAT HAVEN’T YET BEEN APPROPRIATELY DEFINED…”
So, the team estimates the working hours for tasks, then?
If the team estimates it (defines it), so the team should manage it by measuring it, right?
What I mean by “manage” or “measure”?
Of course I am not talking about the success of the Sprint. This is just to be sure, if a task is taking more than planned hours, there might be a problem about the PBI and it may affect the Sprint Goal to be achieved.
I think, the key is simple: The team estimates it and then measures it to be sure if everything is okay or not. If not okay, they will learn it or surface it in the Daily Scrum and they will try to find a solution for it.
Finally, I do not mean measuring task hours to evaluate the team in terms of Sprint success or working hours!
I mean it measuring tasks according to planned and actual to create an alarm mechanism to quickly identify problems.
Also, task estimation and tracking is a good practise for the team to improve. If they make mistakes in estimations, they easily learn to make corrections of the estimates. So, they make better estimations in the future.
This is what I mean in this context.
Thanks for your interest.
Emin
A last addition:
I think the difference is here:
Tracking hours for team members is useless, but tracking hours for tasks is a good tool for managing risks.
Hi Mishkin,
Great job. Congrats. I’m doing an academic research and I would like to know how I can refer to these rules. Are they published in any book or paper?
Cheers,
Ulisses
LOVE this list. It’s great for beginners as well as season scrumbots
Merci pour le travail effectué. C’est génial !