13 thoughts on “Rules of Scrum”

1. 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

   Reply

   1. Venky, what’s a DOD. I’m not familiar with that acronym outside of Department of Defense.

   2. 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.

2. 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!

   Reply

   1. 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.

   2. Hmm. It says eleven.

3. 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…

   Reply

   1. 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:

      This should not be confused with time reporting, which is not part of Scrum. There are no mechanisms in Scrum for tracking the amount of time that a team works. Teams are measured by meeting goals, not by how many hours they take to meet the goal. Scrum is results oriented, not effort driven.

      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).

4. 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

   Reply

5. 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.

   Reply

6. 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

   Reply

7. LOVE this list. It’s great for beginners as well as season scrumbots

   Reply

8. Merci pour le travail effectué. C’est génial !

   Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.