This article is about ways that we can use to communicate the progress of deliverable items and the meaning of those to the stakeholders and teams.
In the "old" world, there were technical tasks written strictly for developers and technical managers only to understand. Most of the time these were part of a bigger task, but again of technical nature. For example, the parent task could be "Database implementation" and a child task could be "Create employer table and relationships". All these of course made almost impossible for Customers and Business people to understand the progress of implementation in their perspective.
In the Agile world, we got used to User Stories. User Stories were meant to act as the trigger for discussions between the Product Owner (Business) and the Dev Team. Starting from semi filled, business language descriptions in the User Stories, the team is called to fill the gaps in collaboration with the Product Owner. The goal was in the end is both sides to agree of what should be implemented eventually and have a common understanding.
The "split it more" request
How many times, while being near the end of a productive refinement session, having a concrete, estimated user story which everybody understands, suddenly, someone of the Dev Team says "Hey, this cannot fit in our sprint! We have to split it.".
What a painful moment for the Product Owner that is! Of course the person raised the concern is right. The story has to split in two or more smaller user stories. Also, I have experienced the fact that a big irrelevant technical task should be created, but for some reason it cannot be as a sub task of a user story. Most of times this happens because that big technical task solves a cross cutting issue and it's not related directly with only one user story. Of course the description of it does not say anything useful to the business world.
All of the above, arose from a user story which made sense for the business initially but not any more. After the splitting and the addition of irrelevant technical tasks, things are getting blurry for the business. But, not surprisingly more clear for the development team. Blurry for the business because finishing a splitted user story doesn't mean that it can be delivered yet. Even if the initial user story finishes, again not always can be delivered to production.
Remember that the word "potentially", in the "potentially shippable increment" of scrum guide? It lets the business to decide when and if to release it. One reason is that it may have no sense to deliver it alone.
The "want to know the progress" request
On the other hand, when business people start losing clarity about items affecting the progress and not being in position to understand what will be delivered and when, they start to become anxious. Anxiety of this kind in the business and management world will fall back to the teams for sure. I think you have heard the word "Reporting" and when it starts to become a more frequent request...
Of course there are the Epic and Theme concepts but we have to understand how we want to use them. I tried to find a clear rule of thumb in the web for Epics and Themes but all of them left some gaps for my internal decision mechanism.
Grouping having stakeholders in mind
I tried to place my self in the shoes of the Product Owner or even the customer and imagine what they would like to see when they checks what's next to be delivered. Like a tree in the desert, it was obvious that they would expect a concrete new Feature (or more) that made some impact in her product.
Why? Because this is something she can understand and make decisions based on it. Having this in mind, whoever is responsible to keep a delivery plan up to date should use this principle to carefully decide the abstract items visible in it. it doesn't matter if they are called Epics or Themes. What it matters is if everyone of them make sense to the business world. Feature I believe is the correct word. Of course, all User Stories, Tasks, and whatever when reaches the "Done" state, will indicate progress in a Feature should be related with it, and carefully be updated in daily basis from the Product Owner. Better if you have tool that does this automatically. (One I know is Jira Portfolio)
But even if you have the best tool in place, what it matters as a Product Owner, is to collaborate with the stakeholders and identify what makes sense for them to track progress.
What is the gain and how releases could be planned?
First of all the teams will be happy to have small user stories (even if alone don't make any sense) and free to create technical tasks even unrelated to stories. This will lead to better estimation of those, which eventually, and depending of how much they will be done in sprint, they will allow the velocity to be calculated. If you don't split something big, then you take the risk of carrying it in several sprints along with the big number of story points you gave at the beginning. Therefore you will have no indication of how much points you "burned" in every sprint.
On the other hand, the business and management world is monitoring the "Feature" completion percentage. After some sprints they could inspect the rate of progress in those features and make some predictions. But be careful, they cannot predict safely the end of each on of them using the velocity and the total remaining story points. That because in a sprint usually teams pick work from several features. If they want to do that, they have to dedicate sprints in a single feature which I'm afraid this cannot be done often.
Limiting the features that a team will work in the next sprints, you can achieve better predictions. What that means, is that the planned dates for every release should not be far apart. if it is, you may lose business focus and load the sprints with parts of several features, making it more difficult to predict the rate of progress in each one of them.