What is Scrum?

The Three Scrum Roles

Scrum defines three accountabilities — not job titles, but roles within the team. One person can hold multiple roles in small teams, though the Product Owner and Scrum Master roles are often kept separate to avoid conflicts of interest.

• Product Owner — owns the product backlog, prioritizes work, represents stakeholder and client needs, decides what gets built and in what order
• Scrum Master — facilitates Scrum ceremonies, removes blockers, protects the team from external interruptions, coaches the team on Scrum practices
• Developers — everyone who does the actual work (design, code, testing, writing). In Scrum, this is a self-organizing cross-functional group

The Five Scrum Ceremonies

Scrum ceremonies are structured meetings with specific purposes and time limits. Many teams skip or collapse ceremonies when they're busy — which usually leads to the exact chaos Scrum is designed to prevent.

Scrum Artifacts: Backlog, Sprint Backlog, Increment

Artifacts are the information and work products Scrum teams maintain. Three main artifacts:

The Product Backlog is the master list of everything that might be built — features, bug fixes, improvements, experiments. The Product Owner owns and prioritizes it. It's never fully complete; it grows and changes as the product evolves.

The Sprint Backlog is the subset of the Product Backlog selected for the current sprint, plus the plan for delivering it. Only the Developers can change the Sprint Backlog during a sprint.

The Increment is the sum of all completed Product Backlog items at the end of a sprint. It must meet the team's Definition of Done — a shared agreement on what "finished" means.

Scrum for Agency and Creative Teams

Full Scrum is designed for product teams building software. Agencies often adapt it — keeping sprints and retrospectives but dropping daily standups in favor of async updates, or merging the Product Owner and Scrum Master roles for smaller teams.

A 6-person design agency might run 2-week design sprints: Monday planning, daily async updates in the project board, Thursday check-in calls, and end-of-sprint reviews with clients. This gives clients visibility without constant meetings, and gives the team a sustainable pace.

The biggest Scrum challenge for agencies is that client requests don't respect sprint boundaries. The solution: keep a buffer of 20–30% of sprint capacity for urgent requests, and train clients that non-emergency requests go into the next sprint.

Running Your First Scrum Sprint: Week-by-Week

Your first sprint will feel slower than your current process. That's expected, not a sign the approach doesn't work. Here is a week-by-week guide for a 2-week sprint, for a team running Scrum for the first time.

Before Sprint 1: Backlog Setup (3–4 hours). Write down every active project, task, and open request. Break items larger than 4 days into smaller pieces. Estimate each item as small (under a day), medium (1–2 days), or large (3–4 days). Don't use story points yet. Prioritize the list. At the end, you should have 30–50 items covering roughly 2–3 months of work.

Week 1, Day 1: Sprint Planning (2 hours). The Product Owner presents the top-priority backlog items and explains the reasoning. The team pulls items into the sprint backlog based on capacity. For a 6-person team over 10 working days, available capacity runs roughly 30 person-days. Apply a 20% buffer: plan for 24 person-days of work. The team writes the sprint goal in one sentence: what does success look like at the end of this sprint?

Week 1, Days 2–5: Execution and Daily Scrum. Run the Daily Scrum at the same time each day. Fifteen minutes. Three questions per person: what did you complete yesterday, what are you working on today, what is blocking you. The Scrum Master records every blocker and resolves it the same day, not tomorrow.

Week 2, Day 6: Midpoint Check. Each team member estimates remaining hours on in-progress tasks. At the midpoint, the team should have completed roughly 50–60% of the sprint backlog. If you're at 30%, raise it in that day's standup. Waiting until day 10 leaves no room to adjust.

Week 2, Day 10: Sprint Review and Retrospective. The Sprint Review takes 30–60 minutes. Present completed work to the Product Owner and at least one stakeholder. Incomplete work goes back to the backlog. Nothing "almost done" gets presented as done. The Retrospective follows: 45 minutes, Start/Stop/Continue format, five minutes per person to write, then vote on the top 3 items. One owner per action item before the session ends.

• Sprint 1 velocity will be lower than expected — sprints 4 and 5 are when teams typically start trusting the system
• Don't run velocity calculations until Sprint 3 — the first two sprints establish your baseline
• Every blocker from standup needs resolution within 24 hours — if a blocker stays open 2 days, escalate it
• "Done" means done: reviewed, approved, and delivered to the stakeholder. Not "mostly done" or "waiting on one thing."

Scrum for a 6-Person Creative Team: Adapted Approach

Standard Scrum comes from software development. A 6-person creative team doing design, copy, or campaign work needs to adapt the framework to match how creative projects actually flow. Here's what changes and what stays.

Sprint length shifts to 1 week instead of 2. Client feedback cycles in creative work run shorter than software release cycles. Waiting 2 weeks to incorporate direction puts deliverables at risk. Weekly sprints let the team respond to feedback without holding up client work.

Estimation moves from story points to hours. Story points require calibration over many sprints before they become reliable. A creative team starting Scrum should estimate in hours instead. Each person has 35 working hours per week. Subtract 5 for meetings, admin, and coordination. Plan each sprint at 30 available hours per person. Concrete and immediately understandable.

Roles get simplified. A 6-person team doesn't need a dedicated Scrum Master. The most organized team member takes on the role alongside their regular work. The Product Owner is the account lead or creative director. Review the assignments after 3 months.

Sprint Reviews become client-facing checkpoints. Software teams demo working features. Creative teams show completed design iterations, copy drafts, or campaign assets. Structure the review as a client walkthrough: present what was completed, collect approvals, and confirm the priority of next-sprint work. This makes the review a billable deliverable checkpoint, not an internal ceremony.

What doesn't change: the sprint backlog is agreed before the sprint starts, nothing enters the sprint mid-sprint without something leaving, the retrospective runs every sprint or every other sprint, and the definition of done is written before Sprint 1.

The most common mistake creative teams make with Scrum: skipping standups when the team is "in the zone." Standups surface blockers. A team member blocked on a client approval can't surface it without the standup. Run it every day.

• Sprint rhythm: Monday planning (45 min), Tuesday–Thursday standups (15 min), Friday client review (30 min), Friday retrospective every other week (30 min)
• Use hours over story points until the team builds 6+ months of estimation data
• Client must attend the sprint review — an internal-only review loses its primary purpose
• Commit to 1-week or 2-week sprints for at least 8 sprints before changing the length
• Don't skip standups — even 15 minutes surfaces blockers that email doesn't

When Scrum Fails: Common Failure Patterns

Scrum fails for predictable reasons. Most of them aren't about the framework. They're about how teams implement it. Identifying the pattern tells you what to fix.

The Zombie Standup: the team runs a daily standup for 8 weeks. Nobody blocks anyone. Everyone reports what they're working on. The standup becomes a formality. This happens when teams use it as a status update rather than a coordination meeting. Fix: change the core question. "What do you need from someone on this team to move forward?" forces the meeting to surface dependencies instead of individual progress reports.

The Frozen Backlog: the sprint backlog fills at the start and gets treated as permanent. New requests arrive mid-sprint and either get ignored or inserted without removing anything. By day 8, the team is behind on everything with no mechanism to make trade-offs. Fix: establish one rule before Sprint 1. Nothing enters the sprint once it starts unless the Product Owner removes an equivalent item.

The Missing Product Owner: too busy to attend sprint planning, reviews, or backlog refinement. The team makes priority calls without them. Work gets completed that the business didn't actually need. Fix: if the Product Owner cannot commit 4–6 hours per sprint to Scrum ceremonies, the team shouldn't run Scrum. A missing Product Owner is a structural problem, not a scheduling issue.

Velocity as a Pressure Tool: management sees velocity charts and asks why velocity isn't increasing sprint over sprint. The team inflates estimates to make velocity look better. Velocity stops being a planning input and becomes a performance report. Fix: set this expectation before Sprint 1. Velocity is for capacity planning, not performance evaluation. Stable velocity is the goal.

No Definition of Done: team members move tasks to "Done" at different standards. The sprint review reveals half the "done" work needs revision. Fix: write the definition of done before Sprint 1 and post it where the whole team can see it. For creative work, it typically includes: file delivered in the correct format, internal review completed, client approval received.

Retrospectives Without Follow-Through: the team identifies the same problems sprint after sprint. Nobody owns the action items. The next retrospective looks identical to the last one. Fix: every retrospective ends with action items that have owners and due dates. Review the previous retrospective's items at the start of the next one before adding new ones.

• Zombie standup: change the question to "What do you need from the team today?"
• Frozen backlog: nothing enters the sprint mid-sprint without an equivalent item leaving
• Missing Product Owner: 4–6 hours per sprint is the minimum — below that the framework breaks
• Velocity pressure: state before Sprint 1 that velocity is a planning tool, not a KPI
• No definition of done: write it before Sprint 1, visible to the whole team
• Retrospectives without follow-through: action items need owners before the session ends, reviewed at the top of the next retrospective

Scrum Tools: What Your Team Actually Needs

Teams starting Scrum often invest in tools before they understand the process. They configure boards with custom fields, velocity charts, and sprint analytics before running a single standup. The tool becomes the project instead of supporting it.

A shared task board is the core tool. Cards that move through To Do, In Progress, Review, and Done. You can build this in any project management platform. A spreadsheet with columns works. What matters is that every person can see the board without asking someone else for an update. If team members are regularly asking "where are we on X?" the board isn't visible enough.

A backlog list stores all work the team is tracking: prioritized, visible to everyone, maintained by the Product Owner. One additional section in your task board handles it. Re-prioritize the backlog before each sprint planning session so planning doesn't start with stale priorities.

A capacity tracker is a simple table: each team member's available hours per sprint, their committed hours, and remaining hours. A spreadsheet works. Update it at sprint planning and review it at the sprint midpoint. Teams that skip capacity tracking consistently overcommit and end every sprint behind.

A blocker log records every blocker from standup: the blocker, who owns resolving it, and the date it was raised. A shared document, a Slack channel, a running notes file. The format doesn't matter. The discipline of recording and following up within 24 hours does.

What you don't need in the first 3 months: burndown charts (teams often manipulate them by marking work done before it clears review), velocity dashboards (a two-column spreadsheet covers this in your first quarter), per-task time tracking (track at the sprint level initially), and separate tools for each ceremony. Planning, review, and retrospective can all run in the same shared document.

The common mistake: buying a tool with built-in Scrum features and spending the first 2 weeks learning the tool instead of running sprints. Start with the simplest setup that gives the team visibility. Add tooling after 3 months, when you understand what information you actually need.

• Board: any tool showing task status at a glance — start with what the team already uses
• Backlog: one prioritized list, maintained by the Product Owner, visible to everyone
• Capacity tracker: updated at sprint planning and at the midpoint — two columns minimum
• Blocker log: every standup blocker recorded with an owner and a follow-up date
• Skip for now: burndown charts, velocity dashboards, per-task time tracking, separate tools per ceremony