To do Scrum, all we need is 11 essentials i.e. 3 Roles, 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 Roles - Product Owner, Development Team 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.
In this post I will be exploring few such guidelines which bind the 11 essentials together and give the Scrum Team flexibility to fit those aspects to their context.
#1. Development Team size: The size of the Development Team is suggested to be 3-9 members. 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:
Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
#2. Titles/Roles on Development Team: Scrum doesn't recognize any titles/roles within the Development Team. Within the Development Team, everyone is a Development Team Member. Although, within an organization the team members may 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. The Development Team 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 suggests to use practices like burn down charts, cumulative flows to monitor progress trends. 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.
This often helps, however is not mandatory for Development Teams to do so. In my experience, 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.
#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
Will it make sense for a Scrum Team that has been funded for year to review its budget at every Sprint Review that happens every two weeks? Maybe not.
Not all the elements mentioned above will make sense for all the Scrum Teams all the time. They are provided as a guideline so that 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 left with 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.