Epics Stories Tasks

I want to quickly discuss development process from the User Story point of view. I will use Jira as example here, because this is the tool I worked with the most, but it is of least importance. First of all, there are many many ways to split your work into user stories and do the needed. I do not think that what I am about to write is some sort of a revelation or the only correct option. It is just my preference.

Each team organize their Jira the way that works for them. Every person will have their own preferences, but for me user stories are one of the mediums for communication in the first place and anything else after that. I prefer to use them to start the discussion and share information between different parts of the working group.

Different positions require separate levels of details. For me, Jira Epics are most useful for high level stakeholders, like Product Owners. When a new Epic is created, it is mostly for business to track its progress and see when something that was promised to clients by the sales team would be actually implemented. Then there are Stories. They are handy to show the work done between developers and maybe between different dev teams. For example, I think a story like “Bootstrap a new microservice” is a good way to tell someone that soon they should be able to integrate with that new service or maybe to add business logic to it. And finally, Tasks are a great way to split those stories into manageable chunks that can easily be done in a day - and therefore easily presented during daily standups. They are used for communication inside the dev team.

So when you prepare user stories it makes sense to think from that perspective - what do you want to say and to whom? If you plan to communicate and visualize a new feature of the product, then it will make sense to create it as an epic (even if it is a tiny feature that could be completed in a couple of days!). Then when you plan to implement that new feature - split it into stories that can be useful for developers, that can highlight what will be done. And finally when someone starts work on a story - they can split it even further into tasks (like do the UI part or do the backend).

But as usual, at the end of the day, it does not really matter how you split your work as far as it is done in a accepted manner. I like to see Jira just as a tool to start the real conversation and not an ultimate manager :)