When approaching JIRA it is best to remember that the tool initially started life as a bug-tracking system.
Components
A component is a software/hardware component that might be shared between teams, departments or across the entire company.
By tagging your stories with a component it all allows formal release management units to see exactly which components are going into a UKDT (Deployment Ticket) or a Release Registration if you are using them.
Examples
- SecureSphere
- MongoDB
- Hashicorp Vault
- Wordpress
- Chrome 54.X
- Business Objects
- Oracle X
Benefits of good component administration
By labelling your user stories with components you can also support in depth reporting from Jira
project = YOURPROJECT AND status = Blocked AND component = "Active Directory"
This report will tell you which Active Directory stories are blocked on your project but you could theoretically expand this search query to multiple components or multiple projects to gain really insightful Portfolio/System/Programme reporting to support stakeholders, business decisions or even spot impediments.
You can also then breakdown your product versions for release (1.0, 1.1, 2.8 etc) by component to see what is in each release.
As a ScrumMaster you can set a filter to show Components by Assignee and see if the same developers are grouping around the same components. That heatmap then forms the basis of cross-skilling the team. It is very easy to say to the Product Owner and/or the team?
Paul is always working on the Terraform stories. Out of 19 stories he has done 18 of them. I would like to suggest to the team a cross-skilling session but delivery may suffer in the short term as we lose 1/2 day. Can you manage your stakeholders while we do this?
Epics
Epics are probably one of the most ambiguous terms thrown around the Agile community. Very few teams in my experience use Themes so everything bigger than a user story simply gets lobbed under the heading Epic.
The official guidance from Jira is
An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs.
Mike Cohn also says the following
A Scrum epic is a large user story. There's no magic threshold at which we call a particular story an epic. It just means “big user story.” So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn't get the chance to break most of them down into stories that are probably small enough to implement directly.
Examples of Epics
- Deliver the Payments API for all accepted payment methods
- Build a web application firewall
- Develop the new sandbox
- Anti Malware capability
- Install and Configure the IDS
Benefits of good epic administration
Although it is important to start delivering working software as soon as possible it is equally important to roadmap your product effectively.
Epics are the first building block to producing coherent and credible roadmaps. By putting the Epic scaffolding into Jira first you can then build your Jira backlog in a logical manner and demonstrate to stakeholders which Epics are the focus for the next 4-12 weeks and which parcels of functionality are getting delivered later in the roadmap.
You also benefit from the accuracy of reporting articulated above. If a stakeholder asks
When will the Web Application Firewall be done?
You can quickly say we estimate the the WAF to be somewhere in the region of 25 user stories of which 6 are completed. If you consider the WAF to be the highest priority we can potentially deliver that in X amount of Sprints / weeks based on our estimates / capacity planning.
Additionally, if you subscribe to the average user story size for estimation (as I do) you can quickly tell people how long each epic will take (within reason) once the majority of the user stories are populated.
Lastly; if you are a ScrumMaster or BA then reviewing the Epics regularly will give your Product Owner a good steer to which areas are looking less well defined and need significant work to populate with stories.
