What is velocity in agile scrum?

 In Agile Scrum, velocity is a measure of how much work a team can complete during a single Sprint. It helps teams estimate how quickly they can deliver future work based on past performance.

---

✅ What Is Velocity?

Velocity is usually expressed in terms of:

• Story points (a common estimation unit for user stories), or

• Number of completed user stories or tasks

For example, if a team completes 30 story points in Sprint 1, 28 in Sprint 2, and 32 in Sprint 3, their average velocity is:

(30 + 28 + 32) / 3 = 30 story points per Sprint

---

📏 How to Find Velocity

1. Estimate the effort of each user story (usually during Sprint Planning), typically using story points.

2. Track the number of story points completed (fully done and accepted) by the end of the Sprint.

3. Calculate velocity as the sum of completed story points.

---

💡 Example:

Sprint	Story Points Completed
1	25
2	30
3	28

Average Velocity = (25 + 30 + 28) / 3 = 27.67

---

🔍 Why Velocity Matters:

• Helps with predicting future Sprints (e.g., if your Product Backlog has 100 points and your velocity is 25, it will take ~4 Sprints).

• Useful for capacity planning and forecasting releases.

⚠️ Note: Velocity is a team-specific metric. It should not be used to compare different teams or judge productivity. It’s for internal planning only.

What is empirical process in Agile scrum?

 In Agile Scrum, an empirical process refers to a way of working that is based on experience, observation, and experimentation, rather than upfront planning and predictive processes. It relies on the idea that knowledge comes from experience and that decisions should be made based on what is known.

Scrum applies empirical process control through three main pillars:

1. Transparency – Everyone involved must have a shared understanding of the process and work being done.

2. Inspection – Scrum events like Daily Scrum, Sprint Review, and Retrospective allow frequent checks on progress and processes.

3. Adaptation – When things deviate from acceptable limits, the process or work must be adjusted promptly.

This contrasts with a defined process, where everything is mapped out in advance. Scrum embraces change and unpredictability, making empirical process control ideal for complex, rapidly changing projects.

Example of Empirical process:

🟢 Transparency

• The Product Backlog is visible to the whole team.

• Everyone (developers, product owner, stakeholders) can see what features are planned, in progress, and completed.

• During Sprint Planning, the team discusses what they will deliver and why.

🔍 Inspection

• Every day, the team meets in the Daily Scrum to inspect progress toward the Sprint Goal.

• At the end of the Sprint, they hold a Sprint Review to inspect the product increment — maybe they demo a working step counter.

• The team also holds a Retrospective to inspect how the team worked together.

🔄 Adaptation

• After feedback in the Sprint Review, they learn users prefer integration with Apple Health over a custom dashboard. The team adapts the backlog and priorities for the next Sprint.

• During the Retrospective, they realize too many bugs came from rushed testing. They adapt by agreeing to write automated tests in the next Sprint.

---

🔁 The Value of Empirical Process

Rather than trying to predict every detail up front (which might fail in a fast-moving market), the team learns by doing, adjusts based on real user feedback, and continuously improves the product and process.

What is DoD?

DoD stands for Definition of Done.

It's a clear, shared agreement within the team about what it means for a work item (like a user story, task, or feature) to be considered fully complete.

Think of it like a checklist or a quality standard — it ensures that when someone says, "This is done," everyone knows exactly what that means. It usually includes things like:

• Code is written and reviewed

• Code is tested (unit tests, integration tests)

• Documentation is updated

• Feature is integrated and working

• No critical bugs

• Product Owner has accepted it

Without a solid DoD, teams can easily have mismatched expectations about what's "done," leading to unfinished or low-quality work.

Example: Detailed DoD for a Web App Team

• User story is implemented according to acceptance criteria.

• 90%+ unit test coverage achieved.

• Peer code review completed.

• Deployed to a staging environment.

• UI/UX verified against designs.

• No high or critical severity bugs.

• Performance tested (page load time under 2 seconds).

• Security checks (input validation, authentication, etc.) completed.

• User documentation (if any) updated.

• Ready for release or demo.