diff --git a/docs/usage/noise-reduction.md b/docs/usage/noise-reduction.md
index 7ba71e6793954e972e9ecb4070047cccee540e47..a9bf137f35e3288c102a64b11e514b1211de18ae 100644
--- a/docs/usage/noise-reduction.md
+++ b/docs/usage/noise-reduction.md
@@ -127,11 +127,13 @@ Have you come up with a rule that you think others would benefit from? How about
 
 ## Lock file considerations
 
-As mentioned earlier, using lock files greatly increases the chance that merging one PR will result in a second PR becoming conflicted with `master`. Therefore:
+Using lock files greatly increases the chance that merging one PR will result in a second PR becoming conflicted with `master`. The table below highlights different noise reduction strategies and their effect on pull request and potential lock file conflicts:
 
-- The more groups you use, the separate PRs you have, and hence the less overall chance at lock file conflicts
-- The less your schedule, the more chance that you pile up concurrent PRs, which increases the chance of lock file conflicts
-- The more automerging you do, the less chance you have concurrent PRs, which decreases the chance of lock file conflicts
+| Action                               | Effect on pull requests  | Chance of lock file conflicts |
+| ------------------------------------ | ------------------------ | ----------------------------- |
+| Group dependencies together          | Decreases separate PRs   | Decreases                     |
+| Automerge dependencies               | Decreases concurrent PRs | Decreases                     |
+| Decrease scheduled time for Renovate | Increases concurrent PRs | Increases                     |
 
 ## The Future of Noise Reduction