Automatization of test cases in SCRUM

Test case automation may bring many benefits for the application/system QA process, but it's not always obvious how to introduce an implementation of the test cases into SCRUM flow. 

The SCRUM methodology defines the number of PBIs (product increments) for prioritization and planning, as a part of the SCRUM process. Those could be user stories or enablers, sometimes bugs. Each of the PBIs needs to be estimated and confirmed by a scrum team before it's added into a sprint scope (sprint backlog). The question would be: How to plan the effort for the implementation of automation tests, as those are not the PBIs per se?

Test Case is not a PBI

In the strategy proven in one of my projects, a test case is an output (product) of the delivery, just like an ordinary artifact. Typically, it's a part of a testing suite. It needs to be created, maintained, and placed into a repository (see: Azure DevOps). Once prepared, we can start working on the automation of the test case. Both activities are planning tasks, to be placed into the backlog, somehow.

Please consider the initial domain assumptions:

• User Story - It's a PBI that describes a requirement defined from user perspective. To cover user story's we may need to have one or more test cases.
• Test Cases - It's a product output, not a PBI per se, so it's not a part of the sprint backlog.
• Automation Test - It's an implementation of a test case. We're automating the test cases, not the user stories.

Given the above, we need to keep all test cases aside from the product backlog. We may organize them into test suites within the test repository. To bring them into the backlog, we need to create a separate PBI (enabler suits best) to embrace the automation implementation effort. The enabler could be estimated and prioritized along with other PBIs during a planning session by Product Owner.

Automation of test cases in Sprint

Automation test might be implemented by one of 3 flows:

1. User Story post-mortem - Once a user story is implemented, we have a tangible product, we can validate using the automated test case. That's why we may want to postpone automatization for the next sprints. The test case will be added to the regression pack and prioritized later (attached to a PBI/enabler).
2. User Story & test cases at once - During the backlog refinement session, PO may decide to invest some effort to automate test cases for a particular User Story. During the planning session, it would be good to extract this requirement from the User Story as a separate PBI (enabler) and place both into the new sprint. This little trick will push back the risk of non-delivery of the User Story, due to missing automatization.
3. Regression pack - We may have a list of test cases, defined across multiple stories or features. All of those would be a part of our regression pack. To automatize those we need to group them and assign each of those groups into separate enablers. Those enablers might be easily estimated and prioritized next to the other PBIs.