Add a pre-PR Review Step

Many teams see an uptick in quality if they add an extra step to the development process. During this step the developer gives a demo of a feature or bug fix before submitting a pull request.

The development process usually looks like this:

1. The product owner writes the user story which includes a description, optional mockups and/or UI design assets.
2. The product owner discusses each user story with a tech lead, it is refined, and put on the backlog for development.
3. Each user story is picked up by a developer.
4. The developer submits a PR including a reference to the user story plus his personal notes on the implementations, caveats, et cetera.
5. His fellow team members review the PR and–usually after a round of revisions–one of them (and not the author himself) approves and merges the PR.

After step 5 the story ends in some companies. If that is the case in your situation then I suggest to slightly alter the process:

• Unaltered from 1.
• Unaltered from 2.
• Unaltered from 3.
• Just before submitting a PR containing the finished feature (or bug fix) the developer contacts the product owner:
  • The developer prepares a feature app on a staging server or in lieu of a live feature app, a demo is prepared on his development hardware.
  • They sit together side-by-side or they conduct a screen sharing session.
  • The developer demonstrates the feature to the product owner.
  • They discuss whether to apply fixes or refinements, and commence with the PR – or to cancel the PR if things are too broken to carry on. If they decide to cancel the PR, the developer will close the issue, and the product owner will have to redo his work on the user story.
• Unaltered from 4.
• Unaltered from 5.
• The author of the PR contacts the product owner to tell him the feature has been merged.
• The product owner:
  • Writes a release note.
  • Ensures all content is translated to other languages.
  • Discusses the release schedule with the deploy team.

Benefits of this approach:

• It reduces the likelihood of misunderstandings between a product owner and developer.
• It improves the quality of the work presented by a developer to his colleagues who will perform a code review on his PR.
• It gives the product owner a clear overview of the exact end result, enabling him to write accurate and detailed release notes including screenshots since he has access to the user interface during the demo.
• It hardly adds time to the total development process because it reduces time wasted on rework at a later stage.