how best to take a vertical slice of something already trivial?

Question

Lets say I have a project which is something relatively simple like a copy checker for legal text files stored in git, that multiple people contribute to via pull requests that must be reviewed before merging. I want to alert the reviewer to weasel words, slang etc. I have split this project into 4 small tickets (probably a single pull request for each one):

1. extract the contents of the pull request
2. parse the diff and extract additions only (I only care about additions to the documents, not deletions)
3. do a text search of the weasel words, slang etc
4. if one of the keywords are found (eg slang), it will write a comment in the pull request saying "slang should be replaced with more formal language".

I've been told that I should take a thin slice of functionality that can deliver value sooner in 1 or 2 tickets - otherwise I need to complete all of these tickets before any value is realised.

Given what the small project aims to deliver, how can I structure the tickets so that they each deliver incremental value and stand on their own? I'm at a loss how to split them because which ever way I cut it, I can't cut smaller than 'extract the changes from the document', 'do a grep' etc.

Answer 1

Start with the simplest thing that could possibly work.

Given that searching for text in a file is a capability you have already let’s move on to searching for a list of words in a file.

That delivers value today. Sure it doesn’t focus exclusively on additions but that’s an optimization for another day.

Answer 2

Why not focus on step 3 and 4 first and make a checker for legal text files? That is something your reviewers can use immediately.

Note this requirement alone can be fulfilled either in a very lean manner, or with a lot of "bells-and-whistles":

• Is the blacklist of words hardcoded into the program? Or is it exchangeable by the user? Or does it come with a default list of words which might be extended by the user?

• Are the comments just a list of words printed to the console, or do they come with some hint about the line number where they were found, with some describing text? Will there be a logic which eliminates duplicate comments, or merges comments for the same word found multiple times? Shall the logging stop after the loglist becomes too long, for example, after 50 comments?

Start without any of those bells-and-whistles, with the smallest possible program which might be useful to a reviewer. Save any extras to a later version.

The Git integration is clearly a separate requirement - if you can check arbitrary text files, you can reuse this to check the parts of the texts which were added during a merge commit.