Is there any place for the Prince 2 Mandate Document 'Quality Expectations' in an agile development?

Question

I have been formalising our IT method. Pretty much a scrumban approach but I still need to document where each artefact and ceremony should be produced or occur.

The basics are

• proposal
• feasibility
• kick off
• requirements gathering
• sprints
• delivery
• project retrospective

One of the Business Analysts has proposed a project mandate document for the proposal phase. This to me seems too onerous for a proposal, especially the section entitled Quality Expectations

vis

Quality Expectations Define the Customer’s Quality Expectations with reference to the relative importance of time, cost and quality of the product so that future decisions may based on what factor is paramount to the project's success.

Am I missing something, but to ask the Product Owner what their quality expectations are given that my whole philosophy is not to compromise on quality unless part of a managed technical debt process whereby payback will happen as a matter of course, seems like a ridiculous proposition.

So, the question is ...

Is it acceptable to ask a Product Owner

What level of quality are you expecting from this solution?

Answer 1

Define Quality Through an Agile "Definition of Done"

What level of quality are you expecting from this solution?

While tempting, asking the question in this way is not useful because it doesn't lead to actionable or testable criteria. In addition, scope (and therefore to some extent quality) is the adjustable theory-of-constraint dimension in most agile implementations.

Instead, you should use the agile "Definition of Done" (DoD) to define quality criteria using quantifiable metrics. For example, the quality expectations of your project might include (but are certainly not limited to) things like:

1. The product increment has been peer-reviewed within the team.
2. The product increment has passed acceptance testing by an end user or UAT resource.
3. Physical products such as cogs and widgets have been validated as being within technical/mechanical tolerances.
4. Code or systems have been validated against regulatory compliance requirements.
5. The product increment has been documented appropriately (e.g. code is commented, or widget specifications and assembly instructions have been added to the product manual).

As long as the quality criteria in your Definition of Done are measurable, you can adjust the thoroughness of the criteria to increase or reduce the project's quality objectives. However, keep in mind that quality impacts other project constraints such as budget and schedule, so you will need to balance quality objectives against other project requirements (such as a fixed shipping date) to find the level of acceptable quality needed for successful project delivery.