Scrum vs Kanban | | SCRUM | KANBAN | |—|—|—|—| | Cadence | Regular fixed length sprints (ie, 2 weeks) | Continuous flow | | Release methodology | At the end of each sprint if approved by the product owner | Continuous delivery or at the team’s discretion | | Roles | Product owner, scrum master, development team | No existing roles. Some teams enlist the help of an agile coach. | | Key metrics | Velocity | Cycle time | | Change philosophy | Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. | Change can happen at any time |

7 waste of software development

  1. Partially Done Work: Any feature put on hold, wastes time already invested and makes the codebase less maintainable.
  2. Extra Processes: Any step in your process that doesn’t add value. Such as documentation that isn’t read or additional rubber stamping.
  3. Extra Features: Low value features, those that are not used or only used infrequently.
  4. Task Switching: Switching tasks reduces efficiency. The fastest way to complete two things is to do one at a time.
  5. Waiting: Time lost while waiting to start such as approval delays and dependencies.
  6. Motion: Time lost moving artefacts or data from one location to another or hunting for information on wikis.
  7. Defects: The cost of fixing defects and the impact of re-work on the bottom line.

1. Sprint planning


  • Velocity driven
  • Capacity driven


  • Decide Sprint Goal
  • List down Sprint Backlog
  • Capacity Planning (Team Leave plan)

2. Daily Scrum or Stand Up

  • Dit it yesterday?
  • Will do it today?
  • Any impediment?

3. Backlog Grooming/Refinement



Definition of Ready: all the things that a backlog item must meet in order to be “ready” to take into the sprint

  • Business Value
  • Clear understanding of who/what/why
  • Clear acceptance criteria
  • Dependencies identified/defined
  • Constraint identified/defined


  • Removing PBIs that no longer appear relevant
  • Creating new PBIs in response to newly discovered needs
  • Re-assessing the relative priority of PBIs
  • Assigning estimates to PBIs which have yet to receive one
  • Correcting estimates in light of newly discovered information
  • Splitting PBIs which are high priority but too coarse grained to fit in an upcoming iteration
  • Adding acceptance criteria

4. Sprint review

  • Product demo

5. Sprint retrospective

  • What worked Well?
  • What could be improved?
  • What will we commit to doing in the next iteration?
  • Actionable commitment?