Any work request involving more than a simple task in a single sprint will likely require considerable planning and organization. This is the role of the EPIC in Jira. It is a mechanism to unify a large body of disparate work into a measurable goal. As always keep your focus on what is absolutely necessary for a minimum viable product (MVP). Any requirement that would be considered phase 2 or nice to have should be clearly labeled PostMVP.
Here an example JIRA Ticket, showing how the proper framework for a story should be implemented (using the copy/paste list below): Please use the referenced copy in DPT-1 as the framework for your project. You should include the following, if applicable. In addition the team has created a T-Shirt sizing guide to assist in estimating the cost of such long tail projects.
Note that some may not apply to all user stories (or defects), but the main FOUR elements should be included always:
- Summary
- Requirements
- Post Production Owner
- Timing
SUMMARY
Paragraph / sentence description explaining what is broken or a new feature and how it it relevant to the business.
One possible format is :“As a [user] would like to [do something] to [achieve some benefit].”
Business Benefits
List of specific benefits to be achieved. Answering the “why bother?” question.
TIMING
Is this needed in any particular timeline? Use “Due Date” field as well, if possible
Scenarios
Define scenarios so reqs align with how people will actually use the feature.
Existing functionality to integrate – If building on top of existing functionality, list out what could be impacted or any integration needed.
Nice to have features – Lower priority items to enhance a feature. Dev to pull from this list when/if something above is quicker to do than anticipated.
POST PRODUCTION OWNER
After go-live, which group / person is responsible for this product? (who will use it? who should help do sign off / testing?)
StakeHolders
A list of the Stake holders relevant to this project/EPIC.
Platforms/Sites
This is now covered in the Products field, but additional notes can be added in the description as needed.
REQUIREMENTS
AKA Features list/MVP – Identify features included in the “scope” of the item to create a minimum viable product.
Acceptance Criteria
This should be covered in the Acceptance Criteria field. What will be considered a success by the product owner or business stakeholder? This field is used for QA verification.
Initial Metrics
What is the baseline (if there is one)? Examples: current page views, video views, CPM, etc.
Expected Results / Goals / Revenue – What is expected after this is completed?
Out of scope
Want to deliver MVP needed to create value. Specify out of scope items so they don’t divert the team’s focus from delivering the value proposition. Assumptions – Elements assumed to be true that were validated (or invalidated) by the business stakeholders.