SPRINT REVIEW MEETING

Sprint Review Meeting is held after the Sprint is over to demonstrate a working product increment to the PO and everyone else who is interested.

  1. At the end of the sprint, the scrum team holds a sprint review meeting to demonstrate a working software to everyone who’s interested.
  2. The meeting should feature a live demonstration, not a report.
  3. After the demo, Product owner reviews the commitments made at the Sprint planning meeting and declares which item is done.
  4. ScrumMaster helps the PO & stakeholders convert their feedback to new Product Backlog Items for prioritization by PO
  5. Appropriate meeting for the external stakeholders (even end users) to attend
  6. Generally, timeboxed for 2-4 hours for 2-4-week Sprints
  7. Opportunity to inspect & adapt the product as it emerges & iteratively refines everyone’s understanding of the requirements

PSI – Potentially Shippable Product

A potentially shippable product is one that has been designed, developed and tested and is therefore ready for distribution to anyone in the company for review or even to any external stakeholder. Adhering to a list of “done” criteria ensures that the sprint product is truly shippable.

Definition of Done

  • In-order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. 
  • DOD is a clear and concise list of requirements that the user story must satisfy for the team to call it complete.
  • The Definition of Done is set during the Release Planning or Sprint 0 and is not generally modified once the active development sprint cycles are underway.
  • The DoD may vary from one Scrum Team to another, ut must be consistent within one team.
  • DOD is the criteria of satisfaction at the product level to avoid technical debt.

Levels of DOD

  1. Task
  2. User story
  3. Sprint
  4. Release
  5. Road Map
  6. Product Vision

Technical Debt

Technical debt includes those internal things which team choose not to do now, but which will impede future development if left undone. This includes deferred refactoring.

Technical debt doesn’t include deferred functionality except possibly in edge cases where functionality is good enough for the customer but doesn’t satisfy some standards.

Technical debt reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Types of Technical Debt

Naïve: Technical debt that evolves due to irresponsible behavior or immature practices of people involved.

Unavoidable: Technical debt that is unavoidable and unpreventable and accrues through no fault of the team building the product.

Strategic: Taking on technical debt for strategic business reasons. So, technical debt can also be used as a tool to help organizations.

  1. Naïve
  • When best practices are not followed due to being unaware. This happens when the team has junior resources.
  • Lack of testing, bad design, less clarity in the code, hard coding.
  • To get rid of naive technical debt we should follow code refactoring, TTD, pair programming, also provide necessary training to the team.
  1. Unavoidable
  • Happens due to upgrades in development tools to give better solutions and when there is a scope change. These are required and cannot be avoided.
  1. Strategic
  • These happens because of strategic decisions taken by the product owner or stakeholders.
  • For example: code review, refactoring is avoided when there is a need for early release.

How to manage Technical Debt

Technical backlog

  • To develop a technical backlog which contain all the technical task it’s brief description about why it is import and and in which part of the code it will be performed
  • Include cost to tech debt in the budget
  • Practice good engineering practices like TDD and CI
  • Include bugger tasks for refactoring in sprint
  • We can also have a clean-up release in which no feature is delivered only debt is paid.

Acceptance Criteria

User stories are specific requirement outlined by various stakeholders as they pertain to the proposed product or service.

Each user story will have associated acceptance criteria, which are the objective components by which a user story’s functionality is judged.

Acceptance criteria are developed by the product owner according to his/her expert understanding of the customer’s requirement.

Example user story:
As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied

Example acceptance criteria:

  • The rolling balance is displayed
  • The rolling balance is calculated for each transaction
  • The balance is displayed for every transaction for the full period of time transactions are available
  • The balance is not displayed if a filter has been applied

Acceptance criteria is the agreement between the product owner and the scrum team about what functionality will be present in each user story in-order for it to be called done.

Definition of Ready

List of rules and criteria that guide the scrum team for legitimately claiming that the user story is ready to be pulled from PB to the sprint, either during SPM or after.

Criteria –

  1. Story has been reviewed and estimated by the team
  2. Story is complete in format
  3. Acceptance criteria are clear and agreed upon
  4. Product owner has approved the story

A “ready” backlog item needs to be clear, feasible and testable