#### 7.2.2.1 Work Items List As part of the Development Work Plan, the Work Items List (WIL) is a list of the work to be done during a project. Work items are intended to be prioritised, effort-estimated and tracked in terms of progress. The following are typically included in the Work Items List (WIL): - Defects (or bugs) - Enabler Stories - User stories The Work Items List (WIL) is continuously maintained by the Product Owner (PrOw) throughout the entire project. During each iteration, the Product Owner (PrOw), the Business Implementation Group (BIG) and the Business Manager (BM) revisit the Work Items List (WIL) to ensure that it reflects the relevant work items to be implemented. The outcome of this exercise is then discussed with the rest of the Agile Project Core Team (A-PCT) so that some relative estimates can be defined and dependencies identified, helping the Product Owner prioritising the Work Items List (WIL). A Work Item is not a contract between the development team and the Product Owner (PrOw) but rather a pointer to something that needs to be implemented. Therefore, each Work Item commonly refers to additional relevant information (business rules, diagrams, user interface specifications, etc.) to carry out the work. | Key Participants | Description | |:------------------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Team Coordinator (TeCo) | Consulted by the team and the Product Owner (PrOw) to guarantee the consistency and form of the Work Items List (WIL) that will allow the Agile Project Core Team (A-PCT) to work on it.<br> Consulted by the Project Manager (PM) to verify alignment with the Project Charter. | | Agile Team Member (ATeM) | Supports the Product Owner (PrOw) by providing inputs regarding estimates, dependencies, etc., that may impact the Work Items List organisation and prioritisation. | | Architecture Owner (ArOw) | Supports the Product Owner (PrOw) by providing inputs regarding enabler work items that need to be delivered to support business work items. | | Business Manager | As a representative of the Project Owner on the daily activities of the project, supports the Product Owner (PrOw) by giving inputs <br> regarding the business priorities, objectives and user needs. | | Product Owner (PrOw) | Responsible for the definition and maintenance of the Work Items List (WIL), fully aligned with the Business Manager (BM) and empowered <br>to make all the necessary decisions on the daily life of the Agile Project Core Team (A-PCT). | | [[Project Manager (PM)]] | As accountable, he needs to be aware on how the Work Items List (WIL) (as part of the Development Work Plan) is aligned with the scope defined in the Project Charter. || **Guidelines** - **Project Charter as a generator of Work items** – As one of the first things to be done when creating the Development Work Plan, the Features’ list defined in the Project Charter will be the key generator of the work items that will populate the Work Items List (WIL). - **Architecture Overview and Operational Model** – These two artefacts are an important source of enabler stories that will support the implementation of the “business part” of the solution. - **Start working with a prioritised Work Items List (WIL)** – The Work Items List (WIL) doesn’t have to be complete for the Agile Project Core Team (A-PCT) start working, but it must be prioritised. Without a prioritised Work Items List (WIL), the team runs the risk of investing resources in not so important items. - **Product Owner (PrOw) maintains the Work Items List (WIL)** – The Product Owner’s (PrOw) responsibility is to maintain the Work Items List (WIL) updated and prioritised, ensuring the Team is always working on the most relevant Work Items. - **Refer to Release Planning, Iteration Review and Iteration Retrospective** – As part of the continuous learning process and because the context of the solution will change, it’s very important to refer to ceremonies like Release Planning, Iteration Review and Iteration Retrospective as they continuously provide inputs and generate work items to be included in the Work Items List (WIL). - **Project Logs as a source of work items** – Managing the project logs (Change requests, Risks, Issues and Decisions) can generate several work items that must be included in the Work Items List (WIL). A Change request may generate several new stories to be developed to deliver the change request or the plan to mitigate an architectural risk my include implementing some enabler stories. ![[7.2.2.1 - Work Items List — Inputs and main roles - 1.png]] ![[7.2.2.1 - Work Items List — Inputs and main roles - 2.png]]