This article is part of a blog series!
| Part | Title |
|---|---|
| 1 | Yes Virginia, even agile teams roadmap! |
| 2 | Moving from roadmaps to requirements |
| 3 | Deliver well: requirements to deployment |
Prioritizing requirements using epics and versions
Now that we have all of the requirements as user stories for a particular feature inside of Jira, it’s time to start work. When we did the import of issues from Confluence, we linked each user story to an epic. An epic is a very large user story to be delivered over many iterations or versions. A small feature may fit inside of one epic whereas a large feature would be composed of several epics.
We can see in Jira Agile that each of our requirements and user stories are tagged with the epic “Large Team Support.”
The product owner has two critical tasks at this point: prioritizing the new requirements against existing work, and tagging each requirement with the release version. How do versions differ from iterations? An iteration is a potentially shippable increment of software. A version actually ships to customers. With Jira Agile, we can easily drag and drop issues to prioritize and assign versions. In this example we are first filtering by our epic, large team support. We then tag half the issues for version 2.2 and half for version 3.0.
As a particular program gets further underway, it’s important to update the project team and the stakeholders proactively, as well as provide self-service ways for the extended team to remain connected. The Confluence page we built in the last article remains a high-level overview for the feature.
If the team adds additional user stories to the epic, they won’t automatically be added to the Confluence page. Some teams prefer it that way as it maintains the original view of the epic at kickoff. Confluence can easily be extended to automatically add new issues. Just use the Jira issues macro with the following JQL:
"Epic Link" = Jira issue key
The epic key is the Jira issue ID. You can find it by clicking on the dropdown in the plan mode on your agile board. In this example the Jira issue key is TIS-3.
Enabling Visibility
Sometimes though, stakeholders and other team participants need more visibility into the engineering landscape. Well, I have good news for everyone in your project: Jira automatically highlights detailed engineering status to keep everyone in sync. The development panel highlights the key artifacts in the development process. At Atlassian, we use a branch-based workflow. Developers can begin work right from Jira using the create branch link on the issue. Jira then pre-populates the branch creation with details from the Jira issue. Branch names are created consistently across your organization for higher traceability.
We don’t stop there, though. People new to the issue need to come quickly up to speed. Jira keeps track of not only branches, but commits, pull requests, reviews, builds, and deployments all from the development panel. Check out how Jira keeps everyone in the loop.
[youtube https://www.youtube.com/watch?v=5c8BLg3YTmo]
So there you have it: roadmap to deployment. Making effective decisions is about having the right information to the right people at the right time. At Atlassian, we have tools to help out with every aspect of your development program.
Using Git?
Check out Git Essentials that combines all of our tools for an effective Git strategy at your organization.
Not Using GIT?
Check out Jira, Confluence, Bamboo, Fisheye, and Crucible for transparency like never before with Subversion, Mercurial, or Perforce!