Guidelines in Scrum
Guidelines in Scrum
While this post goes over some common guidelines in Scrum, it's important to remember that these guidelines are flexible and should be molded to your team's needs.
Join the DZone community and get the full member experience.Join For Free
A few days back I did a Scrum Tapas Video explaining a few of the rules within Scrum. Besides these rules, there are also certain guidelines which help Scrum Teams to make the best possible use of Scrum to create maximum business impact.
When I refer to rules, I mean those aspects which cannot be mended to fit a particular context. For example, you cannot do Scrum without a Product Owner, Development Team, and Scrum Master.
When I refer to guidelines, I refer to those aspects which might be changed to fit a particular context; the impact, however, can 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 the number of hours, story points, or 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 a 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 the 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, 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 three questions for their 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 prevent me or the Development Team from meeting the Sprint Goal?
These three questions are just a template for teams that are starting with Scrum. The Development Team can structure their Daily Scrum any way they see fit as long as they focus on the progress towards their Sprint Goal.
#4. Time-Box for Events
The time-box for events states the maximum amount of time allowed for the event for a one-month Sprint. The guideline is: time-boxing is usually shorter for shorter Sprints.
Does that mean that, for a two-week Sprint, Sprint Planning is time-boxed to four hours, Sprint Review to two hours and Sprint Retrospective to one-and-a-half hours? No.
The events can be as short/long as needed as long as they meet their purpose, but they cannot go beyond the maximum allocated time. For example, a Sprint planning event for a two-week Sprint may be over in two hours if it meets the purpose or may continue for eight hours if it doesn't.
#5. Progress Trends
The Scrum Guide suggests using practices like burn down charts and cumulative flows to monitor progress. However, the team is completely free to choose whatever practice they see fit. In my experience, I have seen teams creating visual roadmaps, milestone-based progressions, journey lines, release burn up charts, etc. We also need to remember that in a complex environment, only empirical data can help us make the right decisions.
The Scrum Guide describes that the Product Backlog Items that need to be estimated. How they should 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. The Scrum Team self-organizes to choose what suits their context.
#7. Work Decomposition
Under the section "how will the chosen work get done?" for Sprint planning, the 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, it is not mandatory for Development Teams to do so. In my experience, I have seen a couple of teams which do not break down their work items to such a granular level. They understand how to get the functionality converted to a "Done" increment.
#8. Sprint Review
This is an important inspect and 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 the 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 a year to review its budget at every bi-weekly Sprint Review? Maybe not.
Not all the elements mentioned above will make sense for all Scrum Teams at all times. 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 a potentially releasable "Done" increment. That means the increment needs to be in a usable state and meets the Definition of Done (DoD) of the Scrum Team.
The choice of releasing an increment to production, however, is left to Product Owner. Based on the context of the 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 the same DoD unless it learns something new to improve the quality of the product.
These are just a 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 fur hours for a two-week Sprint or Development Team spending too much time and effort to break down PBIs into "tasks"— others are not so common. This post I believe will help teams to identify a few of those aspects of Scrum which they can amend to fit their context.
Published at DZone with permission of Piyush Rahate , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.