Posts

Showing posts from April, 2017

Agile Bug Triage Meeting

Agile Bug Triage Meeting Definition: Bug Triage meeting is discussion and analyses for all open bug, and agenda of discussion is set the priority to team for which bug should take up first, classify the bug in different category, find the where team struggle to get help to debug RCA, if RCA is available then assign bug to right team, find the recreation step from reporter and severity of bug.                             Procedure: Generally, below procedure is followed for Bug Triage Meeting QA lead sends out a bug report with the new Bugs introduced since the last meeting. Product owner calls out a meeting. During the meeting, each Bug is analyzed to see whether correct priority and severity are assigned to it. Priority and severity are corrected if need be.   Bugs are discussed by the team. This involves discussing RCA, Dependencies to resolved bug, risks   Assignment, rejection, reassignment of Bugs.   After meeting completion, minutes of meetings are used for the

Sprint review Story demo should be concider testing checklist

Business value should be demoed Positive working flow for story All test combination should be covered and tested All the Open issue should be demoed All the know behavior should be covered in demo Open issue and behavior should be approved by PM/PO

Definition of Ready [DOR]

To help with this, our teams work with the PO to agree on what defines a “ready” state of a backlog item. This will vary by project, but below are some elements to seed the discussion: Story defined and written with details flow Acceptance criteria defined Dependencies identified and marked Size estimated by delivery team User experience included (where required) Performance criteria identified Test Risk identified and written  Team has a good idea about how to demo the user story

Definition of Done

Code produced (all ‘to do’ items in code completed) Code commented, checked in and run against current version in source control Peer reviewed (or produced with pair programming) and meeting development standards Builds without errors Unit tests written and passing Deployed to system test environment and passed system tests Passed UAT (User Acceptance Testing) and signed off as meeting requirements Any build/deployment/configuration changes implemented/documented/communicated Relevant documentation/diagrams produced and/or updated Remaining hours for task set to zero and task closed