Breaking Down a Code Review of a Prototype

Question

I'm the Product Owner on a project, which is essentially the integration of a new technology into an existing product. A prototype has been written by an external developer and we are now tasked with integrating these changes into our code-base.

From what I understand from our, this is mainly about doing a large code-review and making sure that the code is in good enough shape for production.They estimate this work to take in the region of three-months and has many dependencies on other projects. The work hasn't been broken down to a level or form that can be expressed as user stories.

How can I best break this down into user stories with a value that I can express to the business and ensure that the product ultimately delivers value to the end-customer?

Answer 1

Gain the benefits of new technology and not break any existing features

As the Product Owner, I will focus on the what and why and let the dev team worry about the how, namely, the code review and so on. I will write 4 epics for each of the following and then break them down into stories and write acceptance tests and expected results:

1. Why are you integrating the new technology?: Presumably you have a large business benefit to justify all the cost. This epic and the set of stories should make sure that you extract the maximum ROI (Return on investment).

2. This appears to be a major rewrite - like rewiring a car: You want to make sure that all the existing features continue to function as they are. You need to write a set of stories to make sure all these get regression tested and validated.

3. You mentioned 'many dependencies on other projects': You want to make sure that you don't break the other projects.

4. Non-functional requirements: With such a major rewrite, you also need to safeguard non-functional requirements. This includes security, performance, reliability, availability, portability, scalability, usability, maintainability and so on.

Answer 2

Ashok gives a great answer. To add to his #2, these code reviews will reveal the quality of the code. While manual regressions are a good idea, they are costly and time consuming in the long run. Consider thinking about requiring automated testing (integration, unit) as done criteria. As a PO, you may request, in consultation with an Architect or technical lead, to see a minimum level of automated code coverage or documentation that prove business critical flows supported by the new code have test cases and/or automated tests in place. You may also request that defects be documented during code reviews.

Automated tests that frequently execute and test integrations and basic logic are a great way to showcase/improve product quality and ensure the longevity of the solution.