Work Item Process

Overview

This describes a typical development work process for a scrum team. It is making the following assumptions about the teams.

1. They are following the documentation practices covered in work item documentation and pull request documentation processes.
2. They are using the convention based review process and review work items.
3. They are developing source code iteratively with a scrum team.
4. They are using Azure DevOps.

Procedure

1. Development team creates a User Story with acceptance criteria, and works with the Product Owner to prioritize the User Story once it has been refined and accepted.
2. The team gives the story points as part of longer-term planning activities.
3. Once the user story is refined and accepted by the team it is moved into Active status and the team adds tasks for work.
4. As work is assigned each task is documented. See work item documentation for more details on writing good task documentation and what is required.
5. If the story has no work that requires quality record reviews the tasks are started.
6. If the story has only work that can be reviewed using pull request reviews then the tasks are started.
7. The team members can associate feature branches with the task to automate the process of task association during pull requests at this time.
8. If the story describes work that needs uncommon reviews not covered in the above table, the team creates a "Review" work item for people performing those uncommon review tasks and assigns the review role value on the work items (one per needed uncommon review).
9. Software development, verification and validation, and more occur on the work in small and frequent batches.
10. Each task is moved to active while being worked on.
11. The work of the tasks are completed.
12. If the task contains versioned quality records in azure devops repos the author creates a pull request to integrate their changes when the task is complete.
13. The author associates their pull request to the one or more tasks it resolves. This indicates that the associated task(s) is/are in review and will not be closed until all PRs are completed.
14. As the pull request is written the author documents the pull request. See pull request documentation for more details on writing good pull request documentation and what is required.
15. If more than one quality record is contained within the pull request the documentation of the pull request should state this in the description.
16. If the test was manual the protocol/steps of the test performed should be documented also in the pull request, in the associated work items or in a document attached as part of the pull request.
17. If any tests fail the author can optionally refer to another task or bug which will resolve the test failure in the future.
18. The pull request system will apply all automated checks (including builds) and require that at least one reviewer (not the author) sign off on the pull request.
19. All reviewers are performing their reviews based on the quality records present in the review.
20. If the work being submitted falls under a process step with more required reviewers, the PR author should assign the needed individuals or groups as mandatory reviewers on the pull request.
21. Review comments are entered and documented with resolutions on the pull request. The Azure DevOps policies will require that all comments be resolved before the pull request can be closed. Any new work added after signatures are captured but before the pull request is completed will require the reviewers to sign the review again. They are checking the pull request for impacts of recent changes and this is enforced by Azure DevOps policies.
22. Each reviewer approves the pull request and when all are approved the author completes the pull request causing the changes to merge. More work can be submitted if changes are needed to close the pull request.
23. The author of the pull request closes all associated tasks. Closure of the task indicates that the author has done a holistic analysis that all related pull requests are completed, and all work is passing or documented in other tasks for repair.
24. If the story contains associated uncommon "Review" tasks then those reviews are performed.
25. The review work items are moved to active status while the review is active.
26. The review work items assigned are documented with the review performed in the task and notes to all comments and their resolution.
27. Any comments for needed changes from these reviews are documented in either the related pull request on in the review work item task. A related pull request is preferred if available but when the work is only about reviewing another task the complete documentation of the review should be in the review work item and the associated task should be reset to active (or a bug should be written against the task's story) and linked to the review task.
28. Once all comments have been resolved the review work items are moved to closed. Closing a review work item indicates signature of that work.
29. If all tasks are closed and all associated pull requests are complete the team sets the user story to resolved.
30. The product owner--or someone delegated by the Product Owner--will review all resolved user stories and accept the work.
    1. If the work does not meet the acceptance criteria of the user story the Product owner will move the user story back to active and work with the team to plan additional tasks to meet acceptance criteria.
    2. If the story meets all of the acceptance criteria it will be closed and the story points will be added to the team's velocity.
    3. Optionally the product owner can split the user story up and move uncompleted acceptance criteria into additional stories at their discretion.

Design Controls Approvals with Azure DevOps