Creating a Business Epic in JIRA Core
In a previous article I discussed applying Agile project management principles and a Scrum framework within a JIRA Core customized Project to manage the selection, configuration and go-live launch of a calendar solution for a business team. After creating a custom Research and Development (R&D) JIRA Core Project using the Project Management template, I was ready to being eliciting and documenting business needs and requirements with an Agile mindset guiding my efforts.
Getting Started with Launching a JIRA Core Agile Project
The customized R&D JIRA Core project that I configured mimicked the best of several Agile/Scrum projects that I had experienced. The result of this team effort was the timely selection, configuration and iterative release of a customized Cloud-based team calendaring solution in 2017.
Used on a daily basis, the new centralized team calendaring solution represents a significant process improvement, as compared multiple team calendar approach in use at the time by myself and my team. The team calendar application provides a long list of benefits that enables us to manage business and professional engagements efficiently and effectively.
At the beginning of our team calendaring project, my first task was to work with my business team and elicit business needs and requirements. I documented requirements using the Epic Type and Description field text provided by my customized JIRA Core R&D project, illustrated below.
Deconstructing the Business Project Epic Record
In her article How to Define Scope in an Epic, Laura Brandenburg shares the details of the Epic template she uses when writing an Agile Epic. I like her approach to scoping and writing business Epics, as it provides the clarity needed for a development team to focus in on creating an application that will be close to the Minimum Viable Application for production use.
Elaborating on Laura's Epic template example, I created the following Epic record RSD-42:
Note that high-level business requirements for the Calendaring application have been summarized in the Epic record Description field. The Description field is sub-divided into eight paragraph sections that address:
The information contained in each section of the Epic record can be used to create application Sub-Epic records that provide more detailed requirements that will govern the configuration of specific calendaring application functions.
The completed Team Calendaring Epic provides enough information to enable members of the application development team to develop Sub-Epics and supporting Business User Stories that will drive configuration of the calendar application accordingly.
Sub-Epic Records Drive Business User Story Requirements
When I completed documenting the overall key core functional requirements in the application Epic record RSD-42, I turned my attention to providing more detailed requirements for key application features and functions. As a result, I created several child sub-Epics to elaborate on business requirements provided in the main parent Epic RSD-42.
Business requirements documented as sub-Epics are also sub-divided into paragraphs to provide context for developers to create and test needed application features and functions. The information conveyed in each of the sub-Epic Description paragraph sections drives the development of Business User Stories (BUS), which developers use to create software or configure applications based on the information provided.
Epics, Sub-Epics and Business User Stories are also used by User Acceptance Test (UAT) teams to develop an Application Test Plan (ATP). An ATP specifies functional test criteria used by business stakeholders, application developers and members of the UAT team to determine the extent and degree that an application is functioning as designed to requirements.
Keep in mind that the breadth, detail and level of completeness of requirements documented in Epics, sub-Epics and Business User Stories can significantly reduce the number of development iterations needed to produce a MVP ready for production release. The more information provided, the less guesswork (and iterations) the development will need to produce what is desired by business stakeholders.