What is Scrum: sprint, roles, and burndown in practice.

Scrum is a framework for teams that need to deliver results in short cycles, learning with every delivery. The team works in fixed-length periods called sprints. At the start of each one, it chooses what to do; at the end, it shows what got done and discusses how to improve. All of this with few roles, few meetings and three well-defined lists.

This guide explains the pieces of Scrum in the order they show up in the routine: values, roles, events, artifacts, the difference between epic, user story and task, point estimation, velocity and burndown. At the end, it shows how to adapt the method for teams outside tech and how to apply it all in Tasskee.

What Scrum is and where it comes from

The name comes from rugby: the formation in which the whole team pushes together to win the ball. The comparison appears in a 1986 article by Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review, which described product development teams working in an integrated way, instead of passing the work from department to department like a relay race.

Ken Schwaber and Jeff Sutherland formalized Scrum for software in the 1990s and presented it publicly in 1995. Since then, the method has been described in the Scrum Guide, a short, free document that is updated from time to time. The 2020 version, which this text is based on, made the guide even leaner.

One point the guide itself insists on: Scrum is a framework, not a complete process. It defines the rules of the game but leaves it to the team to decide how to work within them. That explains why two Scrum teams can look very different from the outside.

The three pillars and the five values

Scrum rests on the idea that complex work can't be fully planned in advance: you learn by doing. That's why there are three pillars.

• Transparency. The work and its progress must be visible to the people affected by them. If the real status lives in one person's head, there's nothing to inspect.
• Inspection. At regular intervals, the team looks at what has been done and how much progress was made toward the goal.
• Adaptation. If inspection shows that something has drifted off course, the team adjusts whatever needs adjusting, quickly.

The five values describe the behavior that makes this work: commitment, focus, openness, respect and courage. In practice, they translate into concrete things: the team commits to the sprint goal, concentrates on it, talks openly about problems, respects colleagues' opinions and has the courage to say "that doesn't fit."

The roles on a Scrum team

Scrum has three roles, all within a single team. There's no hierarchy among them: the team is small, usually just a few people, and answers collectively for the result.

Product Owner

The person who is accountable for the product's value and for the product backlog, the list of everything the team intends to do. They decide what comes first and why. They talk to customers, executives and internal areas, and bring those needs to the team as prioritized items. It's one person, not a committee: someone needs to have the final say on the order of the backlog, otherwise everything becomes a priority.

Scrum Master

The person who makes sure Scrum is understood and practiced. They're not the team's manager or "the boss of the meeting." They help the team remove impediments, facilitate events when needed, protect the team from interruptions and teach the organization to work with the method. As the team matures, the Scrum Master's workload shrinks, and that's a good sign.

Developers

The people who do the work of delivering the increment. The name comes from the software context, but it refers to anyone who produces the item: a designer, a copywriter, an analyst, an engineer. The team is self-managing, meaning it decides internally who does what and how.

What about the project manager?

That title doesn't appear in Scrum. Its duties are distributed: the Product Owner handles priority and value, the team organizes execution, and the Scrum Master looks after the process. In companies that adopt Scrum without changing the structure, the manager usually takes on one of those roles or moves on to managing the project portfolio and the relationship with executives.

The five Scrum events

Events exist to create rhythm and give opportunities to inspect and adapt. The times below are maximum limits from the Scrum Guide for a one-month sprint; for shorter sprints, the events are usually proportionally shorter.

The sprint

It's the heart of the method: a fixed-length period, one month at most, in which a usable increment is produced. During the sprint, the goal doesn't change, quality isn't reduced, and the scope can be renegotiated between the Product Owner and the team as more is learned. Constant length is an important practical rule: sprints of different sizes make it impossible to compare the velocity of one cycle with another.

Planning

It answers three questions: why this sprint is valuable (the sprint goal), what can be done (the items chosen from the backlog) and how the work will get done (the breakdown into tasks). The Product Owner brings the most important items; the team says how much it believes will fit, based on the velocity of previous cycles.

The Daily Scrum

Fifteen minutes, at the same time and place, for the team to adjust the plan for the next 24 hours. The three-question format (what I did yesterday, what I'll do today, what's blocking me) is an old convention; the current guide leaves the format open, as long as the focus is the sprint goal. A good daily is not a report to the boss: it's the team talking to each other in front of the board.

The review

It's not a formal presentation. It's a conversation in which the team shows what got done and interested people (customers, executives, other areas) weigh in. The outcome feeds the backlog: new items, discarded items, revised priorities.

The retrospective

The focus is on the process, not the product. The team answers what worked, what got in the way and what will change in the next sprint. The quality test is simple: it ends with one or two concrete actions, each with an owner, and the next retrospective starts by checking whether they were done. A retrospective that only produces venting becomes an empty meeting.

Artifacts and their commitments

Artifacts are the lists and results that make the work transparent. Each one has an associated commitment, which serves to provide focus.

Product backlog

An ordered list of everything known to be needed for the product. It's never "done": it evolves as you learn. Items at the top are small and well understood, because they'll be done soon; items at the bottom are big and vague, because they may change by then. The associated commitment is the product goal, the long-term target against which the backlog is measured.

The work of keeping the backlog in order is called refinement. It isn't a mandatory Scrum event, but most teams set aside a weekly slot to break down big items, clear up questions and estimate.

Sprint backlog

It's what the team pulled from the product backlog for the sprint, plus the plan for how to do it. It belongs to the developers, who update it during the sprint. The commitment is the sprint goal: a sentence that explains why the cycle exists, such as "let customers pay with PIX at checkout." If the scope changes during the cycle, the goal guides what stays and what goes.

Increment

The concrete, usable result of the sprint, added to the previous ones. It isn't "half-finished work": it's something that could be delivered. The commitment is the definition of done.

Definition of done

A list of criteria an item must meet to be considered complete. Without it, "done" means one thing to the developer, another to the Product Owner and a third to the customer. An example definition of done from a marketing agency: copy reviewed by another person, artwork approved by the client, link checked and piece scheduled in the publishing tool. An example from a software team: code reviewed, tests passing, documentation updated and deployed to the staging environment.

Epic, user story and task

These three words show up in every backlog and cause confusion. The simplest way to understand them is to think in terms of size. The following section summarizes the idea; the post Epic, user story and task goes deeper with more examples.

Example 1: online store

Casa do Café, an online store in Pouso Alegre, wants to sell a monthly subscription.

• Epic: monthly coffee subscription.
• User stories: "As a customer, I want to choose the type of bean and the delivery frequency, so I get my coffee the way I like it" and "As a customer, I want to pay for the subscription by PIX or credit card, so I don't depend on a single payment method."
• Tasks for the first story: design the selection screen, build the bean type catalog, code the shipping calculation, write the copy, test on mobile.

Example 2: HR

The people department at Metalúrgica Serra Azul, in Sorocaba, wants to improve the onboarding of new employees.

• Epic: onboarding of new employees.
• User stories: "As a new employee, I want to receive the first-week schedule before I start, so I know what to expect" and "As a manager, I want a checklist of access and equipment, so the new colleague finds everything ready on day one."
• Tasks for the second story: map the access needed in each area, build the checklist, agree on the workflow with IT, publish the template in the system.

How to write a good story

The classic format is "As a [who], I want [what], so that [why]." It forces the question about value: if you can't complete the "so that," the item may be a task in disguise. Besides the statement, a story needs acceptance criteria, which say when it has been met. "The customer can pay with PIX and receives the confirmation email in under a minute" is a testable criterion; "payment works well" is not.

A useful size test: if the story doesn't fit in one sprint, it's an epic and needs to be split. Splitting into vertical slices (a simple version that works end to end) is usually better than splitting by layers (just the database, then just the screen).

Points and velocity

What story points are

Points are a relative measure of effort, complexity and uncertainty. Instead of estimating in hours ("this takes 6 hours"), the team compares items with each other: "this one is twice as much work as that one." The most common scales follow the Fibonacci sequence (1, 2, 3, 5, 8, 13), because the bigger the item, the more uncertain the estimate, and the growing gaps reflect that.

The advantage of points is that they don't promise precision that doesn't exist and don't vary with who does the work. The drawback is that they're an abstract concept for outsiders; outside IT, many teams prefer to estimate in hours or simply count the number of items, as long as they're roughly the same size.

Planning poker, in one line

It's a group estimation technique: each person secretly picks a card with a value, and everyone reveals at the same time. If the values differ a lot, the people who gave the highest and lowest explain their reasoning, and the group votes again. The gain is in the conversation, not the number.

Velocity

Velocity is the sum of the points of the items completed in a sprint. If the team finished 21, 24 and 27 points in the last three sprints, the average is 24. For the next planning session, the team pulls in about 24 points, not the 40 that optimism suggests.

Three precautions prevent the misuse of velocity:

• Only completed items count. An item that's 90% done counts as zero. That encourages finishing over starting.
• Don't compare teams. A point on team A is not a point on team B. Velocity is for the team itself to forecast.
• Don't use it as a target. If velocity becomes a demand, the team inflates its estimates and the number loses its meaning.

Burndown: how to read the sprint chart

The burndown shows, day by day, how much work is still left in the sprint. The horizontal axis is days; the vertical is remaining work (in points, hours or number of items). The ideal line descends from the total to zero on the last day; the actual line shows what really happened.

• Actual line above the ideal: the team is behind the plan.
• Actual line below the ideal: it's ahead, and maybe there's room to pull in another item.
• Flat line for several days followed by a sharp drop: work is being completed in a batch at the end, a sign of items that are too big or a board that isn't updated enough.
• Line that rises: new scope came in mid-sprint.

The chart's value is in warning you early. On the Wednesday of the first week, seeing the line above the ideal still leaves time to take an item out of scope or ask for help. The post Burndown: how to read it has examples of each shape.

Scrum outside IT

Scrum's mechanism, which is short cycles, an ordered backlog, review and retrospective, works in any area. What usually goes wrong is importing everything at once, with the names and the ceremony. The post Sprints outside IT covers this at length; here is a summary by area.

At a condominium management company in Porto Alegre, for example, the maintenance team split the work into two tracks: the queue of day-to-day tickets keeps running in continuous flow, and each two-week period is reserved for planned work, such as painting the garage, swapping bulbs for LEDs and inspecting the fire extinguishers. The meeting at the start of the period chooses the jobs; the one at the end checks what the building manager approved. There's no "Product Owner": the contracts manager sets priorities. It works, and nobody had to memorize the vocabulary.

Common mistakes when adopting Scrum

1. Changing the sprint scope all the time. If everything changes along the way, it's continuous flow, and maybe Kanban is a better fit.
2. A sprint without a goal. Without a sentence explaining why the cycle exists, it's just a task list.
3. A Product Owner without decision-making power. If every priority needs approval from three executives, the backlog stalls.
4. Scrum Master as manager. When they hand out tasks and chase people, the team stops managing itself.
5. Backlog as a dumping ground. Two hundred items nobody reads. Discard what won't be done.
6. Done without a definition. Without clear criteria, the item comes back as rework in the next sprint.
7. Using velocity to pressure people. It exists to forecast, not to push.
8. The daily turning into a status meeting. Everyone talks to the manager, nobody talks to the team.
9. Skipping the retrospective. It's where the team improves. Without it, the same problems repeat every cycle.
10. A sprint that's too long. The longer the cycle, the later you find out it went off course.
11. Estimating in points without understanding the concept. If the team doesn't like points, estimate in hours or count items.
12. Ignoring what was left out. An item that wasn't finished goes back to the backlog and gets reassessed, instead of being automatically pushed to the next sprint.

How to start your first sprint

1. Choose the length. Two weeks is a good default. Fix it and stick with it.
2. Gather the backlog. Everything in one place, in priority order, with the top items well described.
3. Define who prioritizes and who facilitates. Who is the Product Owner? Who facilitates the process? They can be people with other job titles.
4. Write the definition of done. Three to five criteria are enough to start.
5. Plan with slack. In the first sprint, pull in about 60% of what you think will fit. Estimating without history is a guess; the first cycle exists to create that history.
6. Hold the daily and update the board. Fifteen minutes, same time.
7. Close with a review and a retrospective. Without them, it's just a calendar with a fancy name.

After two or three sprints, velocity starts to mean something, and planning begins to rely on data. The backlog and sprint template brings a filled-in spreadsheet for you to adapt.

Scrum and Kanban together

Many teams use both: Scrum provides the rhythm (cycles, planning, review), and the Kanban board shows progress within the sprint, with a work-in-progress limit on the middle columns. The Kanban guide explains the other side. A practical rule: if your work can be planned in two-week chunks, use sprints; if it arrives unpredictably and needs a fast response, use continuous flow; if it's a mix, separate the two tracks, as in the condominium management example.

How to do it in Tasskee

Tasskee sprints cover the whole cycle, from backlog to the close-out report. They're part of the Pro plan.

• Backlog. Tasks that haven't entered any cycle yet stay in the backlog, in priority order.
• Cycle planning. You pull from the backlog what fits in the sprint, with an estimate and an assignee, and lock the scope with everyone watching.
• One sprint, several projects. The same cycle can gather tasks from different projects, which is how many teams really work.
• Sprint board. The cycle's tasks show up on the Kanban board, which can be grouped by assignee, priority or sprint.
• Daily burndown. Follow the chart from day one and find out mid-cycle, not on the eve, whether you'll make it in time.
• Velocity. The average of previous cycles serves as the basis for the next planning session.
• Close-out report. Shows what was planned, what was completed and what went back to the backlog, without erasing the history.
• Flow metrics. Lead time, cycle time and cumulative flow in the reports, to find the stage where work gets stuck.

To get the team started with something filled in, use the backlog and sprint template. And if your cycles need to push bigger objectives forward, link them to the quarterly goals.