JIRA is very configurable, and as such the best way to map your JIRA data to Wizeline will vary depending on how you’ve configured JIRA at your organization. Here are some best practices for common JIRA configurations.
Epic as Feature-level User Story, within a Release
In this case, epics are used as complete user stories, with many stories within the epic that break down the individual components of the user story. One or more epics will be delivered as part of a larger release, which is used to group any number of user stories.
If you use epics in JIRA in this way, you can think of a feature in Wizeline as an analog for your epic. Once you’ve set your priorities in Wizeline, you can create an epic from Wizeline and send it to JIRA. Your development team can break this epic down into its story-level components. As a product manager, you won’t need to log in to JIRA to look at the progress of your epic, and status will update automatically as your team begins and completes their stories.
If your developers need to add a story as they get deeper into their work, they can add new issues or stories to your epic within JIRA, and Wizeline will automatically track progress.
Epic as Release or Sprint
In this case, epics are used to contain all stories and tasks that will be delivered at a given point in time (so an Agile team might use an epic to define a sprint, for instance). Everything in the epic will be delivered by the release end date, and things that don’t get delivered will be deprioritized or deferred to a later release.
If you use epics in JIRA in this way, you can think of a release in Wizeline as a container for the work within your epic in JIRA. Set your priorities in Wizeline, create stories from Wizeline, and send them to JIRA; alternatively, map your JIRA stories to corresponding features in Wizeline from within JIRA. Some may be 1 story = 1 feature, and some will be many stories = 1 feature, depending on the level of granularity of stories in your epic.
As a product manager, make sure that all of your features are mapped, and track status as work is delivered. If your developers need to add a story, they can map it to an existing feature, or map it to a new feature that you create if you decide to expand the scope of your release.
Epic as Category or Theme Grouping
In this case, epics are used to categorize work across various releases, projects, or teams. For instance, an ‘iOS’ epic might be used to categorize any work that is relevant to the iOS mobile operating system across iPad and iPhone app (or front and back-end) teams.
If you use epics in JIRA in this way, you have a couple options.
- You can think of a field in Wizeline as an analog for your epic in JIRA. You’ll want to use releases to define when specific sets of work are delivered and map stories in your epic to their respective features in Wizeline across releases or sprints. Creating a custom field to match your epic allows for labels on features in that field across all features in your backlog or in releases.
- You can use an Initiative in Wizeline as an analog for your epic in JIRA. Use releases to define when specific sets of work are delivered and map stories in your epic to their respective features in Wizeline across releases or sprints. You’ll be able to track progress from JIRA at the Initiative level in Wizeline, giving you epic-level reporting across one or more different project or product areas.