Purpose
The purpose of the various tickets in Azure is to facilitate
communication among the team. This includes setting up work activities
in a manner that makes it easier for those performing the work
(typically developers and QA/test) to understand expectations around
functionality, UI, appearance, complexity, priority, and release timing.
Similarly, keeping the project backlog maintained allows for better
management, oversight, reporting, and release planning for those
managing the project.
The ideal ticket should encapsulate everything necessary to perform the
described work. Tickets should include enough information to minimize
(or eliminate, if possible) the need for looking elsewhere (e.g.,
Basecamp or teams) to implement the feature, or should link to another
ticket within Azure (such as a User Story) that includes that
information. Examples include applicable image and specs from the FSD or
BRD, attached data sheets provided by the client, or links to the
results page to be wired-up. To be clear, this does not mean the team
isn't responsible for reviewing project information such as the BRD,
core designs, etc., to ensure familiarity with the project; but neither
should the team have to refer to additional project documentation to
program or test each feature or related functionality.
Once assigned, tickets should also specify the PM, the iteration, the
priority, the estimated effort, and any related work (most notably any
parent-child relationships).
Policy Responsibilities and Expectations
Project Setup IN PROGRESS
Project Maintenance
Work with the team to ensure tickets exist for all work expected to be performed for the Sprint
Review the work with the team to ensure alignment on expectations around
being Done (or complete), timing, and potential dependencies and/or
blocks.
Review tickets to identify blocks, state changes, monitor progress.
Should there be an issue with a team member not following the practices
outlined above, the first step is to make a request via Teams to remedy
the issue. Teams doesn't need to be the only approach, but include it
so there's a helpful reminder, as well as a record to head off a lot of
the team repeating a request already made.
Correction should typically be made within two (2) work days, but
periodically exceptions should and will be made, particularly to account
for extenuating priorities. Furthermore, providing as much detail as
possible about the issue is likely to result in addressing the problem
faster.
If you have questions about the policy and activities above, please feel
free to reach out to the manager of the PMO, your manager, or any
Project Manager.