No fish, prawn also good? Improvised Scaled Scrum Framework

A scaled scrum implementation for multiple teams with separate backlogs working on the same product.

Introduction of the following new events in this scaled scrum implementation

  • Overall Sprint Planning
    • Each team involved in this scaled scrum implementation will share with other teams on what will be considered for the upcoming sprint. Any dependency across teams will be raised and taken into consideration during the individual team sprint planning that happens immediately after this overall sprint planning. The purpose of this new event is for synchronization and identification of any cross-team dependency
    • Attendees: POs, SMs and at least 1 representative from each team
  • Overall Sprint Review
    • Each team will share the outcome of the sprint with a demo and gather feedback from the stakeholders. With this new event, there will no longer be any individual team sprint review.
    • Attendees: The whole world
  • Overall Sprint Retrospective
    • To be held after each team has conducted their own team retrospective. This new event is for the purpose of sharing any feedback regarding cross-teams coordination and the scaled scrum implementation
    • Attendees: POs, SMs and at least 1 representative from each team
  • Overall Daily Scrum
    • To be held daily after each team daily scrum. For the purpose of synchronization of daily work across teams and raising of cross-team dependency
    • Attendees: At least 1 representative from each team

 

 

Defect Retrospective (Experiment)

A separate event from the regular retrospective targeting on defects. The idea of this retrospective is to review the defects identified and fixed by the development team, allowing the team to identify ways to prevent similar defects from re-occurring and improving the quality of the product being developed.

  • Frequency: Once per week (Friday)
  • Duration: 1 hour

To ensure that this event run smoothly, the backlog containing the defects need to have the following information filled up by the development team

  1. Root Cause Category
  2. Detailed Root Cause Analysis
  3. Solution

Category for Root Cause has been set up as followed:

  • Back End – This defect is due to back end
  • Configuration – The defect was caused by incorrect static data setup
  • Environment – The defect has occurred due to a code base lining issue, server level configuration, etc
  • Existing bug – This is an existing defect in the system which is probably also present on the live environment
  • Impact Analysis – Thorough impact analysis has not been done and implicit requirements have been missed out
  • Injected defect – This defect has been injected due to a different defect fix.
  • Requirement – The requirement has not been clearly understood, the team’s assumption does not match with the business user’s expectations.
  • Testing Error – The test case was incorrect effectively resulting in an invalid defect getting logged
  • Wrong Implementation – The defect was caused due to an incorrect coding implementation
  • Others – Please reach out to Scrum Master to create the necessary category

Continue reading