Classic Scrum versus SAFe Scrum

After studying the Scrum Guide on multiple occasions over the past few weeks in preparation for a PSM1 Scrum Master certification workshop, I realized that there are several distinct differences between the “classic” Scrum and SAFe’s application of Scrum-like practices. I decided to do a deeper dive into how Scaled Agile Framework (SAFe) utilizes Scrum and found some interesting points that surprised me. I would like to share these observations with you so that you can make an educated decision before selecting SAFe as your Agile scaling methodology.

Most teams that I have worked with adopt Scrum based on the Scrum Guide since it has been around for many years, and is considered by most Agilists to be the standard. However, as SAFe continues to grow in popularity and adoption across various organizations, the differentiation between how SAFe leverages Scrum and basic Scrum can become challenging, especially for those who already have extensive experience practicing “classic” Scrum.

To help those folks who may not have the time or budget to attend SAFe courses, but are interested in gaining a deeper understanding of Scrum within the SAFe domain, I have compiled a summary of my assessment below. I will share a few points that I found to be interesting based on my experience applying both Scrum and SAFe for teams. To obtain a full understanding of how Scrum works within the context of SAFe framework, I recommend taking the “SAFe for Teams” training course.

Characteristic / Terminology “Classic” Scrum (Scrum Guide) SAFe 4.5 Instantiation of Scrum
Name of Team Scrum Team Agile Team
Team Members Development Team, Scrum Master, Product Owner Dev Team, Scrum Master, Product Owner
Dev Team Size 3 to 9 people 5 to 9 people
Team Method Scrum Any combination of Scrum/XP/Kanban
Daily Collaboration Daily Scrum Daily Standup
Planning Event Sprint Planning Iteration Planning
Review Event Sprint Review Iteration Review
Retrospective Event Sprint Retrospective Iteration Retrospective
Backlog Refinement Event Backlog Refinement Backlog Refinement
Review/Demo Event Sprint Demo (single team) Single-team demo (at Iteration Review), supplemented by System Demo (all teams)
Timebox Sprint/Iteration <= 1 month 1 to 4 weeks acceptable; 2 weeks recommended
Timebox for Sprint/Iteration Planning (for 2 wk Sprint) <= 4 hours <=4 hours; 2 to 4 hours recommended
Timebox for Sprint/Iteration Review (for 2 wk Sprint) <= 2 hours 1 to 2 hours
Timebox for Sprint/Iteration Retrospective (for 2 wk Sprint) <= 1.5 hours <=1 hour
Timebox for Daily Scrum <= 15 minutes <= 15 minutes
Time allocation for

Backlog Refinement

<=10% of team capacity ~ 1 hour
Sprint/Iteration Goals Sprint Goal Iteration Goal
Backlog of Work (Team Level) Product Backlog Team Backlog
Content of Backlog Features, functions, requirements, enhancements, fixes User and enabler Stories; improvements, refactors, maintenance, defects, technical debt, spikes
# of Backlogs in Multi-team Environment 1 backlog for all teams 1 Team Backlog for each team
Definition of Done (DoD) No specific guidance. Team decides what is acceptable. Example scalable DoD defined as reference.