Just in case anyone is interested, ...
I declare Practice as an Issue Type in JIRA ...
I use it to declare an atomic unit of a Service Plan.
The Service Plan is part of a "Traceability Base"
Service Plans are to Practices as Epics are to Features (or Story if you are so inclined)
or Test Plans to Tests...
With Test Plans, you apply a "Test Plan Execution" Task to account for resources required during development and Report results. Example: In Zephyr you define Tests the perform Test Cycles.
The Test Cycle feeds results back to the original Test. Very cumbersome when you perform the Test in successive Releases. So, what I do is, Create two JIRA Projects, one for QA and one for Development. The Test is declared and designed under the QA Project. The QA Project is maintained as part of a Traceability Base including QA Requirement and Guideline. When a project is initiated, the test is duplicated as part of the Development Project in JIRA. A Test Execution Task is created correlating to a Test Plan (containing the cloned Tests). When the Test Plan is assigned, a Test Cycle is created and executed under the Development Project with the cloned Test (associated to the Plan) as sources. This isolates all Project oriented planning and execution.
Similarly, there is a Product Design JIRA Project where Service Plans are maintained as a part of the Traceability Base.
With a Service Plan, you apply a "Service Plan Execution" Task under the Development Project to account for resources required during Development (or Operations) Projects. An example might be a Code Review,... a Practice is cloned and outlines the procedure while maintaining links to any Knowledge Base documents for Guidance during the review. The "Task" allots resource and personnel and can be tracked for optimization discussions during Retrospectives.
Both Test Plan and Service Plan Execution can be declared as a Task, an accounted in the Backlog, or be autonomous and created as a sub-task during a specific transition. An example of a Test Plan Execution that would be Autonomous is the CI Test Cycle. An autonomous Task could be part of a Transition or even an assignable sub-task taht is auto-created on transition and becomes part of the Sprint or Kanban Board the parent Task is in. Members of the team could pull it from Sprint Backlog or Kanban TODO column, complete it, and auto-trigger a State transition of the Parent Task.
In any case, that is why I want the simple ability to add in a procedure as a custom field.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.