Refinement - NextensArelB/SwaggerGenerationTool GitHub Wiki

##Objective Refine the Feature into detailed description and Acceptance Criteria

##Who

• Quality engineers (QA)
• Business analysts (BA)
• Developers (DEV)
• User Experience (UX)

##How

• Collect all relevant information, like analysis information from the BA, (UX) designs, verbal information, rules and regulations from Belastingdienst, XBRL designs and link that in the feature description
• Form a focus group with a developer and other relevant stakeholders and startup discussions to get more details on the feature
• Share scope, details and other findings in the refinement meeting
• Determine during refinement meeting per User Story what the Product Risk is- Determine which components are shared and can be re-used
• Describe proposed way of working (validations, XBRL, etc everything which is of relevance), Acceptance Criteria
• When refinement is ready, have the story reviewed

The focus group usually consists of a tester and a developer, however if something entirely new is picked up by the Team, the focus group may expand a bit. It is good practice to have a focus group of max. 4 people.

The focus group's main focus is to ensure that refinement is complete and to add User Stories to the Feature in the backlog. Adding User Stories means splitting the Feature's Acceptance Criteria into smaller deliverables. The right size of deliverable makes that the process is easy to follow.

Tip: if it is a good sprint and the deliverables are the right size, finishing them will motivate the Team more than finishing very small chunks (no satisfaction) or very large chunks (takes too long) of work

1. Each Feature or User Story should have at least one Acceptance Criteria, could consist of
   • User & usability requirements
   • Functional descriptions, like Circumstances when or when not occurring, calculations, mandatory/optional
   • Technical expectations
   • Layout and styling Criteria (should be taken from the figma designs)
2. Acceptance Criteria are written and reviewed before implementation
3. Each acceptance criterion is independently testable
4. Acceptance criteria must have a clear Pass / Fail result
5. They focus on the end result
6. Team members write acceptance criteria and
   • Here is my expectation which can be answered with Yes | No
   • Here is my expectation which can be answered with Yes | No and which is part of and clarifies the expectation above
   • Here is another expectation which can be answered with Yes | No

1. What is the key element to request from the database
2. What is the criteria to request data from the database
3. What are the fields in the response returned from the database
4. What is the mapping of fields: response versus display
5. What is response returning:
   1. (C) Create a point
   2. (R) Get this point to see if it was created
   3. (U) Change the status of this point
   4. (D) Delete this point

See for general approach on Product Risk Analysis link

Based on the outcome of the Product Risk Analysis on asset and sub-asset level, the Product Risk of the Feature is determined, the outcome will be used during Test Analysis to determine the level of test coverage and the level of test automation. The product risk of the feature is added to feature: