Tips and trick using the board - NextensArelB/SwaggerGenerationTool GitHub Wiki

#Using the board

This section will explain the different levels of work and how to conceptually understand the context of the item. Microsoft's documentation

DevOps follows a hierarchical item structure.

Each child item (Feature, User Story, Task) must be within the context of the parent item.

The Microsoft documentation states clearly what an epic should be:

The epics and features that you create should reflect your business focus. As user stories or product backlog items roll up into features, and features roll up into epics—you'll want to name your features and epics with that in mind.

• Criteria

  • If an item of work would extend over multiple sprints and involve multiple participates.

• Members

  • Epics are created and owned by the Delivery Manager.

A feature is a further breakdown of how the parent epic will be achieved. The context of features should relate closely to a working roadmap.

• Criteria

  • A feature should be achievable within a single sprint. If not the feature should either be broken down into more features or converted into an epic.

• Members

  • Features are created and owned by the Delivery Manager and Development Lead.

User Stories must be in the context of the feature. The details of a User Story should reflect the desired interaction and expectation of a piece of functionality.

• Members

  • User Stories are created and owned by the QA and/or Development lead with input from all members involved and based on the refinement doc.

User Stories will contain multiple tasks. These tasks will explain in details all the systems which are impacted and detail the changes required.

• Criteria

  • A task should be achievable within one working day. This is not always possible but used as a guideline.

• Members

  • Tasks are created by all members involved.