1. What is a burndown chart?
A burndown chart is a simple line chart that shows how much work remains in a sprint versus how much time is left. It is the Scrum team’s quickest way to see whether they are on track to finish.
The chart has two axes. The horizontal axis is time — the days of the sprint. The vertical axis is the amount of work remaining, measured in story points or hours. Before the sprint starts, the team draws an ideal line from the total work at the top-left down to zero on the last day at the bottom-right. Then, each day of the sprint, they plot the actual amount of work remaining and connect the points.
ASCII diagram:
Work
Remaining
^
|\
| \
| \ Ideal
| \
| \
| \__
| \__
| \__
| \__
| \__ Actual
|
+----------------------------> Time
Day 1 Day 2 Day 3 Day 4 Day 5Reading the chart is intuitive. If the actual line is below the ideal line, the team is ahead of schedule. If it is above, they are behind. If the line stays stubbornly high and flat, something is wrong — a blocker, a wrong estimate, an unplanned task — and the team needs to adjust.
The chart does not tell you about quality or morale; it tracks only the quantity of work remaining. But that single number is remarkably useful. It keeps the whole team aligned on the sprint goal, makes delays visible within a day or two, and gives everyone a constant, honest picture of progress. When a team says “we’re behind,” the burndown chart is usually where they saw it first.
2. What are Scrum ceremonies?
Scrum ceremonies are the recurring meetings that structure a sprint. They are Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. Together they give Scrum its rhythm of planning, inspecting, and adapting.
ASCII diagram:
+------------------+
| Sprint Planning |
+--------+---------+
|
v
+------------------+
| Daily Scrum |
+--------+---------+
|
v
+------------------+
| Sprint Execution |
+--------+---------+
|
v
+------------------+
| Sprint Review |
+--------+---------+
|
v
+------------------+
| Retrospective |
+--------+---------+
|
v
Next SprintSprint Planning starts each sprint. The team decides what to build — selecting items from the product backlog — and how to build it, breaking the items into tasks. The output is the sprint backlog and a sprint goal.
The Daily Scrum happens every day of the sprint, time-boxed to 15 minutes. Each team member answers three questions: what did I do yesterday, what will I do today, and what is blocking me. Its purpose is alignment and early detection of blockers, not problem-solving.
The Sprint Review happens at the end of the sprint. The team demonstrates what they built to stakeholders and gathers feedback. The stakeholders see real working software, and their reactions shape what happens next.
The Sprint Retrospective happens after the review. The team looks inward at its own process — what went well, what did not, what to change. The goal is continuous improvement: each sprint should leave the team slightly better than the last.
| Ceremony | Purpose |
|---|---|
| Sprint Planning | Set the goal and select the work |
| Daily Scrum | Sync daily and surface blockers |
| Sprint Review | Show results and gather feedback |
| Retrospective | Improve the team’s process |
The four ceremonies are the cadence of Scrum. Planning sets direction, the daily meeting keeps it on track, the review validates it with stakeholders, and the retrospective makes the team itself better. A sprint without them is just a deadline.
3. What are Scrum artifacts?
Scrum artifacts are the three things that make the work of a sprint visible: the Product Backlog, the Sprint Backlog, and the Increment. They exist so that everyone can see what is planned, what is being done, and what has been delivered.
ASCII diagram:
SCRUM ARTIFACTS
|
+--------------+--------------+
| | |
v v v
+---------------+ +---------------+ +---------------+
| Product | | Sprint | | Increment |
| Backlog | | Backlog | | |
+---------------+ +---------------+ +---------------+
| What could | | What is being | | What has |
| be built | | built now | | been delivered|
+---------------+ +---------------+ +---------------+
| | |
v v v
Future work Current work Working productThe Product Backlog is the ordered list of everything that might go into the product — features, fixes, and improvements, ordered by value. It is owned by the Product Owner and is never finished; it evolves as the product and priorities change.
The Sprint Backlog is the set of items from the product backlog that the team committed to in the current sprint, broken into tasks. It is owned by the development team and represents their plan for the sprint.
The Increment is the usable, working product produced at the end of the sprint — the sum of everything done so far, plus the new work. It must be usable and meet the team’s definition of done.
The artifacts matter because they provide transparency. Scrum’s promise is that everyone — the team, the Product Owner, the stakeholders — can look at the three artifacts and understand the true state of the work. The backlog shows what could be built, the sprint backlog shows what is being built now, and the increment shows what has actually been delivered.
Transparency enables the other two pillars of Scrum: inspection and adaptation. When the artifacts are visible and honest, the team can inspect progress at the ceremonies and adapt the plan accordingly. Hidden or vague artifacts break all of that — you cannot inspect what you cannot see.
4. What are the roles in a Scrum Team?
A Scrum Team has three roles: the Product Owner, the Scrum Master, and the Developers. There is no project manager — the three roles split the responsibilities a traditional project manager would hold.
ASCII diagram:
SCRUM TEAM
|
+--------------+--------------+
| | |
v v v
+----------------+ +----------------+ +----------------+
| Product Owner | | Scrum Master | | Developers |
+----------------+ +----------------+ +----------------+
| Owns "WHAT" | | Owns "HOW THE | | Own "HOW TO |
| to build | | TEAM WORKS" | | BUILD IT" |
+----------------+ +----------------+ +----------------+
| | |
v v v
Priorities & Process & Design, code,
backlog blockers test & deliverThe Product Owner owns the “what.” They manage the product backlog, order items by value, and decide what the team builds next. They represent the customer and the business, and they are the single voice of priorities. If two stakeholders want different things, the Product Owner decides.
The Scrum Master owns the “how the team works.” They coach the team on Scrum, protect them from distractions, and — their most practical job — remove impediments that block progress. If the test environment is broken, the Scrum Master gets it fixed. The Scrum Master serves the team, not the other way around.
The Developers own the “how to build it.” They are the people who design, code, test, and deliver the increment. Crucially, they are self-organizing: the team decides internally how to do the work, rather than being told by a manager. The Developers are accountable as a group for delivering the sprint.
| Role | Responsibility |
|---|---|
| Product Owner | What to build, and in what order |
| Scrum Master | Process, coaching, removing blockers |
| Developers | How to build the product |
The three roles are designed to be cross-functional and self-managing. The Product Owner points the team at the highest-value work, the Scrum Master keeps the process healthy, and the Developers figure out how to get the work done. Each role is accountable for a different part of the Scrum engine.
5. How does DevOps complement the SDLC?
DevOps is a set of practices that extends the SDLC beyond development into operations, joining the two so that software can be built, tested, and delivered faster and more reliably.
ASCII diagram:
TRADITIONAL SDLC
Requirements -> Design -> Development -> Testing -> Deployment
|
v
Operations
DEVOPS APPROACH
+---------------------------------------------+
| |
v |
+-----------+ +-----------+ +-----------+ |
| Plan | -> | Code | -> | Build | |
+-----------+ +-----------+ +-----------+ |
^ | |
| v |
+-----------+ +-----------+ +-----------+ |
| Monitor | <- | Operate | <- | Test | |
+-----------+ +-----------+ +-----------+ |
| |
+---------------------------------------------+
Continuous FeedbackTraditionally, development and operations were separate worlds with different goals. Developers wanted to ship new features fast; operations wanted stability and avoided change, because change risked breaking things. That tension produced slow, painful releases. DevOps breaks down the wall between the two teams.
The core of DevOps is automation of the entire delivery pipeline. Continuous Integration means code changes are merged and tested constantly, so problems are found within minutes of being introduced. Continuous Delivery means the code is always in a deployable state, and releases are automated rather than risky manual events. Monitoring and feedback close the loop — the software’s behavior in production is measured and fed back to the team.
ASCII pipeline:
Developer
|
v
+---------+
| Code |
+----+----+
|
v
+---------+
| CI |
| Build |
+----+----+
|
v
+---------+
| Test |
+----+----+
|
v
+---------+
| CD |
| Deploy |
+----+----+
|
v
+---------+
|Production|
+----+----+
|
v
+---------+
| Monitor |
+----+----+
|
+--------------------+
|
v
Developer
FeedbackThe results are measurable. Release cycles shrink from months to days or hours. Release failures drop, because testing and deployment are automated and consistent. And because issues are caught early in the pipeline, they are cheaper to fix.
DevOps complements the SDLC by adding what the classic SDLC leaves out. The traditional SDLC ends at deployment — hand the product to operations and move on. DevOps extends the lifecycle, treating operations as part of the development team and making deployment, monitoring, and feedback first-class parts of the process. The SDLC defines how to build software; DevOps defines how to keep building and shipping it, continuously and reliably.
Premium Content
Unlock Top 50 Placement Questions - Part 4 and all premium lessons with a subscription.
From ₹199.99/year — See plans