Scrum
Scrum is a lightweight framework for developing, delivering, and sustaining complex products. It organizes work into fixed-length iterations called sprints, defines three specific roles, and prescribes ceremonies for planning, synchronizing, and reflecting. Scrum doesn't tell you how to build software - it provides a structure within which teams can figure that out through inspection and adaptation.
Why it matters
Before agile frameworks like Scrum, software development often followed waterfall approaches: extensive upfront planning, sequential phases, and big-bang releases. This worked poorly for complex projects where requirements evolved and the right solution wasn't knowable in advance.
Scrum addresses these challenges by embracing uncertainty through iterative delivery and continuous feedback. It delivers value early through potentially shippable increments every sprint. It enables adaptation through regular inspection and course correction. It empowers teams to self-organize around how to accomplish their goals. And it creates transparency through visible backlogs, burndown charts, and ceremonies.
Scrum has become the dominant agile framework, used by millions of teams worldwide. Its success comes from being simple enough to understand quickly while being rich enough to handle complex development.
Scrum roles
Scrum defines exactly three roles, each with distinct responsibilities.
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. This includes managing the Product Backlog, clearly expressing backlog items, ordering items for optimal value delivery, ensuring the backlog is visible and understood, and making prioritization decisions. The Product Owner is one person, not a committee. They may represent stakeholder interests, but they make the final call on priorities.
The Scrum Master helps everyone understand and apply Scrum. They serve the team by facilitating Scrum ceremonies, removing impediments to progress, coaching the team in self-organization, helping the organization understand Scrum, and protecting the team from external interference. The Scrum Master isn't a project manager or team lead - they're a servant-leader who enables the team's effectiveness without directing their work.
The Development Team consists of professionals who do the work of delivering a potentially releasable increment every sprint. The team is cross-functional, possessing all skills needed to deliver. It's self-organizing, deciding how to accomplish work. It's accountable as a unit, with the whole team owning delivery. And it's small, typically 3-9 people. There are no sub-teams or hierarchies within the Development Team.
Scrum artifacts
The Product Backlog is an ordered list of everything that might be needed in the product. It's the single source of requirements and is never complete - it evolves as the product and its environment evolve. Items near the top are more refined and detailed; items further down are larger and less understood. The Product Owner is responsible for the backlog, though others contribute to it.
The Sprint Backlog is the set of Product Backlog items selected for the sprint plus a plan for delivering them. It's owned by the Development Team and updated throughout the sprint as work progresses and understanding deepens.
The Increment is the sum of all Product Backlog items completed during a sprint and all previous sprints. At the end of each sprint, the new Increment must be "Done" - usable and meeting the team's Definition of Done.
Scrum events
The Sprint is a time-boxed container of one month or less during which a "Done," usable, potentially releasable product Increment is created. Sprints have consistent duration throughout development, and a new Sprint starts immediately after the previous one ends.
Sprint Planning happens at the start of each sprint, when the team plans the work to be performed. It addresses what can be delivered (the team selects items from the Product Backlog) and how it will be accomplished (the team creates a plan for delivery). Sprint Planning is time-boxed to eight hours for a one-month sprint, scaled proportionally for shorter sprints.
The Daily Scrum is a 15-minute daily event for the Development Team to synchronize activities and create a plan for the next 24 hours. Common questions include what was done yesterday, what will be done today, and whether there are any impediments.
The Sprint Review happens at the end of the sprint to inspect the Increment and adapt the Product Backlog if needed. This is a collaborative working session, not a status meeting. The team demonstrates completed work and discusses what to do next.
The Sprint Retrospective follows the Sprint Review, allowing the team to inspect itself and create a plan for improvements. The team discusses what went well, what could be improved, and what they'll commit to improving in the next sprint.
Scrum values
Scrum is built on five values that the team must embrace. Commitment means team members commit to achieving goals and supporting each other. Courage means having the courage to do the right thing and work on tough problems. Focus means everyone focuses on the sprint work and team goals. Openness means the team and stakeholders are open about work and challenges. Respect means team members respect each other as capable, independent people.
Without these values, Scrum becomes mechanical ritual rather than effective framework.
Common scrum challenges
Absent Product Owner creates problems when the Product Owner isn't available for questions - the team either blocks or guesses, and both are bad. Scrum Master as Manager undermines the team's ownership when Scrum Masters tell teams what to do rather than facilitating their self-organization. Skipping Retrospectives means teams that stop reflecting stop improving - retrospectives aren't optional. Sprint Scope Changes make commitment meaningless when work gets added mid-sprint, preventing teams from planning effectively. Incomplete Increments accumulate technical debt when sprints end without truly "Done" work, destroying the ability to release on demand. Scrum in Name Only happens when organizations adopt Scrum terminology without embracing its principles, getting the overhead without the benefits.
Scrum and customer feedback
Scrum creates natural points for incorporating customer feedback. Sprint Reviews provide regular opportunities for stakeholder input, and the Product Backlog can continuously absorb and prioritize new insights.
Tools like Klero enhance this by connecting customer feedback directly to backlog items. When the Product Owner can see exactly what users are requesting and how those requests align with current priorities, Sprint Planning becomes more informed and the resulting Increments better address real user needs.
