Why Scrum Needs a Manager’s Edit

Scrum provides a clear framework for delivering software incrementally, yet many engineering teams struggle with it. Ceremonies can feel mechanical, velocity stagnates, and the process starts to overshadow the purpose. As an engineering manager, you are responsible for the health and effectiveness of your team, not for enforcing a methodology. The question is not whether Scrum is good or bad, but which parts of it serve your team and which ones create friction. This article walks through the core elements of Scrum and offers criteria for deciding what to keep, what to drop, and what to adapt.

What to Keep: The Non Negotiable Core

Regular Retrospectives

Retrospectives are the single most important ceremony in Scrum. They give the team a structured opportunity to reflect, identify what is working, and decide what to change. Without retrospectives, improvement becomes random and reactive. Keep this practice even if you drop everything else. The format can vary: you can use start stop continue, the sailboat exercise, or simply a discussion around a single question. What matters is that the team owns the retrospective and leaves with concrete actions. As a manager, your role is to protect the time, remove any fear of honesty, and ensure that action items get followed up.

Backlog Refinement

Backlog refinement is the practice of regularly reviewing, estimating, and clarifying upcoming work items. It prevents the sprint planning session from turning into a discovery meeting. Teams that skip refinement often end up with vague tickets and unstable commitments. Keep refinement as a weekly habit, but adjust the duration and level of detail to your team’s predictability needs. For a team operating in a low uncertainty domain, refinement may be a quick pass. For teams dealing with complex work, deeper sessions are necessary. The manager ensures that the product owner and the team have a shared understanding of priorities before the sprint starts.

What to Keep with Adaptations: Flexible Elements

Sprint Planning

Sprint planning is useful, but it does not have to be a rigid two hour block every two weeks. The goal of sprint planning is to align on the sprint goal and select a realistic set of work items. What matters is the outcome, not the timebox. Keep sprint planning, but adjust the format. Some teams work better with a shorter planning session that focuses on the sprint goal and a rough capacity check, followed by a more detailed task breakdown session. Others prefer a single longer meeting. The engineering manager should observe the team’s energy and decision quality during planning and adjust accordingly. Drop the expectation that every story must be perfectly estimated before the sprint starts. A rough order of magnitude is often enough.

Daily Stand Up

The daily stand up is intended to coordinate the team, but it often turns into a status report to the manager. That is a problem. Keep the stand up only if it serves the team’s need to coordinate. If the team communicates well through other channels, you can drop the formal stand up or shift to an asynchronous check in. Many teams benefit from a short daily huddle that focuses on bottlenecks and help requests, not on what each person did. As a manager, you should attend as a participant, not as the sole listener. If you notice that the stand up is draining energy or becoming a lecture, change the format. You can also rotate facilitation among team members to keep it fresh.

Sprint Review

The sprint review is the demonstration of completed work to stakeholders. In theory, it provides feedback and builds alignment. In practice, it can become a perfunctory slide show that no one engages with. Keep the sprint review if you can make it interactive. Invite users, ask specific questions, and focus on outcomes, not feature checklists. If the team is working on a system with frequent deployments and continuous stakeholder feedback, the formal sprint review may add little value. In that case, you can drop the separate review ceremony and replace it with regular demos or a show and tell session. The manager must ensure that the feedback loop remains open even without the formal event.

What to Drop: Elements That Often Create Waste

Fixed Role Definitions

Scrum defines strict roles: Product Owner, Scrum Master, and Developers. In many organizations, the engineering manager ends up carrying responsibilities that do not fit neatly into any of these boxes. Forcing yourself into a single role can limit your effectiveness. Drop the expectation that you must stick to a predefined role. Instead, assign the responsibilities that matter: ensuring team health, removing impediments, coaching, and aligning with business goals. The Scrum Master role can be shared or rotated. The Product Owner should be a separate person, but if that is not possible, you can adapt the arrangement as long as decision making authority is clear. Do not be afraid to modify the role structure to match your team’s reality.

Velocity as a Performance Metric

Velocity, the amount of work completed per sprint, is a planning tool, not a performance indicator. Yet many engineering managers track velocity as if it measures productivity. This leads to estimation inflation, burnout, and unhealthy competition. Drop the practice of using velocity to compare teams or to evaluate individual performance. Use velocity only for forecasting, and even then, treat it as a rough guide. A better approach is to track cycle time and throughput, which reveal more about process efficiency. If you must keep a metric, keep cycle time and defect rate instead of velocity.

Story Points

Story points are a relative estimation technique that many teams find confusing and time consuming. If your team can estimate well using simpler methods, drop story points entirely. Alternatives include t shirt sizing (small, medium, large), ideal hours (with clear guidelines), or even no estimation at all for teams with stable flow. The purpose of estimation is to create a shared understanding of effort and to inform decisions. If story points are creating debate without improving decisions, drop them. The manager should ask the team whether estimation adds value and be willing to experiment with alternatives.

The Sprint Goal as a Rigid Commitment

Scrum encourages a sprint goal, but the goal should not be treated as an inflexible target. When teams treat the sprint goal as a promise, they resist change and fear failure. Drop the expectation that every sprint goal must be fully achieved. Instead, treat the goal as a direction. If new information emerges during the sprint, the team should be able to pivot. The engineering manager can help by communicating to stakeholders that the sprint goal is a forecast, not a contract. This reduces pressure and allows the team to respond to reality.

Timeboxed Estimations

Scrum prescribes timeboxed estimation sessions, often using planning poker. This can be effective for some teams, but for others it becomes a ceremony that takes too long relative to the value it provides. If your team is already proficient at breaking down work, you can drop the formal estimation session. Instead, rely on historical data and experience. The engineering manager can facilitate a lightweight sizing check during refinement without the full poker ritual. Trust the team’s judgment when they say a piece of work is small or large.

How to Decide What to Keep

The decision to keep or drop a Scrum element should be based on two criteria: does it help the team deliver value and does it improve team health. If a practice is adding overhead without clear benefit, drop it. If a practice is causing frustration or slowing down the team, adapt it. If a practice is helping the team coordinate, improve, or build trust, keep it. The engineering manager should regularly survey the team about the effectiveness of each ceremony and practice. A simple retrospective question like “Which meeting would you remove if you could?” can reveal a lot. Do not be afraid to kill a ceremony that no one finds useful. A team without a daily stand up but with strong asynchronous communication and collaboration is better off than a team that holds a daily stand up out of obligation.

Examples of Adapted Scrum in Practice

Consider a team working on a mature product with low uncertainty. They have high technical skills and strong communication. The engineering manager drops story points and uses t shirt sizing during weekly refinement. The daily stand up is replaced by a written check in and a 15 minute optional huddle. The sprint review is replaced by a monthly product demo. Retrospectives remain every two weeks. The team and stakeholders report higher satisfaction and lower meeting load. Velocity fluctuates less because estimation is simpler.

Another example: a team in a high uncertainty domain with frequent requirement changes. The manager keeps the sprint goal but treats it as a hypothesis. They keep backlog refinement but do it twice a week for 30 minutes. They drop the formal retrospective format and use a continuous improvement board where team members add ideas anytime. They keep the daily stand up because the team values the coordination. Sprint planning is reduced to 45 minutes focusing on the goal and rough capacity. The manager actively protects the team from scope creep during the sprint.

The Role of the Engineering Manager in Scrum

The engineering manager is not the Scrum Master, but they are responsible for the process working. That means you need to build the conditions for Scrum to serve the team, not the other way around. You shield the team from organizational pressure that would turn Scrum into a ritual. You facilitate experimentation with different formats. You make sure that the retrospective produces real changes. You coach the product owner on how to prioritize. You help the team understand why certain practices exist in the first place. When you drop something, explain the rationale. When you keep something, reinforce its purpose.

Ultimately, the best version of Scrum for your team is one that they own. If the team feels empowered to adapt the framework to their needs, they will take more responsibility for their delivery and their process. As an engineering manager, your job is to enable that ownership, not to enforce a doctrine.