Agile ceremonies Flashcards
Product Backlog
📦 What is a Product Backlog?
A Product Backlog is a dynamic list of features, enhancements, bug fixes, and technical work that needs to be done for the product. It’s essentially the “to-do” list for the product team.
- It’s maintained by the Product Owner (PO).
- It evolves throughout the project as requirements change, new ideas come up, or feedback is received.
🔑 Key Features of a Product Backlog:
1. Items in the backlog (often called Product Backlog Items or PBIs) include:
- User Stories
- Defects (bugs)
- Technical tasks
- Research spikes
- Improvement requests (features or refactoring)
-
Prioritization:
- The PO prioritizes items based on business value (how important they are for the product and the customer).
- High-priority items appear at the top.
-
Continuous Evolution:
- The backlog is continuously updated to reflect new findings, changing requirements, and any shifting priorities.
- New tasks can be added, and tasks can be re-prioritized as needed.
🎯 How Does It Work?
-
Product Owner:
- Owns the backlog and makes decisions about what goes into it.
- Prioritizes items to ensure the team is always working on the most important things.
-
Development Team:
- Estimates the effort required for backlog items (story points or time).
- Pulls tasks from the backlog during Sprint Planning.
-
Scrum Master:
- Ensures the backlog is well-managed and groomed.
📝 Example of a Product Backlog:
🔄 Product Backlog Refinement (Grooming):
- The Product Owner, Dev Team, and QA review the backlog regularly to:
- Add new items
- Clarify user stories
- Split large tasks into smaller tasks
- Re-prioritize based on feedback or business needs
🧠 In Summary:
- The Product Backlog is like a living document that ensures the team is always focused on what’s most important for the product.
- It’s constantly evolving, and every sprint the team pulls work from the top of the backlog to tackle.
Would you like to see how the backlog influences sprint planning and test case creation?
ID | Backlog Item | Priority | Estimated Effort | Status |
|——–|——————|————–|———————-|————|
| PB001 | User can log in using email and password | High | 5 story points | To Do |
| PB002 | Implement password reset functionality | High | 8 story points | To Do |
| PB003 | Fix bug where user profile is not saving correctly | Medium | 3 story points | In Progress |
| PB004 | Add feature to change user email address | Low | 13 story points | To Do |
| PB005 | Research best approach for multi-factor authentication | Low | 5 story points | Backlog (Research) |
Let’s walk through a realistic Agile sprint flow, step by step,
Perfect! Let’s walk through a realistic Agile sprint flow, step by step, so you can see how a user story moves from idea → test case → done.
🚀 Sample Sprint Flow (QA Perspective)
1️⃣ Backlog Grooming / Refinement (Before the sprint starts)
- Product Owner (PO) shares a new feature as a User Story.
- PO also defines initial Acceptance Criteria (AC).
- QA, Dev, and UX join to review it.
- QA asks questions like:
> “What happens if the password is expired?”
> “Should the user get a confirmation email?”
This helps refine or add more AC
✅ Goal: Get a clear and testable user story with AC before sprint planning.
2️⃣ Sprint Planning
- Team agrees on what stories to include in the sprint.
- QA gives test effort estimation.
- Dev & QA discuss technical approach and possible test strategy.
- QA starts thinking of test scenarios and edge cases.
✅ Goal: Everyone is aligned on the scope, requirements, and plan.
3️⃣ During the Sprint
- 🧑💻 Dev starts coding based on the user story and AC.
✅ QA writes test cases based on the AC.
- 🧪 QA may prepare:
- Manual test cases
- Automation scripts (if test automation is used)
- API test plans
- 📋 Dev finishes, and QA gets the build for testing (usually in a QA environment).
✅ Goal: QA is ready to test as soon as dev work is done.
4️⃣ Testing the Story
- QA runs test cases.
- If a bug is found:
- QA logs it (e.g., in Jira)
- Dev fixes → QA retests
- Once all AC are met and test cases pass:
- QA marks story as “Passed” or “Ready for Release”
✅ Goal: Confirm the feature works as expected and meets the AC.
5️⃣ Sprint Review / Demo
- Team demos completed stories to the PO/stakeholders.
- QA may support by explaining testing or helping run the demo.
6️⃣ Sprint Retrospective
- Team reflects on what went well, what could be improved.
- QA might say:
> “Let’s include QA earlier in refinement”
> “We need more time for regression next sprint”
🧠 Summary Chart:
|——|—————-|———|
| Backlog Grooming | PO, Dev, QA | Review stories, clarify AC |
| Sprint Planning | Whole team | Estimate testing effort |
| Development | Dev, QA | Write test cases in parallel |
| Testing | QA | Execute & automate tests |
| Review | Team + PO | Support demo |
| Retro | Team | Suggest process improvements |
Step | Who’s Involved | QA Role |
What is Sprint ceremony>
Sprint ceremony meetings are key events within an agile project’s sprint cycle, designed to facilitate communication, collaboration, and progress monitoring. They include sprint planning, daily stand-ups, sprint review, and sprint retrospective.
Sprint Planning?
Sprint Planning: This meeting defines the scope of work for the upcoming sprint, including identifying product backlog items, estimating effort, and creating a sprint backlog.
Daily Stand-up?
Daily Stand-up: A short, daily meeting where team members discuss progress, identify impediments, and plan for the next day’s work.
Sprint Review?
Sprint Review: At the end of the sprint, the team presents the work to stakeholders and gathers feedback on the increment delivered.
Sprint Retrospective?
Sprint Retrospective: A reflective meeting where the team discusses what went well, what could be improved, and identifies actions for future sprints.
