This article contains a detailed explanation of the Work Items entity available in PPO. This entity is available by default on the Agile Software Development solution type but can also be configured manually by yourself or with assistance from the support desk.
Work items form the product backlog. These work items are prepared for sprinting and are later planned on a specific sprint based on priority and other considerations. Because the work items are associated with a project, this can be used to further break up the backlog e.g. operations, development, specific applications, epics or user stories.
Next, the fields on the work items entity will be discussed per category. First up is the Work Item Information and the Work Item Classification categories, as can be seen below:
Work Item Information
Project – Each work item is associated with a project. The project that you choose will be dependent on how you want to structure your product backlog. Typically, a work item will be associated with the generic Operations project, an application project (e.g. Application ABC: Minor Changes) or an epic (e.g. Application ABC: Search Functionality).
Title – Capture a descriptive title for the work item. It is important that you get this right as it is used extensively in reporting.
Description – This is a more detailed description of the work item. Over time, as the work item is refined, this description should be updated.
Solution – this is a brief description of what the team thinks the solution for the specific work item is. Once again, this should be refined and updated over time.
Work Item Classification
Type – this categorises the work items into the following types: Enhancement Request, Generic, Incident, Operational Issue, Other and Software Bug.
Priority – this prioritises the work items into either being: Critical, High, Medium or Low.
Code Change Risk – this is a subjective measure of the risk associated with a work item. The risk being that the change will break the application or have other undesirable side effects.
Impact – this categorises the work item according to the following impacts: User Facing, Technical and Other.
Work Item Planning
Sprint – if you want to link a work item to a sprint, simply select the applicable sprint from the drop-down list.
Sprint Status – this is a calculated field that shows the status of the sprint that the work item is linked to. If the status is blank like in the example above, the item is not linked to a sprint, as previously mentioned.
Responsibility – this shows the person responsible for the work item in the sprint. This is the person that will be doing the work.
Estimated Hours – this indicates the estimated hours for completing the work item. This is usually captured when the work item is added but may be changed as the work item is refined.
Estimate to Complete – this number is updated daily by the person working on the work item, and should become less as the development of the work item is progressing.
Product Backlog Status – This is a calculated field and shows the status of the work item, with regards to the product back-log. The statuses are the following: Ready, Preparing, New and Parked (see the table further below).
Work Item Management
Sprint Backlog Status – this is a calculated field that indicates the sprint back-log status of the work item. The statuses are the following: Backlog, To Do, Doing and Done. These statuses are also used on the Kanban board on the Scrum - Sprint Backlog dashboard, to also show the status of the work items that are currently part of a sprint and currently in development (see the table further below).
Status – when the work item is captured the applicable status needs to be selected. The table below shows the relationship between the status of the work item, Product Backlog Status and the Sprint Backlog Status.
If the status of the work item is changed to “Ready for Sprint” then the Sprint needs to be updated to reflect the sprint that the work item will form part of.
Assigned To – this is usually the same as the Responsible person except when it is in a review or QA status, in which case it will be the person responsible for that activity.
Action / Response – every time that the work item is updated, the reason for the update is captured here and gives an indication of what is required for the item to progress. Please note that this field is auto-cleared each time the work item is updated.
Deployment Date – this field only needs to be populated once the status of the work item is changed to “Deployed”.
Deployment Steps – the development team usually follows their normal deployment process. This field is only used to record special steps they required during the deployment of the work item and is not always populated.
Time Entry Hours – this is a calculated field which shows the actual hours captured for the work item, on the time entries maintenance page.
Variance – this is a calculated field that shows the difference between the Estimated Hours for the work item and the Time Entry Hours + Estimated Hours to complete fields on the work item.