Leading a Scrum team effectively comes down to five practices, applied in the order they naturally occur across a sprint cycle: a well-maintained backlog shapes what enters the sprint, protected sprint boundaries and a visible Scrum board govern how work gets tracked and executed once committed, consistent velocity measures whether that commitment was realistic, and servant leadership runs underneath all four as the constant thread holding the team together.
The 5 Scrum Best Practices:
- Keep the product backlog visible, prioritized, and collaboratively refined
- Protect sprint boundaries and time-boxed events
- Maintain a visual Scrum board for transparency and alignment
- Maintain a consistent, sustainable velocity
- Practice servant leadership as the Scrum Master
Best Practice 1: Keep the Product Backlog Visible, Prioritized, and Collaboratively Refined
Keeping the backlog effective means building and refining it together with stakeholders, prioritizing it by real customer value rather than internal convenience, and regularly checking that current backlog items still align with the project’s original chartered scope. A backlog that drifts from its original scope without anyone noticing is one of the most common ways Scrum teams stay busy while quietly losing sight of why the project was chartered in the first place.
Three questions keep a backlog honest during refinement:
- What does the customer value most right now? — priorities shift, and the backlog should reflect the current answer, not the answer from three sprints ago.
- Does this specific work item still align with that value? — items that made sense earlier can lose relevance as understanding of the customer’s need evolves.
- Does the current backlog still match the project’s original chartered scope? — this check catches scope drift before it compounds into a project that no longer resembles what was originally approved.
Best Practice 2: Protect Sprint Boundaries and Time-Boxed Events
Protecting sprint boundaries means holding each Scrum event — planning, daily standup, review, and retrospective — for its intended purpose and time-box only, resisting the temptation to extend a sprint or change its goal mid-cycle. Adding unscheduled meetings on top of Scrum’s built-in events, or lengthening events beyond their sanctioned time, erodes the rhythm and predictability the framework is specifically designed to provide.
- Hold each ceremony for its intended purpose, without letting planning meetings turn into status updates or standups turn into problem-solving sessions.
- Resist mid-sprint scope changes once the team has committed to a sprint goal.
- Complete the current sprint’s commitments before pulling in new work, rather than blending sprints together.
Best Practice 3: Maintain a Visual Scrum Board for Transparency and Alignment
A well-organized Scrum board — whether physical or in tools like Jira or Trello — keeps the whole team aligned by making task status visible at a glance, and it works best when items are grouped logically and updated consistently rather than treated as an afterthought. A board nobody updates regularly stops being a transparency tool and becomes a stale artifact that misleads more than it informs.
- Group items logically into clear stages — to-do, in progress, and done — so status is readable at a glance.
- Use color and labels to highlight priority items and approaching deadlines.
- Update the board continuously throughout the day, not just during the daily standup, so it reflects reality rather than yesterday’s status.
- Keep the board simple enough that any stakeholder can understand project status without needing it explained.
Best Practice 4: Maintain a Consistent, Sustainable Velocity
Maintaining consistent velocity means building a level-loaded workload into each sprint so the volume of committed work stays predictable across the life of the project, rather than swinging between overcommitted and underutilized sprints. A team that consistently commits to roughly the same amount of work each cycle — rather than oscillating between an overloaded sprint and a light one — produces steadier morale, more reliable forecasting, and a genuine sense of accomplishment sprint after sprint.
A team with an established velocity of around 30 story points per sprint that suddenly commits to 50 points is signaling a planning problem, not unusual ambition — sustainable velocity means recognizing that pattern during the retrospective and adjusting the next sprint’s commitment back down before it produces burnout or a missed sprint goal.
Best Practice 5: Practice Servant Leadership as the Scrum Master
Servant leadership means the Scrum Master leads by removing obstacles, shielding the team from distractions, and coaching rather than directing, flipping the traditional top-down management structure common in predictive project environments. This practice underlies the other four — a backlog refined without genuine stakeholder collaboration, a board maintained through mandate rather than shared ownership, sprint boundaries enforced through authority rather than shared discipline, or velocity tracked to punish rather than inform, all point back to a Scrum Master who has reverted to command-and-control leadership rather than practicing the model Scrum actually assumes.
How Do These Five Practices Work Together Across a Sprint Cycle?
These practices follow the natural lifecycle of a sprint: backlog refinement shapes what enters sprint planning, protected boundaries and an actively maintained board govern execution once the sprint begins, velocity data collected during the sprint review informs the next cycle’s commitment, and servant leadership operates continuously underneath all four stages rather than at a single point in the cycle. A team strong in four of these practices but weak in the fifth typically shows a specific, recognizable failure pattern — a team with a great backlog, a well-tracked board, and protected sprint boundaries but a Scrum Master who reverts to directive leadership under pressure will still struggle, since that leadership gap eventually undermines the other four practices as well.
How Does This Appear on the PMP and PMI-ACP Exams?
Both exams test these Scrum practices through scenario questions asking what a Scrum Master or project manager should do when a sprint is at risk, a board has gone stale, a backlog has drifted, or team velocity has become unpredictable. Recognizing which of the five practices addresses a given scenario is the core skill these questions test.
Sample Question 1
Midway through a sprint, a stakeholder requests a significant new feature be added to the current sprint’s scope. What is the appropriate response? A) Add the feature immediately to satisfy the stakeholder B) Protect the current sprint’s commitment and route the new request to the backlog for future sprint consideration C) Extend the current sprint to accommodate the new work D) Cancel the current sprint and restart planning
Sample Question 2
A team’s Scrum board shows several tasks still marked “in progress” that were actually completed three days ago. What does this indicate? A) The board is functioning correctly B) The board has gone stale and is no longer providing accurate transparency C) The Scrum Master should discard the board entirely D) The team is ahead of schedule
Sample Question 3
A team’s velocity has swung between 15 and 50 story points over the last four sprints with no clear pattern. What does this most likely indicate? A) The team is highly adaptable and this is a strength B) A planning or estimation problem requiring attention to stabilize sustainable velocity C) The Scrum Master should immediately replace the team D) Nothing — velocity naturally varies without any need for adjustment
Sample Question 4
A Scrum Master directly assigns specific tasks to specific developers each morning rather than allowing the team to self-organize. What does this behavior indicate? A) Strong, effective Scrum Master leadership B) A departure from servant leadership toward command-and-control management C) The correct application of Scrum’s leadership model D) A necessary practice for all Scrum teams
Sample Question 5
A team has been completing sprint after sprint successfully, but a review reveals the current backlog no longer resembles the project’s originally chartered scope. What has most likely occurred? A) The team has been highly productive with no concerns B) Scope drift went unaddressed during backlog refinement C) The Scrum Master failed to hold daily standups D) The Product Owner should be replaced immediately
Answers: 1) B — protecting the current sprint’s commitment while routing new requests to the backlog preserves the team’s rhythm without ignoring the stakeholder’s request. 2) B — a board showing outdated status has stopped functioning as a transparency tool and needs immediate attention. 3) B — wide, inconsistent velocity swings signal an estimation or planning issue rather than healthy adaptability. 4) B — directly assigning tasks rather than enabling self-organization is a departure from the servant leadership model Scrum assumes. 5) B — consistently completing sprints doesn’t guarantee alignment with original scope; unaddressed scope drift during backlog refinement is the most likely explanation.
Frequently Asked Questions
Is the Scrum Master a Project Manager?
The Scrum Master is not a project manager in the traditional sense — they don’t direct the team’s work or own project outcomes the way a predictive project manager does, instead facilitating Scrum events, removing obstacles, and coaching the team toward effective self-organization. Some organizations blend the two roles in practice, but Scrum’s own framework defines them as distinct.
How Long Should a Sprint Be?
Most Scrum teams run sprints of two to four weeks, though the framework does not mandate a single fixed length — the key requirement is consistency, since a stable, predictable sprint length is what makes velocity tracking and forecasting meaningful. Changing sprint length frequently undermines the predictability Scrum depends on more than choosing a slightly longer or shorter length ever would.
Does the Scrum Board Need to Be Digital?
A Scrum board does not need to be digital — physical boards with sticky notes work well for co-located teams, while digital tools like Jira or Trello better serve distributed or remote teams that need shared, real-time access. The format matters far less than whether the team actually keeps it updated and treats it as a genuine transparency tool rather than a formality.
What Happens if the Team Can’t Complete the Sprint Backlog?
Incomplete sprint work typically returns to the product backlog for reprioritization in a future sprint, rather than extending the current sprint to force completion. Protecting the sprint boundary, even when it means carrying incomplete work forward, preserves the team’s rhythm and provides more honest data about actual velocity than artificially extending sprints to hit arbitrary completion targets.
Can Scrum Best Practices Apply Outside Software Development?
Scrum’s core practices — a prioritized backlog, protected time-boxed cycles, a visible tracking board, sustainable pace, and servant leadership — apply to any team managing iterative work, not only software development. Marketing campaigns, sales cycles, and operational teams have all adapted these same underlying practices to their own context.
