Guidelines in Scrum

To do Scrum, all we need is 11 essentials i.e. 3 Roles Accountabilities, 3 Artifacts and 5 events. These 11 essentials are bound together by certain rules and guidelines which are described throughout the Scrum guide. These rules and guidelines help Scrum Teams to make the best possible use of Scrum framework to create maximum business impact.

When I refer to rules, I mean those aspects which cannot be mended to fit a particular context. For ex: You cannot do Scrum without the 3 Accountabilities - Product Owner, Development Team  Developers and Scrum Master.

When I refer to guidelines, I refer to those aspects which might be changed to fit to a particular context; the impact however, could only be verified after implementation. Then we Inspect and Adapt accordingly.

For example, Product Backlog Refinement consumes no more than 10% of a team's capacity. Is the capacity - # of hours; # of story points; # of days - well, there is no rule for that. Scrum Teams self-organize and choose what best fits their context; following the guidelines that we consume no more than 10% of team capacity.  This was a guideline till the 2020 version came out.

However, from 2020 version perspective Product Backlog Refinement

is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

So now the guideline is - it is an ongoing activity and Scrum team may decide how much capacity they want to put into it.

In this post I will be exploring few such guidelines which bind the 14 essentials together and give the Scrum Team flexibility to fit those aspects to their context.

#1. Development Scrum Team size: The size of the Development Team is suggested to be 3-9 members. The Scrum Team size is 10 or less people. Depending on the context, it might have more people or less. The impact of it would vary based on team context.

From the Scrum Guide:

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product.

#2. Titles/Roles on Development Team for  Developers: Scrum doesn't recognize any titles/roles within the group of Developers. Everyone is a Developer. A Developer is anyone who is involved any kind of development of the product. 

However, within an organization the team members may still have titles/roles. In my experience that I have been associated with Scrum; I haven’t come across any team which has only one title/role.

#3. Three question format for Daily Scrum: Most teams that I have worked with utilize the format of 3 questions for Daily Scrum:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediments that prevents me or the Development Team to meet the Sprint Goal?

Surprise, these 3 questions are just a template for teams that are starting with Scrum and this was a guideline only till 2017 version of Scrum guide. The Developers can structure the Daily Scrum in any way that they see fit as long as they focus on the progress towards Sprint Goal.

#4. Time-box for Events: The time-box for events states the maximum amount of time allowed for the event for a 1 month sprint. The guideline is: it is usually shorter for shorter duration of sprints.
Does that mean, for a two week Sprint, Sprint Planning is time-boxed to 4 hours, Sprint Review to 2 hours and Sprint Retrospective to 1 and 1/2 hours? No.
The events can be as short/long as needed as far as they meet the purpose; but cannot go beyond the maximum allocated time. For ex: A Sprint Planning event for a 2 week Sprint may be over in 2 hours if it meets the purpose or may continue till 8 hours if it doesn't.

#5. Progress Trends: The Scrum Guide states that various practices like burn down charts, cumulative flows to forecast progress. However, the team is completely free to choose whatever practice they see fit to meet the purpose. In my experience, I have seen teams creating visual roadmaps, milestone based progressions, journey lines, release burn up charts etc. Although, we also need to remember that in a complex environment; only empirical data can help us to make right decisions.

#6. Estimation: The Scrum Guide describes that the Product Backlog Items need to be estimated. How should they be estimated is completely up to the Scrum Team. Story Points, Ideal Days, T-Shirt sizes, Dog Sizes are some of the ways.

Can the Scrum Team do "No Estimates"? Of course, as long as the Scrum Team is able to draft a plan that, supports empiricism; creates transparency and helps the team to create a potentially releasable "Done" increment at the end of Sprint; it doesn't matter. The Scrum Team self-organizes to choose what suits its context.

#7. Work Decomposition: Under the section "how will the chosen work get done?" for Sprint planning, Scrum guide mentions -

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. 

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.

This often helps, however is not mandatory for Developers to do so. Sometimes, IME, it is not possible to break down a PBI to a work item that can be done in one day. I have seen couple of teams which do not break down there work items to such a granular level. They very well understand how to get the functionality converted to a "Done" increment by the end of the Sprint.

#8. Sprint Review: This is an important Inspect & Adapt event where the Scrum Team collaborates with key stakeholders on what was achieved during the Sprint and what can be done in the next Sprint to optimize the value of the product.

The Scrum Guide also describes elements that are part Sprint Review:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner
• The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done"
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
• The Development Team demonstrates the work that it has "Done" and answers questions about the Increment
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next

• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product

  The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Scrum guide now states - what has changed in the environment instead of the details like budget, timelines, capabilities, marketplace change - but does that mean that all of those things should not be discussed in the Sprint Review. Definitely not. We can still discuss all the aspects that might impact valuable product delivery. 

Although, not all the elements mentioned above will make sense for all the Scrum Teams all the time. Scrum Teams may choose to discuss and touch upon various aspects of Product Delivery during the Sprint Review as they see fit in their context.

#9. Release to Production: The purpose of every Sprint is to create potentially releasable "Done" Increment. That means the Increment needs to be in a useable state and meets the DoD of the Scrum Team.
The choice of releasing an Increment to production, however, is with the Product Owner. Based on the context of team and the increments they create; a Scrum Team may decide to do multiple releases per sprint, one release per sprint or an accumulated release of multiple sprints; whatever optimizes the value for the product.

#10. Definition of Done: Definition of Done helps to raise transparency and creates a shared understanding about what it means for the work to be complete. As per the Scrum guide, the Scrum Teams are expected to expand their DoD and make it more stringent for higher quality.
Again, this is not a rule. Depending on the context of the team; the Scrum Team might revisit it's DoD every retrospective or might continue with same DoD unless it learns something new to improve the quality of the product.

Conclusion: These are just few guidelines spread throughout the Scrum Guide. I wanted to bring out this distinction because I have often found Scrum Teams getting confused with Scrum rules and guidelines. Few are very common - fixing the time box of Sprint Planning to 4 hours for 2 week sprint or Development Team spending too much time & effort to break down PBIs into "tasks"- others, not so common. This post I believe will help teams to identify few of those aspects of Scrum which they can amend to fit their context as well as they would be able to differentiate with those aspects which cannot be altered.

P.S. The content is modified to reflect the changes from 2020 version of Scrum Guide.