Epics, which were introduced in GreenHopper 6.1, are a group of related user stories and usually capture a large body of work or a big project.  For example, the University team currently has an epic for all work related to an upcoming homepage redesign.  We had an epic for all work related to our better, faster, stronger lesson type we released in March, but since all the user stories were marked as ‘Done’, we also marked the epic as ‘Done’.

Epics help organize user stories in the Plan, Work and Report Mode.

• In Plan Mode, it is possible to sort user stories by epics.  Also, all user stories in epics have color coded tags so you can quickly see which backlog issues are related.
• In Work Mode, it is possible to set up swimlanes by epic.
• In Report Mode, there is an Epic Report which shows a list of complete, incomplete and unestimated issues in an epic. This is useful for planning work for an epic that extends over multiple sprints.

To create an epic:

1. Go to the plan mode of the board you are working on (note: Epics are only available for Scrum Boards)
2. Click ‘Epics’ on the left side (or select Tools> Show Epic Panel)
3. Click the Create icon (the “+” sign) at the top right of the Epics panel
4. You will be prompted to create an issue of type “Epic”
5. In the Epic Name field, enter a short name. The Epic Name (rather than the Summary) will be used to identify your epic and to label issues that belong to it.

Great, the Epic is now added to the board

To view or add an epic, click the EPICS link on the left side of the screen. The yellow ‘Rich Media’ tag is an Epic tag. The ’2.0′ and ’2.1′ tags are Version tags.

Plan mode with the Epics panel open. Clicking on any epic will filter the backlog to only show user stories in that epic.

If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.

What’s the word on the street?

Hey @greenhopperteam, version report from a live @unbounce project with notes. So useful, thx! #agile twitter.com/carl_schmidt/s…

— Carl Schmidt (@carl_schmidt) April 19, 2013

@greenhopperteam Love… It! Keep on Rocking!

— Kevin Allen (@Mac42az) April 22, 2013

Atlassian #GreenHopper 6.2 now has Release planning capability and burndown gadgets! Finally the critical mass of features to get me to buy. — Mark Thomas (@mrt11) April 24, 2013

@atlassian Love the new version plan in #Greenhopper

— Kevin Shine (@KEV_SHINE) April 23, 2013

See what all the fuss is about

GreenHopper 6.2 helps teams satisfy their customers through early and continuous delivery of valuable software and gain confidence over the value and timing of delivery. Check out our demo video of scrum planning and reporting with GreenHopper 6.2:

Don’t delay, upgrade today

GreenHopper 6.2 is available today, so what are you waiting for? Download and upgrade now!

Get GreenHopper 6.2

Using JIRA OnDemand?
Congratulations, you have already been auto-upgraded!

Establish a Triage Process

Once your product has a feedback stream flowing, you will need to take action on it.  Input should always be coming directly from your customers, using tools like Bonfire, JIRA Issue Collectors, and JIRA Mobile Connect–at Atlassian we use JIRA to manage user feedback on our products at https://jira.atlassian.com.   Not all feedback in the backlog is valuable however.  Set up a simple feedback loop to triage all incoming feedback.  You’ll want to understand each piece of feedback and see if it is:

• Valid and on target for action: “When I click button X I expect Y to happen but instead Z happens”
• Represented elsewhere: two tickets express the same feedback.
• Not relevant to the product direction: “There should be another button for option X”
• Not cost effective to implement: “Hitting esc in the browser should save my form text should I want to re-use it”
• As designed – the product team made an explicit decision to work this way.  Feedback here should be carefully reviewed.

If your product backlog is clogged with inactionable feedback, you’ll have a harder time moving forward.  Send the inactionable feedback to a parking lot.  We close tickets of this type with the appropriate resolution.  Closed issues are not lost!  We can target searches of closed issues just like open ones.  Tagging an appropriate resolution makes searching closed issues much more efficient.  You never want to delete feedback as you may want to come back to it, thus take the time to ensure you can quickly find it later.  JIRA’s resolution fields can be customized to add each of the cases above.  Epics, components, and labels can track large feature areas for review at a later time.

Tier Your Backlog

It costs a product owner time for each issue he or she reviews. The JIRA team uses a three tier backlog to denote levels of review for each piece of feedback. If we expand the first “passes review” section above we can see two more levels of fidelity in our backlog.

In the raw feedback stage the product owner quickly decides whether to keep or pass on a piece of feedback.  If the feedback is kept, then it gets moved to the unprioritized state.  This means the product owners intend to take action on it at some point, but it’s not in a state where it can be handed off to the product teams.  Once the product owner has flushed out a particular story it moves from the unprioritized state into the ready for feature teams queue.  This queue is the tight, ordered backlog that the product teams can quickly pull into future sprints.

What happens when the ready for feature teams queue gets low?  The product owner only has to pull from the unprioritized queue.  He or she doesn’t have to look over the entire backlog as there is a higher fidelity set of data ready for review.  Rather than review potentially hundreds (or thousands) of issues, the product owner can see a set of a much lower magnitude.

GreenHopper, it’s not just for Developers

GreenHopper is the agile plugin for JIRA.  Many development teams use it to track their work in an agile fashion.  Product owners can use it to track their backlogs.  The JIRA PM team tracks their backlog using GreenHopper using a Kanban board.  Kanban boards model a flow process so it is easy to see issues flow from feedback into features. Note, this is a different board than development uses.  Think of it as the precursor to the development process.

The JIRA roadmap backlog has four major states:

• Not Ready Yet – Raw feedback
• Unprioritized – Committed to the back log, but not ready for handoff to development
• Ready for Feature teams – The feature teams should work on the highest priority items first
• In Design (PM and Dev) – The feature story is actively being worked on.

The PM team then uses swim lanes to group issues by epic so all of the related issues are contextually close to one another on the screen.  Swim lanes can be easily collapsed so the PMs can focus on one epic at a time.  This helps the PM quickly traverse the backlog.

Ready to transform your backlog?  Try GreenHopper today!

Try GreenHopper

• New Epic Report – track progress toward larger feature work spanning multiple sprints
• New Version Report – projected completion dates calculated per-day based on historical velocity, giving you confidence as you get close to completion dates
• New Gadgets – keep stakeholders informed and broadcast status to the entire team

All About Reporting

Track progress toward large feature work spanning multiple sprints

Epics help you get a handle on large areas of functionality and break down a large backlog so you can deliver chunks of value with each sprint. The new Epic Report enables the product owner and team to get a quick handle on progress both by number of story points and by number of issues, and keep a watch out for potential risk areas in unestimated issues.

Gain confidence over release dates

As you plan value across a larger release, keeping track of work across the entire project by Version is a big job. The new Versions tab on the Plan board helps you plan progress toward each release in individual sprints. Assign issues to a version via drag and drop.

The new Version Report will help you ensure the release is on track. The chart calculates your historical velocity per-day, and you can configure non-working days to ensure the projection is accurate. The closer you get to release date, the more confidence you’ll gain with what you’ll deliver and when.

JIRA Dashboards keep everyone on the same page

New gadgets will make your information radiator even more powerful! The Sprint Burndown gadget helps your team keep an eye on progress, and the Days Remaining gadget reminds everyone just how close you are to delivering value to your customers.

Bonus: Configure the Detail View

We’ve been heads-down focused on all things reporting in GreenHopper, but we managed to slip in another goodie during 6.2 development. You asked, we delivered: you can now configure the detail view on the right side of the Plan and Work boards to show the fields that matter most to your team!

Better your Agile Practices

Satisfying the customer through early and continuous delivery of valuable software is the highest priority of any agile team. Get GreenHopper 6.2 today and gain confidence over the value and timing of your delivery.

Get GreenHopper 6.2

JIRA OnDemand customers have already been upgraded to GreenHopper 6.2.

Yves Riel acts as a Scrum Coach to help teams learn the Scrum methodology. Yves has actively been using JIRA and GreenHopper since 2009. He built Rekall for JIRA to help agile teams improve their estimates.

Every year, I try to make an appointment with my doctor for an annual check-up. Invariably, I walk out of his office with a blood tests form in my hand. These tests are what helps my doctor notice illnesses like high cholesterol or diabetes. About two years ago, I began to suspect my agile team was suffering from a different disease: Estimation Disorder. Unfortunately, I had no tools to diagnose the problem like my doctor, so I started to keep track of some data. After a few weeks, I plotted the distribution of the time spent executing the issues versus their story points value. I also extracted statistical data such as the minimum and maximum time spent on issues as well as their average and standard deviation. These graphs became an invaluable tool in my fight against my teams’ Estimation Disorder. This article will show you some of the pathologies that can be discovered by looking at the graphs’ profile.

“Story Point Favoritism” pathology

After a while, some teams start to lose perspective and see everything to be the same size. Hence, they end up having one or two favorite Story Point values. This pathology is relatively easy to diagnose. When looking at graph, you see that the distribution of some Story Points is disproportionate with respect to the others. The most common symptom is that almost all the new items in the product backlog are estimated at the same Story Point value. The team may also experience a fluctuating velocity since there are too much differences in the time required to execute the stories. This will especially hold true if your sprint includes user stories that are in the lower and higher percentiles of the distribution.

“Exponentiality” pathology

In order to be an effective estimation technique, Story Point values must follow a linear trend. When it is not, the extrapolated date for the completion of the product backlog may be completely off. If your team has success planning and executing smaller user stories but struggles with the bigger ones, it may suffer from the “Exponentiality” syndrome. To confirm this diagnostic, look at the graph and try to locate a big jump in the data. The text book pathology is for a team to exhibit a very good linear trend for the smaller Story Points (0.5, 1, 2, 3 and even 5) but to diverge considerably for higher Story Points. It is as if these higher Story Points would fit the trend much better if pushed further to the right. If the velocity of teams exhibiting this pathology has been based on sprints containing mainly lower Story Points items, you should use extreme caution in calculating a product backlog completion date; especially if the backlog contains many higher Story Points user stories.

“Venn” pathology

This pathology gets its name from Venn diagrams. Venn diagrams are useful when you want to see if an item actually belongs to different data set. Therefore, the graph of teams displaying this pathology will show a large overlap over two or many Story Points. It is not uncommon for teams to start developing this pathology after being pressured by management to increase their velocity. The team will then subtly increase the Story Points value of stories over time. After a while they can start claiming more Story Points per sprint but they fail to realize that similar items were previously executed at a lower Story Points value. It is also very common for these teams to have their velocity greatly fluctuate sprint after sprint.

Just what the doctor ordered

If you diagnose your team to suffer from one of the above mentioned pathology, do not despair. With a little bit of work and patience, they can be cured from their affliction. The prescribed remedy is to recalibrate your Story Points benchmark and start using Triangulation. However, just like blood tests, you should run these checks on your team periodically since you never know when they can have a relapse.

Get Started with Triangulation in JIRA Here

This webinar is an introduction to Scrum and Kanban and how iteration and flow based workflows can be implemented in Atlassian GreenHopper. Covering the new GreenHopper Boards, Epics and Sprints along with the three new modes Planning, Working and Reporting, you will leave the session understanding how your team can use GreenHopper to become agile.

Participation in these sessions is an exclusive benefit for Atlassian Enterprise customers. This and other workshops are available in our Enterprise Resources.

From growing startups to the Fortune 100, Atlassian Enterprise offers support and services built to match the needs of the largest enterprise customers. With Enterprise offerings available for JIRA, Confluence and Stash, Atlassian has your covered when it comes to managing your software development and company-wide collaboration needs.

Learn More about Atlassian Enterprise

In the past we’ve looked many times at JIRA keyboard shortcuts, including my four favorites. Today I’d like to share with you my favorite GreenHopper keyboard shortcut: T!

Whenever you find yourself in need of more details for any issue on the Plan or Work board in GreenHopper, simply hit “t” to toggle the detail view on the right side of the screen. From here, you can view the description and comment thread, along with other details, and even make changes.

So the next time you need to see issue details, don’t leave the board you’re working on – just hit “t” to toggle the detail view on and off.

If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.

Save 2 clicks a day by setting your JIRA home to Agile

How do you access GreenHopper?  Do you go to JIRA, click the Agile tab, then choose your Rapid Board?  Wouldn’t it be better if you were taken directly to your Rapid Board?  It takes 2 seconds, here’s how:

Open up JIRA and click your icon in the top right corner.  In the drop down menu, set your JIRA home to Agile.  OK, that’s it.  Now, every time you login, you will be taken to the last Rapid Board you were on.

If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.

Here are 3 ways to indicate you are waiting on other work to be done before you start working on your task.

Say you need to update a page, but are waiting on your designer to give you the polished images, or you are waiting for your PM to get the wireframes approved before you start development, how do you indicate to the rest of your team that an issue is waiting on someone else before you can take action? Check out these 3 options to indicate ‘waiting’ on your GreenHopper board:

Start by configuring your board

For all 3 options, you need to go to the Configure page.  To get there, go to your board, and under the Tools menu, click Configure:

OK, we’re ready to change our board…

Option 1: Add a “Waiting” swimlane

Here you’ll simply add a label to any issue that you are waiting on. The swimlane will only appear when issues on your board have that label:

• Click the “Swimlane” tab
• Base Swimlane on “Queries”
• Name the Swimlane “Waiting”,
• Add labels = “waiting”
  • Learn more about JQL here
• Click Add

Now any time you want to indicate that a story is in Waiting, simply edit the labels field on that issue to include “waiting”.

Option 2: Change card color

• Click the “Card Colours” tab
• Base card colours on “Queries”
• Choose your colour
  • Add labels = “waiting”
• Click Add

Just like the swimlane, any time you want to indicate that a story is in Waiting, simply add a “Waiting” label.

Option 3 (admins only): Add a “Waiting” column

In the “Swimlane” and “Card Colour” example, we added a “Waiting” label.  For option 3, we’ll add a “Waiting” status to the workflow, and move issues in and out of that status.

• First, configure your workflow to add a new status and step
  • Learn more about configuring workflow here
• Head back to GreenHopper to configure your board
• Click the “Column” tab
• Then click the “Add Column” button
• Name the column “Waiting”,
• Drag and drop the column to a point where it makes sense in your flow

Share your ideas

What are some other ways to indicate that you are waiting on someone else before you can take action on an issue? Share in the comments below.

If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.

Free Screencast: Agile Best Practices

Agile software development methodologies like Scrum are easy to learn, but hard to master. It’s easy to get some of the details wrong. This could keep your team from receiving all the benefits the framework has to offer, or worse, lead to poor communication and defects.

This screencast will walk you through Agile best practices, with a discussion of some of the pitfalls, and ways to get your team back on track.