DoR and DoD in TxS...

DOR in TxS
==========

1. User stories written in As a < type of user >, I want < some goal > so that < some reason >.
2. Acceptance Criteria written, and in BDD format - Given, When, Then.
3. User stories approved by PO.
4. User stories prioritised by PO.

DoD in TxS
==========

1. Development is complete.
2. Pega unit is complete
3. Code reviewed.
4. Relevant comments and attachments made.
5. Dev QA complete
6. ZSIT / IT complete
7. System Testing complete
8. UAT complete (based on TC provided by business).
9. No open Sev 1/ Sev 2 bugs.
10. US approved by PO.

Agile lifecycle in TxS
==================

1. Discovery workshops to clarify scope.
2. High level Pega estimates by Pega team (Pega Design Council) - Epic level (in terms of both T Shirt sizes and man days).
3. User story mapping and Release planning sessions.
4. Sprint Planning.
5. Daily standups, Refinement sessions (Every wednesday), Sprint Review (Fri 3pm to 4pm), Retro (4pm to 5pm).
6. Scrum of Scrums [TxR Upstream and downstream] daily 9:45am, standups daily 10:15am to 10:30am.
7. Release Train Scrum of Scrums every Tuesday 2:30pm to 3:00pm.

For Agile Release Train [ART]
======================

o Establish and embed SAFe framework to manage scope, delivery, quality and resources.
o Employ Scrum at team level to reinvigorate team, bring about trust & empathy, transparency and clarity of purpose.
o Coordinate activities in preparation for PI Planning – Backlog with epics, features, stories.
o Coordinate in-PI-planning, dependency management and presentation.
o Plan and coordinate Sprint 0 activities such as initiation, elaboration, architecture, etc.
o Coordinate customer journey mapping and User Story Mapping
o Help team in defining MVP, Release plan, sprints, etc.
o Facilitate sprint planning, daily stand ups, Sprint Review and retrospective.
o Managing program board, dependency management with stakeholders.
o Stakeholder communication, management reporting, etc.
o Manage team conflicts, challenges; escalate where necessary.

Personalised Rates Workflow

Root Cause Analysis ( RCA )

RCA comprises the techniques and tools to uncover the underlying causes of problems. 

• Most common is 5-Whys?
• When you have a vast amount of data:
• Do a 80-20 Pareto chart to identify the 20% causing the defects.
• Do a 5-Why on the 20% based on the defect categories.
• Fish Bone / Ishikawa Diagrams

* Images may be subjected to copyrights. I don't hold the rights.

Defect Triage

Defect Triage is process of determining the priority of a defect based on their severity. Severity is raised by the software tester. A decision on priority is made collectively in conjunction with the Product Owner. 

1. Is this a valid bug?

2. Is this bug reproduceable?

3. Is this bug worth to fix in the present sprint / can it be deferred?

4. If it has to be fixed, then When?