Are you concerned that your team might have strayed from the foundational principles of Scrum or deviated from its core practices? What are the warning signs and what can you do to get back on track?
If you’re not following the minimal practices of Scrum, then you should ask why? Instead of thinking of this as a refresher on Scrum, think of it as a Scrum flight checklist. You may have larger issues to attend to than what the focus of your last retrospective was.
This checklist is organized under a set of foundational principles of Agility, which implementation of the Scrum framework should account for. A brief definition of the principle being discussed is provided along with warning signs that you might be deviating from this principle and policy issues your team should consider. The intent is not to cover those topics in detail or identify all the possible problems.
This is by no means a comprehensive discussion. Your warning signs or policy issues may be different than mine, and if so, I would love to hear about them.
Foundational Principles of Scrum
Process Control
The team has control over its underlying process. This emphasizes the Scrum philosophy of transparency, inspection, and adaptation.
- Warning Signs:
- The team has little influence on how it runs its ceremonies
- The team’s Kanban board has been specified by an external group
- Policy Issues:
- The Kanban board, team agreements, and metrics are transparent and visually posted
- The majority of Scrum ceremonies should be open to a wider audience
Self-Organized Teams
This emphasizes the principle of team buy-in; those who do the work are best able to determine how to perform the work.
- Warning Signs:
- Group decisions are dominated by supervisors, the product owner, or the Scrum master
- Proposed changes require buy-in from management
- Policy Issues:
- Work decisions should be made at the team level
- The team draws up a team charter
Teams are Collaborative
This emphasizes the principle of participation. The team’s output is a shared responsibility. It leverages the contributions of the entire team, embracing that the whole is greater than the sum of its parts. It’s not just about high-output performers.
- Warning Signs:
- Star performers produce a high volume of the team’s output
- The same team members frequently dominate the ceremonies
- Policy Issues:
- All team members are given a chance to participate
- Employ techniques to encourage participation. Consider the following:
- Pairing or sharing techniques
- Group assignments on user stories
- Spontaneous breakout sessions to whiteboard or brainstorm assignments
- Encourage new team members to ask for help
Value-based, Prioritized Work
One characteristic of highly functioning teams is a clear and aligned purpose. Teams need to prioritize the work that customers feel is most valuable.
- Warning Signs:
- User stories lack a clear business value, priority, or stakeholder input
- Sprints don’t have a clear goal
- Policy Issues:
- Sprints should have a theme based upon the product roadmap
- Sprint theme and product roadmap are shared with the team
- Stakeholders have input into prioritizing user stories
- All user stories in the sprint backlog are prioritized
Time-boxed Work
Time is a limiting factor that can be used to make work more productive.
- Warning Signs:
- Meetings often go off track
- User stories are very large
- Policy Issues:
- Publish an agenda for all ceremonies and working sessions
- Place time constraints (time-box) on all ceremonies and working sessions
- Parking-lot non-relevant team discussions
- User stories greater than five story points are rewritten into smaller user stories
Iterative Development
The team works in short, iterative cycles of activities. These are delimited by initiation activities such as sprint planning and termination activities, such as the retrospective.
- Warning Signs:
- Sprint lengths have been changing due to the expediencies of the moment
- Activities often transcend the sprint
- Policy Issues:
- Keep sprint lengths short
- All work is performed within the sprint
- Minimize specialty sprints, such as a “bug hunt” or UAT/end-to-end sprints
Shippable Work Products
Individual work products when completed need to be “shippable” or available for use by the intended customer.
- Warning Signs:
- Work products have multiple dependencies and must be shipped together
- Work products require more than one sprint to finish
- Releases are stalled out because specific user stories aren’t finished
- The entire release must be backed out due to one user story’s failure
- Policy Issues:
- Identify upfront dependencies and actively remove them from user stories
- Design user stories that can be implemented independently of each other
- Design user stories that can be backed out of production independently
If you are not embracing these foundational principles, then you have strayed from the path of Scrum. Maybe your team just needs to be more Scrum-like than it already is. Now let’s consider the core practices which are needed to satisfy those principles.
Core Practices of Scrum
Small Independent Teams
The fundamental working unit of Scrum is a small team consisting of one Scrum master, one product owner, and several developers. Developers are a small group, actively engaged in producing work products or services. The sweet spot for team size seems to be between 3 and 9 people, sans the product owner and Scrum master. As your team grows, consider splitting them into separate teams based on their functional attributes. Consider what functionality the team must focus on to deliver a working product.
- Warning Signs:
- The Scrum team has grown considerably in size
- The Scrum team has expanded its functional scope of work
- Work products stall out due to dependencies on external groups or individuals
- Management frequently crashes the sprint with other work
- Policy Issues:
- Keep your teams small, between three and nine people
- Balance and structure your team vertically to produce shippable results
- Invite representatives of external groups to Scrum ceremonies who are responsible for dependencies
- Limit outside political influencers on your team
The Sprint
A sprint is a fixed length of events based on a predetermined goal to create potentially shippable products. It’s characterized by a specific set of cadences.
- Warning Signs:
- Sprint length changes frequently to meet external pressures
- The team doesn’t consistently perform all the sprint cadences
- Policy Issues:
- If you want to be Scrum, then you need to do the sprint cadences
- Keep sprint lengths short to provide an opportunity to react quickly to changes
- Stabilize your sprint length; pick a length and stick to it
- When changing sprint length, crucial tracking metrics need to be re-baselined
Sprint Planning
The Scrum team collaborates and discusses the high-priority work for the sprint and defines the sprint goals.
- Warning Signs:
- Sprint planning turned into user story enhancement, estimation, or “gripe” sessions
- Sprint planning lacks focus or occurs in multiple sessions
- Policy Issues:
- Pointing and prioritizing should be a prerequisite to sprint planning
- Sprint planning only considers team capacity, priorities, and story points
- The product owner provides a sprint theme and commits to not changing the user stories
- The team commits to completing the user stories within the print
Daily Scrum
The development team meets to discuss impediments towards its progress in achieving the sprint goals.
- Warning Signs:
- Daily Scrum becomes the daily status or “gripe” meeting
- Daily Scrum focusing on discussions, not impediments
- Management often commandeers the time to make pronouncements
- Policy Issues:
- The daily Scrum is about discussing impediments
- Limit sessions to 15 minutes
- Everyone has an opportunity to comment on their user stories
- Establish guidelines: show up on time, no laptops, no other work performed
- Hold team break-out sessions after the daily stand-up for further discussions
Sprint Review
The Scrum team reviews potentially shippable products with the stakeholders.
- Warning Signs:
- Reviews have turned into gripe sessions
- Stakeholders request additional features
- Stakeholders frequently indicate the team is delivering functionality they didn’t ask for
- Policy Issues:
- Stakeholders commit to the functionality during sprint planning; hold them to that
- The goal is to demonstrate new functionality
- Stakeholders either accept or reject changes based on the acceptance criteria
- Increase transparency by including stakeholders in the development process:
- Invite them to daily Scrum
- Invite them to sprint planning
- Invite them to user story enhancement sessions
Sprint Retrospective
The Scrum team discusses what went right and areas for improvement in the sprint.
- Warning Signs:
- Retrospective become an indictment of team members
- Action items are not being completed
- The team is distracted by institutional issues
- Policy Issues:
- Establish guidelines: everyone participates, non-judgmental and open discussion
- Focus on short term changes to accomplish during the next sprint
- Create an action board and assign user stories for action items
- The Scrum master facilitates and is not responsible for everything
Scrum Artifacts
Product Backlog
This is a prioritized list of work (requirements) derived from the road map (future projects) for the development team to work on to complete the project.
- Warning Signs:
- The product backlog contains every idea, every user story ever created
- Difficult to find historic user stories
- Policy Issues:
- Periodically archive obsolete items
- Organizing items into epics, themes, or functionality
Sprint Backlog
A subset of the product backlog. This is a list of tasks identified by the Scrum team to complete during the sprint.
- Warning Signs:
- The sprint backlog is an unrealistic wish list
- The sprint backlog far exceeds the team average capacity
- Policy Issues:
- The sprint backlog ONLY contains prioritized, pointed, and sufficiently defined user stories
- ALL user stories must be in “Ready” status for immediate work
- Remove all user stories which don’t meet the minimal sprint requirements
- Determine a work-in-progress limit for the sprint backlog
I have identified the classic core practices of Scrum. If your team includes additional ceremonies, then employ the same style of critical thinking. Consider the following:
- Identify the intent
- Assess the impact on productivity
- Create a strategy to get back on track
- Focus first on simple things with the largest impact
Key Metrics
Velocity
Velocity is a calculation that measures units of work completed in a given time frame. This is a measure of throughput.
- Track ALL work with pointed user stories
- Track velocity and obtain a trend over several sprints
- Discount outliers such as changes in sprint length or team size
- Stabilized velocity is a positive trend; it indicates the team is performing consistently
Burn-down/Burn-up Charts
A sprint burn-down/burn-up chart visually tracks the completed work throughout the sprint. The x-axis represents time and the y-axis refers to the amount of work left to complete. The expected result is a straight line angling up or down. This is either calculated or based on accumulated velocity.
- Do not use partial story points — only account for actually completed user stories
- Slight deviations from expected results are normal
- Assess deviations during a retrospective
Story Points
This is a subjective measure of the complexity of the work. It’s often measured with a modified Fibonacci sequence, which is a series of numbers starting at 1, 3, 5, and so on. Sometimes so-called T-shirt sizing is used: small, medium, large, and extra-large. This can be used to derive many other useful metrics as part of the denominator.
- Teams should be trained on how to estimate user stories
- Teams should initially use one of the well defined estimating practices
- The entire team is involved in the estimation
- Estimation is not limited to the Scrum master, product owner, or team leads
- Large user stories indicate they are poorly written and should be rewritten and re-estimated
There are a host of metrics to consider. Be selective. At a minimum, you should consider these. The key is to define them and use them wisely. You get better results by using metrics consistently. They can be powerful tools to help you to measure a team’s performance and provide feedback for improvements.
Closing Thoughts
It helps to assess your team’s current approach to Scrum periodically, whether or not you have made recent changes. These are intended to be guidelines to help put things into proper perspective. You should start by considering factors that cause unproductive effort. Would time-boxing meetings help? Do your current practices generally conform to the intent of Scrum’s core practices? Use these as touch-points you can refer back to. Retrospectives can be a powerful tool for change in Scrum, but consider other approaches for larger systemic issues.
References
Scrum The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland, 2014
6 Main Principles in the Scrum Framework from blog.scrumstudy.com/
What is Scrum from Scrum.org
The Scrum Team Roles and Accountabilities by Scrum Alliance
