Agile & Scrum
A complete BA revision guide for understanding the Agile mindset, Scrum framework, Product Backlog, Sprint Backlog, Scrum events, user stories, acceptance criteria, estimation, Agile metrics, and interview-ready answers.
Agile is a mindset for delivering value through collaboration, feedback, flexibility, and iterative delivery. Scrum is a lightweight Agile framework that provides structure through Sprints, roles, events, artifacts, and commitments.
What is Agile?
Agile is a mindset and set of values/principles used to deliver business value through collaboration, feedback, flexibility, and iterative delivery. Agile is not a tool, meeting, or process — it is a way of working where teams deliver small increments, get feedback early, and adapt to changing business needs.
- A mindset
- Value-driven
- Feedback-oriented
- Iterative
- Collaborative
- Adaptive
- Focused on working outcomes
- No documentation
- No planning
- Random changes
- No process
- Only daily meetings
- Only Scrum
- Developer-only approach
Agile Manifesto Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile does not mean avoiding documentation or planning. It means creating the right level of documentation and planning to support delivery without slowing down value.
Agile is a mindset based on values and principles that focus on delivering customer value through collaboration, frequent feedback, adaptability, and iterative delivery. It does not mean no documentation or no planning — it means enough of both to support delivery without slowing the team down.
What is Scrum?
Scrum is a lightweight Agile framework used to deliver value in short iterations called Sprints. It gives structure to Agile by defining accountabilities, events, artifacts, and commitments.
- Product Owner
- Scrum Master
- Developers
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- Product Backlog
- Sprint Backlog
- Increment
- Product Goal
- Sprint Goal
- Definition of Done
Scrum is a lightweight Agile framework where a cross-functional team delivers value through short Sprints. It provides structure through accountabilities, events, artifacts, and commitments — Product Backlog, Sprint Backlog, Increment, Sprint Goal, and Definition of Done.
Agile vs Scrum
| Topic | Agile | Scrum |
|---|---|---|
| Type | Mindset / philosophy | Framework |
| Purpose | Deliver value through collaboration and adaptability | Implement Agile through Sprints and defined structure |
| Scope | Broad way of working | Specific Agile framework |
| Includes | Values and principles | Accountabilities, events, artifacts, commitments |
| Delivery | Iterative and incremental | Timeboxed Sprint-based delivery |
| Examples | Scrum, Kanban, XP, Lean | Backlog, Planning, Daily Scrum, Review, Retro |
Agile is a mindset based on values and principles, while Scrum is a framework used to implement Agile. Agile tells us how to think; Scrum gives us a structure for execution through Sprints, accountabilities, events, artifacts, and commitments.
Scrum Lifecycle — How Scrum Works End-to-End
- 1Product Goal
Defines the future product objective.
- 2Product Backlog
Ordered list of work needed to improve the product.
- 3Backlog Refinement
Clarify, split, estimate, and prepare backlog items.
- 4Sprint Planning
Select Sprint work and define Sprint Goal.
- 5Sprint Backlog
Selected work plus plan for delivery.
- 6Sprint Execution
Team builds, tests, clarifies, and delivers.
- 7Daily Scrum
Team inspects progress toward Sprint Goal.
- 8Increment
Usable completed product output.
- 9Sprint Review
Stakeholders inspect Increment and provide feedback.
- 10Sprint Retrospective
Team improves process for the next Sprint.
- 11Updated Product Backlog
Feedback and learnings update future priorities.
Scrum is iterative: the PO manages the Product Backlog, the team refines items, Sprint Planning defines the Sprint Goal and Sprint Backlog, Developers build a usable Increment, Daily Scrum inspects progress, Sprint Review gathers stakeholder feedback, and Retrospective improves the next Sprint.
Scrum Roles / Accountabilities
Product Owner
Maximizes product value and manages Product Backlog.
- Defines product direction and Product Goal
- Owns and orders Product Backlog
- Clarifies business value
- Aligns stakeholders
- Makes priority decisions
- Accepts or rejects completed work
- Ensures backlog transparency
- Assign tasks to Developers
- Control how Developers build
- Change Sprint scope casually
- Replace stakeholder collaboration
“The Product Owner maximizes product value and manages the Product Backlog. They order items, clarify priorities, align stakeholders, and accept completed work based on value, AC, and DoD.”
Scrum Master
Helps the team and organization use Scrum effectively.
- Facilitates Scrum events
- Removes impediments
- Coaches the team on Scrum
- Supports self-management
- Protects team focus
- Supports PO with backlog practices
- Helps organization improve Agile adoption
- Encourages continuous improvement
- Act as command-and-control project manager
- Assign tasks
- Own requirements
- Own product priority
“The Scrum Master helps the team use Scrum effectively, facilitates events, removes impediments, coaches the team, supports the PO, and improves Scrum adoption.”
Developers
Create the usable Increment each Sprint.
- Create Sprint plan
- Build, test, and deliver Increment
- Self-manage work
- Ensure quality
- Meet Definition of Done
- Adapt plan during Sprint
- Are not only coders — includes QA, designers, analysts, DB specialists
“In Scrum, Developers are everyone who creates the usable Increment. They self-manage Sprint work, build and test the product, and deliver work meeting the DoD.”
Business Analyst Role in Scrum
A Business Analyst is not a formal Scrum accountability, but many Scrum teams include BAs to support the Product Owner, Developers, QA, and stakeholders.
Analyzes requirements, clarifies rules, writes stories/AC, supports QA/UAT.
Owns product value, prioritization, backlog ordering, stakeholder alignment.
Owns Scrum effectiveness, facilitation, impediment removal, coaching.
A BA is not a formal Scrum accountability, but supports the PO and team by refining backlog items, writing stories and AC, clarifying business rules, identifying dependencies, supporting planning, answering requirement questions, reviewing test scenarios, helping with defect triage, and supporting UAT.
Product Backlog
- • Features
- • Enhancements
- • Bugs
- • Technical debt
- • Spikes/research
- • Compliance items
- • Non-functional needs
- • Integration work
- • Reporting needs
- Ordered by value/priority
- Evolves with feedback and risk
- Transparent to team and stakeholders
- Owned by the Product Owner
- Continuously refined
The Product Goal is the commitment for the Product Backlog and describes a future product objective the team works toward.
Product Backlog is an ordered and evolving list of everything needed to improve the product. The PO owns ordering, and the BA supports by refining items, writing stories, defining AC, and clarifying rules and dependencies.
Sprint Backlog
Sprint Backlog is the selected work for the Sprint plus the plan to deliver it. It includes the Sprint Goal, selected backlog items, and the delivery plan.
“Enable users to submit and track service requests online.”
- Owned by Developers
- Flexible plan, updated as the team learns
- Focused on the Sprint Goal
- Visible and inspectable
Sprint Backlog includes the Sprint Goal, selected items, and delivery plan. It is owned by Developers and updated throughout the Sprint as more is learned.
Product Backlog vs Sprint Backlog
| Topic | Product Backlog | Sprint Backlog |
|---|---|---|
| Purpose | All product work | Work selected for current Sprint |
| Owner | Product Owner | Developers |
| Scope | Entire product | Current Sprint |
| Changes | Continuously evolves | Updated during Sprint by Developers |
| Commitment | Product Goal | Sprint Goal |
| Example | All features, bugs, improvements | Stories selected for Sprint 12 |
Scrum Events / Ceremonies
Sprint
A fixed-length iteration where the team works toward a Sprint Goal and produces a usable Increment.
- • Timeboxed, usually 1–4 weeks
- • Has a Sprint Goal
- • Produces usable Increment
- • New Sprint starts immediately after the previous one
Clarify requirements, answer dev/QA questions, support test scenario review, help PO with feedback.
Sprint Planning
Decide why the Sprint is valuable, what can be done, and how the work will be delivered.
- • Inputs: prioritized backlog, Product Goal, capacity, velocity, DoD
- • Outputs: Sprint Goal, selected items, Sprint Backlog, initial plan
Clarify story details, explain AC, identify dependencies, confirm readiness, support PO in explaining value.
Daily Scrum
A 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt their plan.
- • Not a manager status meeting
- • Focus: are we on track to meet the Sprint Goal?
Participate if part of Sprint work, clarify requirement blockers, take detailed discussion offline.
Backlog Refinement
Ongoing activity of clarifying, splitting, estimating, and preparing backlog items for future Sprints.
- • Break epics into stories
- • Add AC and business rules
- • Identify dependencies
- • Estimate and prioritize
Convert requirements into stories, ensure stories are small/testable, clarify edge cases, meet DoR.
Sprint Review
The team and stakeholders inspect the completed Increment and adapt the Product Backlog based on feedback.
- • Demo completed work
- • Collect stakeholder feedback
- • Update Product Backlog
Help prepare demo scenarios, validate stories, capture feedback, convert feedback into backlog items.
Sprint Retrospective
The team inspects how the Sprint went and identifies improvements for the next Sprint.
- • What went well / didn’t / improve / actions
Raise clarity issues, suggest better refinement, improve testing/UAT collaboration, reduce rework.
Scrum Artifacts & Commitments
| Artifact | Commitment | Meaning |
|---|---|---|
| Product Backlog | Product Goal | Future product objective |
| Sprint Backlog | Sprint Goal | Objective of the Sprint |
| Increment | Definition of Done | Quality standard for completed work |
Increment = usable product output completed during a Sprint that meets DoD, adds value, and is potentially releasable — moving the product toward the Product Goal.
Definition of Done & Definition of Ready
Definition of Done
Shared quality standard for completed work.
- Code complete
- Peer reviewed
- Unit tested
- QA tested
- Acceptance criteria met
- No critical defects open
- Regression impact checked
- Documentation updated
- Product Owner accepted
- Deployed to test/staging if applicable
Definition of Ready
Team agreement that helps decide whether a story is ready to enter a Sprint. Not an official Scrum artifact.
- Story has clear description
- Acceptance criteria written
- Business rules documented
- Dependencies identified
- Designs/wireframes available if needed
- Test data needs understood
- Story is small enough
- Open questions resolved or tracked
| Definition of Ready | Definition of Done |
|---|---|
| Ready to start | Complete and releasable |
| Before Sprint | During/end of Sprint |
| Focuses on clarity | Focuses on quality |
| Helps planning | Helps acceptance |
| Common team agreement | Official Scrum commitment |
DoR means a story is clear enough to start. DoD means the work is complete and meets the team’s quality standard. DoR focuses on readiness; DoD on completion.
User Stories
“As a [user/role], I want [capability], so that [business benefit].”
“As a supervisor, I want to approve or reject submitted requests so that only valid requests move forward in the workflow.”
- Only requests in Submitted status can be reviewed
- Only Supervisor role can approve or reject
- Approved → Approved status
- Rejected → Rejected status
- System sends notification after action
- Given Submitted, when Supervisor clicks Approve, then status = Approved
- Given Submitted, when Supervisor clicks Reject, then status = Rejected
- Given non-supervisor opens request, Approve/Reject buttons are hidden
- When status changes, system notifies the requester
Business user, supervisor, admin, customer, analyst.
Submit, approve, search, upload, export, etc.
Track status, reduce manual work, validate, support reporting.
Define when the story is complete.
Validations, permissions, status, data, edge cases.
Confirm story quality.
Techniques for Better Stories
INVEST Checklist
| Letter | Meaning | BA Check |
|---|---|---|
| I | Independent | Deliverable without too many dependencies? |
| N | Negotiable | Flexible enough for discussion? |
| V | Valuable | Delivers business/user value? |
| E | Estimable | Team can estimate it? |
| S | Small | Fits in a Sprint? |
| T | Testable | QA can verify pass/fail? |
3C Technique
Short written story.
Discussion between PO, BA, Devs, QA, and stakeholders.
Acceptance criteria that confirm completion.
User Story Mapping
Organize stories around the user journey.
Story Splitting — Common Ways
When a story is too large, I split it by workflow step, user role, business rule, data group, operation, channel, or happy path vs exception. The goal: small, valuable, testable within a Sprint.
Acceptance Criteria
Acceptance criteria define the conditions that must be met for a story to be accepted. They make the story clear, measurable, and testable.
Precondition
User action or system event
Expected result
Given a request is in Submitted status, when the Supervisor clicks Approve, then the system shall update the status to Approved and send an approval notification.
“System should allow approval.”
“Search should be fast.”
“Given a request is in Submitted status, when a Supervisor clicks Approve, then the status updates to Approved, the approval timestamp is recorded, and a notification is sent.”
“Given the user searches by request ID, when search is submitted, then matching results display within 3 seconds under normal load.”
I write AC in Given/When/Then format covering happy, alternate, and negative paths, validations, permissions, status changes, and expected results so the story is testable.
Story Sizing & Estimation
Story sizing estimates relative effort, complexity, uncertainty, and risk — it is not exact time estimation. Story points are relative, not hours.
- • Effort
- • Complexity
- • Risk
- • Uncertainty
- • Dependencies
- • Testing effort
- • Integration impact
- • Data complexity
- • UI complexity
- • Business rule complexity
- Clarify requirement scope and AC
- Explain business rules and edge cases
- Identify dependencies and impacted systems
- Help reduce uncertainty
- Do not force estimates on Developers
Estimation Techniques
| Technique | Best Used For | Strength | Watch Out |
|---|---|---|---|
| Planning Poker | Collaborative Sprint-level estimation | Encourages discussion | Can take time |
| Fibonacci | Story point estimation | Reflects uncertainty | Needs team calibration |
| T-Shirt Sizing | Early rough sizing | Simple and fast | Less precise |
| Affinity Estimation | Many backlog items | Fast grouping | May miss details |
| Bucket System | Fast sizing with buckets | Efficient | Needs clear bucket meaning |
| Relative Estimation | Compare to known stories | Practical | Needs reference stories |
| Ideal Days | Time-based planning | Easy for beginners | Can be mistaken for commitment |
| Dot Voting | Identify risky/unclear items | Quick signal | Not final estimate |
Story Points, Velocity & Capacity
Relative size of a story (e.g., 5 points).
Completed points per Sprint (forecasting, not pressure).
Team’s available effort for the Sprint.
Burndown Chart
A burndown chart shows remaining work over time during a Sprint and answers: “Are we on track to complete Sprint work?”
A burndown chart shows remaining work and helps the team inspect whether they are on track. As a BA, I use trends to detect unclear stories, missed dependencies, large items, or late testing.
Other Agile Metrics BAs Should Know
| Metric | Meaning | BA Relevance |
|---|---|---|
| Velocity | Completed story points per Sprint | Forecasting |
| Capacity | Available team effort | Sprint planning |
| Burndown | Remaining work trend | Sprint tracking |
| Burnup | Completed work vs total scope | Scope visibility |
| Cycle Time | Time from start to finish | Process efficiency |
| Lead Time | Request to delivery time | Business responsiveness |
| Defect Leakage | Defects found after release | Quality gap |
| Escaped Defects | Production defects | Requirement/testing improvement |
| Story Spillover | Stories not completed | Readiness or estimation issue |
| Rework Rate | Work redone | Requirement clarity issue |
Prioritization in Agile
Prioritization is owned by the PO; as a BA I support it by analyzing business value, urgency, risk, dependencies, compliance, user impact, and effort. Techniques like MoSCoW, value-vs-effort, RICE, or WSJF make it transparent.
MVP — Minimum Viable Product
- Usable
- Valuable
- Testable
- Feedback-ready
- Built with required quality
- Low quality
- Incomplete
- Prototype only
- Everything business wants
MVP is the minimum usable version that delivers value and enables feedback. It is not low quality or incomplete. As a BA, I identify must-have requirements, defer lower-priority items, and ensure the MVP meets core business needs.
Handling Changing Requirements
- Refine requirement
- Add/update Product Backlog item
- Prioritize with PO
- Pull into future Sprint if valuable
- Does it affect the Sprint Goal?
- Is it urgent? Can it wait?
- What work should be removed if added?
- Does PO agree?
- What is the testing & dependency impact?
Defects & Agile Testing / UAT
- Story defect
- Regression defect
- UAT defect
- Production defect
- Requirement defect
- Clarify expected behavior
- Determine defect vs change request
- Support defect triage by impact
- Update story/AC if needed
- Support retesting and UAT
In Agile, testing happens continuously. As a BA, I make stories testable through clear AC, review test scenarios, clarify expected results, support defect triage, and help business users during UAT.
Common Scrum Anti-Patterns
Many Scrum issues come from poor refinement, unclear AC, unavailable stakeholders, weak DoD, or constant scope changes. As a BA, I help reduce these by improving requirement clarity and story readiness.
Topics Checklist — A Strong BA Should Know
Interview Answer Bank
Top 1% BA Language — Say This, Not That
“I write requirements.”
“I refine backlog items into clear, valuable, small, and testable user stories.”
“I attend Scrum meetings.”
“I support Scrum events by clarifying requirements, dependencies, AC, and rules.”
“I write user stories.”
“I define user role, capability, value, AC, business rules, and testable outcomes.”
“I help developers.”
“I reduce delivery ambiguity by clarifying edge cases, data rules, validations, and dependencies.”
“I help QA.”
“I make stories testable through clear acceptance criteria and expected results.”
“I estimate stories.”
“I support estimation by reducing uncertainty — Developers own the estimate.”
“I manage change.”
“I perform impact analysis and support PO backlog prioritization.”
“I support Agile.”
“I help the team deliver value through clear refinement, Sprint readiness, and stakeholder feedback.”
Master Interview Answer
“Agile is a mindset focused on delivering customer value through collaboration, adaptability, feedback, and iterative delivery. Scrum is a lightweight Agile framework where a cross-functional team delivers value in short Sprints using defined accountabilities, events, artifacts, and commitments.
Scrum starts with a Product Backlog aligned to a Product Goal. The team continuously refines items, Sprint Planning defines the Sprint Goal and Sprint Backlog. During the Sprint, the team works toward the Sprint Goal and uses Daily Scrum to inspect progress. At the end, they produce a usable Increment that meets the DoD, review it with stakeholders, and improve the process in Retrospective.
As a BA, I support the PO and Scrum Team by refining backlog items, writing user stories and AC, clarifying business rules, identifying dependencies, supporting Sprint Planning, answering requirement questions during the Sprint, reviewing test scenarios, supporting defect triage, capturing Sprint Review feedback, and helping with UAT — making stories clear, valuable, small, and testable so the team can deliver value every Sprint.”
Final Memory Table
| Topic | Quick Memory |
|---|---|
| Agile | Mindset |
| Scrum | Framework |
| Sprint | Timeboxed delivery cycle |
| Product Backlog | Ordered list of product work |
| Sprint Backlog | Selected Sprint work plus plan |
| Product Goal | Long-term product objective |
| Sprint Goal | Objective of Sprint |
| Increment | Usable completed output |
| Definition of Done | Quality standard for completion |
| Definition of Ready | Story readiness checklist |
| Refinement | Prepare stories for future Sprints |
| Sprint Planning | Decide goal, work, and plan |
| Daily Scrum | Inspect progress toward Sprint Goal |
| Sprint Review | Inspect Increment with stakeholders |
| Retrospective | Improve team process |
| User Story | As a / I want / so that |
| Acceptance Criteria | Given / When / Then |
| INVEST | Story quality checklist |
| 3C | Card, Conversation, Confirmation |
| Story Splitting | Break large stories into small valuable stories |
| Story Sizing | Estimate relative effort/complexity/risk/uncertainty |
| Planning Poker | Collaborative estimation |
| Fibonacci | Common story point scale |
| T-Shirt Sizing | Rough early sizing |
| Velocity | Completed work per Sprint |
| Capacity | Available team effort |
| Burndown | Remaining work trend |
| MVP | Minimum usable valuable product |
Ready to Practice?
Use this guide to revise Agile and Scrum concepts, Scrum roles, ceremonies, artifacts, backlog management, user stories, acceptance criteria, story sizing, Agile metrics, and interview answers for BA and PO roles.
Back to BA Skills Resources