1. Passed Acceptance Criteria

2. Unit tests to reflect the code

3. Peer Code Reviewed

4. Tested

5. On Production

6. PM informed

7. Documented, documentation updated (including the Iteration Review page)

1. Standard DoD

2. Root Cause Analysis

3. Incident log

1. New ticket(s) for proposed solution where appropriate

2. Document the findings and communicate in the relevant Refinement session (on the follow up ticket), or in a Team/Tech Sharing

1. Action is carried out in the coming iteration

2. For actions that are not finite (e.g. adopting newly stated best practice) the DoD is to add the decision to adopt this best practice on the Decisions log page.

In our last Retro, the team identified the need to define 'values' that help drive our delivery to our end users. Defining and agreeing on value within a team not only enhances alignment, clarity, and motivation but also improves efficiency, fosters innovation, and ultimately leads to greater success in achieving shared objectives.

Work shop presentation was carried out with the team and in conclusion we understood due to the structure of the organisation and complexity of our products, defining value could present challenging as it is often involves balancing diverse perspectives and priorities, such as those of users, stakeholders, and the development team. However, it's crucial for managing expectations effectively and ensuring both user satisfaction and team productivity.

In carrying out the workshop we recognised the lack of visibility in the value that we delivered to our users therefore adopting metric and having a clear process to defining ‘value’ would be beneficial.

Key points:

TIS21-5903 - Getting issue details... STATUS

Team Checklist to Definition of Value (DoD) when it comes to allocating 70% of effort to routine tasks and 30% to improvement.