In the name of automation and visibility, it seems to me that Tasks or Backlog Items (and maybe bugs and features) should have a status that maps to a number of CI/CD statuses, ideally automatically. Perhaps the task is set to "Done" as per Scrum but then the PBI should somehow track perhaps "Merged", "Built", "SystemTest", "Production" or equivalent which gives the PO easy oversight of where things are and when they are ready to test etc.
The problem I am having is that there is no obvious correlation between the fact that a build might only contain a subset of tasks and will not have any concept of the PBI or when it is completed by all tasks being finished so it would only ever be able to set task statuses. If I tried to build something based purely on the status of tasks, then that sounds like it would break the concept of a Task being "Done" as soon as it is merged and would potentially be complicated e.g. when all tasks are set to Built or above, set the PBI to built.
Am I misunderstanding? Should I be trying to track my backlog into Production or is it better to assume that things are Done as soon as the CI starts and any failures/deployments/releases should be tracked separately? I am using Azure Devops if that is relevant.
I think where you are going wrong is that you are saying Tasks or Backlog Items should map to CI/CD statuses. This is not always the case. Depending on the actual task (or feature) you may not always have a status in your CI/CD pipeline.
The "Done" state of a task is something I've had conversations about in many organizations as they try to mature their processes. In many cases it needs to be broke out more (waiting for QA / done but waiting for internal verification / etc).
* TODO
* In progress
* On hold
* Awaiting feedback
* Pending Release
* Done