⏳
Loading cheatsheet...
Scrum, Kanban, sprints, user stories, velocity, retrospectives, ceremonies, and agile frameworks.
Agile is a set of values and principles for software development under which solutions evolve through collaborative effort. It is not a methodology itself but a philosophy that underpins frameworks like Scrum, Kanban, XP, and SAFe. Understanding Agile fundamentals is essential for every software professional.
| We Value (Left) | More Than | We Still Value (Right) | In Practice (India IT Context) |
|---|---|---|---|
| Individuals and Interactions | > | Processes and Tools | Daily standups, face-to-face沟通, pair programming over heavy documentation and rigid Jira workflows |
| Working Software | > | Comprehensive Documentation | Deploy working features every sprint; test automation; CI/CD pipeline; docs support but do not replace working code |
| Customer Collaboration | > | Contract Negotiation | Product Owner involved daily; sprint reviews with stakeholders; feedback loops; user stories co-created with business |
| Responding to Change | > | Following a Plan | Re-prioritize backlog every sprint; pivot when needed; short iterations reduce cost of change; plan is a living document |
A Sprint is a time-boxed iteration (typically 1-4 weeks, most commonly 2 weeks) during which a specific set of work must be completed and made ready for review. Sprints provide a predictable cadence for planning, delivery, and feedback.
| Event | When | Duration | Participants | Output |
|---|---|---|---|---|
| Sprint Planning | Day 1 of sprint | 2 hrs (2-week sprint) | PO + SM + Dev Team | Sprint Goal, Sprint Backlog (committed user stories + tasks) |
| Daily Standup | Every day, same time | 15 minutes | Dev Team (+ SM facilitates) | Updated task board, identified impediments, alignment |
| Backlog Refinement | Mid-sprint (optional) | 1-2 hours | PO + Dev Team | Refined, estimated, prioritized backlog items for upcoming sprints |
| Sprint Review | Last day of sprint | 2 hrs (2-week sprint) | Scrum Team + Stakeholders | Demo of completed work, stakeholder feedback, updated backlog |
| Sprint Retrospective | After Sprint Review | 1.5 hrs (2-week sprint) | Scrum Team only | Actionable improvements for next sprint |
| Metric | Definition | How to Calculate | Use Case |
|---|---|---|---|
| Velocity | Total story points completed per sprint | Sum of story points of all completed user stories in a sprint | Predict how much work the team can deliver in future sprints; use average of last 3-5 sprints |
| Capacity | Total available working hours in a sprint | (Team size x working days x hours per day) - (meetings, PTO, support, other commitments) | Plan sprint realistically based on actual available time, not team size alone |
| Sprint Burn-down | Visual chart showing remaining work vs time | Y-axis: remaining story points; X-axis: sprint days; ideal line: straight diagonal | Track sprint progress daily; identify if team is behind early enough to take action |
| Sprint Burn-up | Visual chart showing completed work vs time | Y-axis: completed story points; X-axis: sprint days; shows scope changes too | Track completed work and scope changes; useful when scope changes during sprint |
| Commitment vs Completion | Compare planned vs actual delivery | Track: committed points vs completed points per sprint | Improve estimation accuracy over time; identify consistently under/over-committing sprints |
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability (the user). They are the building blocks of every sprint backlog. Story points are a relative estimate of the effort required to complete a user story.
| Component | Description | Example |
|---|---|---|
| User Story Format | As a [role], I want [feature], so that [benefit/value] | As a registered user, I want to reset my password via email, so that I can regain access to my account if I forget it |
| Acceptance Criteria | Conditions that must be met for the story to be "done" | 1. User clicks "Forgot Password" link, 2. Enters registered email, 3. Receives reset link within 2 minutes, 4. Link expires after 24 hours, 5. New password must meet complexity rules |
| Definition of Done (DoD) | Global criteria that apply to ALL stories | Code reviewed, unit tests pass (>80% coverage), QA tested, no critical/high bugs, deployed to staging, documentation updated, PO approved |
| INVEST Criteria | Good user story qualities | Independent, Negotiable, Valuable, Estimable, Small, Testable |
| Points | Effort Level | Description | Example Story |
|---|---|---|---|
| 1 | Trivial | Under 1 hour; simple bug fix, text change, CSS tweak | Change button color from blue to green on the login page |
| 2 | Simple | 1-4 hours; minor feature, simple logic, no external dependencies | Add phone number field to the registration form |
| 3 | Medium-Simple | Half a day; straightforward feature with minor logic | Implement email validation on the contact form |
| 5 | Medium | 1-2 days; standard feature with moderate complexity | Build user profile page with edit functionality and validation |
| 8 | Medium-Complex | 2-3 days; complex feature, multiple components, API integration | Build shopping cart with add/remove items and quantity update |
| 13 | Complex | 3-5 days; very complex feature, external APIs, significant testing | Build payment integration with Razorpay including retry and refund flows |
| 21 | Very Complex | 5-8 days; major feature requiring design, multiple APIs, significant testing | Build complete order management system with status tracking and notifications |
| ? | Unknown | Too complex to estimate; needs research/spike first | Evaluate 3 different search engine options and recommend one for the product |
Scrum defines five events (ceremonies) that provide structure and regularity to the development process. When done well, these ceremonies create transparency, inspection, and adaptation — the three pillars of empirical process control that Scrum is built upon.
| Format | How It Works | Best For | Time Needed |
|---|---|---|---|
| Start-Stop-Continue | Team lists: what should we START doing, STOP doing, CONTINUE doing | New teams, first retrospective | 45-60 minutes |
| 4Ls (Liked, Learned, Lacked, Longed For) | Review: what did you like, learn, lack, and long for in this sprint | Mid-project retrospectives | 60-90 minutes |
| Sailboat | Draw a sailboat: wind (helps), anchors (slows), rocks (risks), island (goals) | Visual teams, identifying risks | 60-90 minutes |
| Mad-Sad-Glad | Team shares emotions: what made them mad, sad, and glad this sprint | Teams with interpersonal issues | 45-60 minutes |
| Timeline Retrospective | Plot sprint events on a timeline; discuss highs and lows | Long or eventful sprints | 60-90 minutes |
| Lean Coffee | Participants propose topics, vote on most important, discuss top-voted topics | Experienced teams, self-facilitated | 60-90 minutes |
When multiple teams need to work together on large products, a simple Scrum implementation is not enough. SAFe (Scaled Agile Framework) provides a structured approach for scaling Agile practices across the enterprise. It is the most widely adopted scaled Agile framework globally, used by many large Indian enterprises.
| Concept | Description | Key Elements |
|---|---|---|
| Agile Release Train (ART) | A team of Agile teams (50-125 people) that plans, commits, and executes together | PI Planning, System Demo, Inspect & Adapt, Scrum of Scrums |
| Program Increment (PI) | A timebox (8-12 weeks, typically 10 weeks = 5 sprints) during which an ART delivers value | PI Planning event, PI Objectives, stretch goals, confidence vote |
| PI Planning | A 2-day face-to-face event where all teams on the ART plan the upcoming Program Increment together | Business context, team breakouts, dependency management, risk identification, confidence vote |
| Lean-Agile Budgeting | Funding is allocated to value streams, not individual projects; lean budgets enable agility | Guardrails instead of detailed budgets; participatory budgeting; horizon-based funding |
| Value Stream | The series of steps an organization takes to deliver a product or service to customers | Operational value stream, development value stream; optimize end-to-end flow |
Agile and Scrum interview questions are commonly asked for PM, Scrum Master, and developer roles. Below are the most frequently asked questions.
| Question | Key Points to Cover |
|---|---|
| What is Agile and how is it different from traditional project management? | Agile is iterative, welcomes change, values working software over documentation, self-organizing teams, continuous feedback. Traditional (Waterfall) is sequential, resists change, heavy documentation, command-and-control management. |
| Explain the Scrum framework | 3 roles (PO, SM, Dev Team), 5 events (Sprint, Sprint Planning, Daily Standup, Sprint Review, Retrospective), 3 artifacts (Product Backlog, Sprint Backlog, Increment). Sprint is typically 2 weeks. |
| What is a user story? Write an example. | Format: As a [role], I want [feature], so that [value]. Example: As a customer, I want to filter products by price range, so that I can find products within my budget. Always include acceptance criteria and Definition of Done. |
| What are story points and how are they estimated? | Relative measure of effort/complexity using Fibonacci sequence (1,2,3,5,8,13,21). Estimated via Planning Poker or T-shirt sizing. Points are team-specific and measure complexity, not time. |
| What is the role of a Scrum Master? | Servant-leader who facilitates Scrum events, removes impediments, coaches the team on Agile principles, shields team from external distractions, promotes continuous improvement, and ensures Scrum practices are followed. |
| What is velocity and how is it used? | Total story points completed per sprint. Used to predict future sprint capacity and plan releases. Average of last 3-5 sprints provides the most reliable estimate. Never compare velocity across teams. |
| How do you handle a team member who is not performing? | 1) Have a private 1-on-1 conversation to understand the issue. 2) Identify if it is a skill gap, motivation issue, or personal problem. 3) Offer support: training, mentoring, adjusted workload. 4) Set clear expectations and follow up. 5) Escalate to HR only if no improvement after documented coaching. |
| What is the Sprint Burndown chart? | Visual chart showing remaining story points vs sprint days. Ideal line goes diagonally from top-left to bottom-right. Actual line should track close to ideal. If actual line is above ideal, the team is behind. Use daily to identify and address issues early. |