Skip to content

Embracing Agile

quick summary of agile practices

Definitions

Product backlog

  • Features we want to implement but not yet prioritized for the release
  • Often decided by the product manager/offering manager

Release backlog

  • Features that we want to implement for a particular release
  • Offering management along with engineering team collaborates to set the scope of a release

Sprint backlog

  • User stories, specific tasks that need to be completed during a specific period of time
  • Decided by the development team depending on the velocity and capacity

Epic

  • Large body of work that can be broken down to a number of smaller stories
  • Spanning across multiple sprints
  • Commitment tracked over a release
  • Evolves based on customer feedback and development progress
  • No Pull Requests are made against an Epic

User Stories

  • Informal, general explanation of a software feature/end goal written from the perspective of the end user or customer
  • Spans across multiple days
  • Commitment tracked over a sprint
  • Does not change over a sprint

Sub tasks

  • A set of specific outcome focussed activities that contribute to a Story's progress
  • Spans across a few hours to a couple of days
  • Commitment tracked over days
  • Does not change over a sprint

Definition of ready

The criteria to move from new-issue to backlog:

  • requirement is well defined in the user story following INVEST criteria
  • Dev lead and dev team must have talked about the story at least once
  • A least one acceptance criterio is explicitly defined
  • Story is sized and prioritized
  • Story must be brokent down enough to fit single sprint

Definition of Done

Describes the requirements that must be met in order for a story to move from In Progress/Review/QA to Done/Closed

Criteria

  • Code is refactored and reviewed
  • Code is integrated with master/main branch
  • Automated tests (UT+FVT) are written and all tests are green
  • Documentation changes are incorporated

Ceremonies

Zenhub practices

Objectives Best Practice
Backlog Grooming * New Issues are created/reviewed based on OM/Customer inputs
* 'Move' the issues under 'New Issues' to 'Backlog' observing DoR
* 'Move' the issues under 'Backlog' to 'Sprint Backlog' upon prioritization
* Appropriate 'tags' are added for easy classification/tracking
Backlog' Actions * Issues are visually ordered according to the priority (Highest priority always at the top)
* Prioritized issues are tagged to the targetted 'Release'
Sprint Backlog' Actions * Only those issues are present that are planned for the current sprint
* Team commits the Sprint Backlog according to the capacity
* Each issue is tagged to the associated 'Milestone' (Sprint 1, Sprint 2 etc.)
* Each issue has potentially identified an owner(s)
In Progress' Actions * 'Move' the issues from 'Sprint Backlog' to 'In Progress' once the team start working on the particular story
* Only those issues are present that are actively worked upon by an individual (and vice versa)
* Has at least one owner
* Regular updates on the progress made in 'Comments' section of the issue
QA/Review' Actions * 'Move' the issues from 'In Progress' to 'QA/Review' to indicate the development completion
* DoD is observed before marking as 'Done'/'Closed'
* Regular updates on the progress made in 'Comments' section of the issue
Reporting Defects * The defect description follows the defect template
* Severity/Priority is rightly identified and updated in the github issue
* Targetted release is identified and updated
* Ensure appropriate engineering priority is observed for addressing the defect
Daily Scrum * Issues "In Progress" are iterated through
* Respective owner of the issue updates the progress, potential blockers, need for help explicitily
* Blockers, Need for Help etc. which require extensive discussion are parked and taken up after the scrum