Index
[Downloads (PDF, HTML & XML formats)]
[Other versions]
Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].
2012 年 12 月 10 日
The Atlassian team announces the release of GreenHopper 6.1, launching epics out of Labs.
Thank you for your feedback:
Over 100 fixes and improvements implemented since GreenHopper 6.0
Over 500 votes fulfilled since GreenHopper 6.0
Your votes and issues help us keep improving our products, and are greatly appreciated.
Please keep logging your votes and issues. They help us decide what needs doing!
Upgrading to GreenHopper 6.1 is free for all customers with an active GreenHopper license.
If you are using GreenHopper "behind-the-firewall" (that is, if GreenHopper is installed on-premises at your site), you can upgrade GreenHopper via the JIRA Plugin Manager. Before upgrading, please read the GreenHopper 6.1 Upgrade Notes.
If you are using GreenHopper OnDemand, please watch the GreenHopper OnDemand Release Summary for the latest updates.
エピックは、ストーリーを管理する追加の階層として機能し、プロジェクト内またはプロジェクトをまたぐ課題グループに対して、計画立案する際の指針としての役割を果たします。エピックを活用することによって、スクラムマスターとプロダクトマネージャーは、すべて共通のテーマで関連している重要な課題グループを測定することができます。
In GreenHopper 6.1 we are delighted to launch epics out of Labs. Epics are now automatically enabled for every Scrum board, appearing in the left-hand panel:
Originally released (via Labs) in GreenHopper 6.0.6, we added colour customisation and inline editing in GreenHopper 6.0.7. This was followed in GreenHopper 6.0.8 by progress bars, an Epics panel that follows you down the page, and the ability to create an issue that is automatically added to your chosen sprint.
You can now exclude completed epics from Plan mode to keep it uncluttured.
Simply select Mark as Done in the epic drop-down:
Technical notes for the curious: Epics now have a custom field called Epic Status, of type Status of Epic (for details please see GreenHopper JIRA Configuration). Marking an epic as "Done" will set the epic's Epic Status field to "Done", but will not affect the epic's workflow or its Status field, and none of the epic's issues will be affected.
Change History is now stored on the epic (as well as on the included issues), and is visible when you view the issue in JIRA.
For example, if issue SSP-1 is added to epic SSP-24, then SSP-1 will look like this:
... and SSP-24 will look like this:
In Plan mode, you can now drag-and-drop issues to an epic from either the backlog, a planned sprint or an active sprint.
See Adding an Issue to an Epic.
Ever used Quick Filters in Plan mode, and forgotten they were on? (We have.)
So now there is a Filtered icon
at the top of the backlog — and in each sprint header — to indicate that one or more filters have been applied. Click it to clear all filters.GreenHopper 6.1 includes the following updates and bug fixes:
30 Comments
Anonymous
Dec 10, 2012Somewhat depressingly this seems to continue the trend of moving functionality away from JIRA which was one of the main reasons we bought into JIRA/GreenHopper in the first place. Why couldn't Stories in Epics have been handled with Issue Links? That way people would be able to use functionality that they already know to perform this task? It would also not tie people into using the Rapid Board for assigning stories to epics. GreenHopper is running at full speed in a very bad direction.
Shaun Clowes
Dec 10, 2012Hi Anonymous,
The links between Epics and their Stories are in fact issue links but they are system level so they are not shown in the links section. This is important so we can prevent loops being added as well as preventing the link type being deleted. We will shortly implement a view of the link in the view issue page.
Thanks,
Shaun
Anonymous
Dec 11, 2012But will you be able to add links on the issue view page or will you still be forced to use the Rapid Board to set up Epics?
Shaun Clowes
Dec 11, 2012We may eventually allow this to be edited by placing a value in the 'Epic Link' field, but that's undecided at this point.
Cheers,
Shaun
Janos Biro
Dec 10, 2012agreed! why do you reinvent the wheel again and again? also ... Epics are not shown in the Backlog anymore... whhyyy??
Shaun Clowes
Dec 10, 2012Hi Janos,
We're attempting to address serious deficiencies in the old implementation, not reinvent the wheel. Epics are not shown in the backlog since they're not normal stories, i.e. they're not taken in to a sprint and implemented. This is not the end of our work with Epics, expect more features over the next couple of releases.
Thanks,
Shaun
Anonymous
Dec 10, 2012It is not possible to choose Epics as swim lanes in the rapid board as you can do with Stories.
Nicholas Muldoon [Atlassian]
Dec 16, 2012Hello,
There is an story on the backlog for this feature. You can watch GHS-6426 - Getting issue details... STATUS to be notified when it is addressed.
Thank you,
Nicholas Muldoon
@GreenHopperTeam
Anonymous
Dec 10, 2012Don't see how this can be released out of Labs. All existing Epics in JIRA are shown in the format: "unlabelled-PRT-435". This should obviously display the Summary field for that epic...how did this get past testing? Also agree that by creating an entirely new field called Epic (rather than using the existing Epic/Theme field), you are making existing usage of the tool unusable, not to mention confusing–there are now two fields with Epic in the name. Putting the parent-child relationship between epics and stories nowhere in the issue summary (except a little bread crumb trail in the history) is not 'delightful'. Lastly, if there are no dashboard gadgets or other "burndown" views for an Epic, how are we supposed to see progress against epics in our organization? (BTW, the little progress bar in the board plan view doesn't seem to be working for us...) We'll continue to use the classic board and versions to track our epics until some of these deficiencies are addressed.
Shaun Clowes
Dec 10, 2012Hi Anonymous,
We will implement migration of old style Epics to new style Epics in the future, for now you can manually migrate them if you wish. It does not show the summary for the Epic because that will typically be too long, the Epic Name field is expected to be less than 30 characters (i.e. it's a short name for the Epic).
To cover your various points directly:
You can see all of those stories on our public backlog if you wish to watch them to see our progress.
Thanks,
Shaun
Anonymous
Jan 11, 2013The Epic name is quite often a high level user story, we would really like it to be able to be more than 30 characters!
Shaun Clowes
Jan 13, 2013Please use the summary for this. The purpose of the Epic name is to have a short, user recognizable label for the Epic that we can show on the cards, you can store further information (for example the complete user story) in the full summary.
Thanks,
Shaun
Andrew Arnold
Jan 31, 2013Hi,
It seems as though you can not add points directly to Epics now???!!!! Rather you have to create stories and for that epic and assign them points! When gathering requirements, many are epics and they need to be assigned points for estimation. How do you estimate your points early on when you only have epics and not all the stories?
This has really screwed up my exsisting projects as well. My epics all had points, now I can't see the points!!! Please help!
Thanks,
Drew
Anonymous
Dec 10, 2012Can this new feature be used with Kanban boards, or just scrum?
Nicholas Muldoon [Atlassian]
Dec 16, 2012Hello,
The Epics can only be used on the Scrum boards today. Plan mode is not yet available for the Kanban boards, keep an eye on GHS-6175 - Getting issue details... STATUS for updates on this functionality.
Thank you,
Nicholas Muldoon
@GreenHopperTeam
Anonymous
Dec 10, 2012Where did this fascination with Epics not being shown in the planning board come from? This was a dumbass idea. Let us decide what we want to see (or not) in the Planning Board. Quit trying to add cool functionality that only ends up irritating those of us who have actual scrum teams that use the boards and want simplicity and practicality.
Anonymous
Dec 10, 2012The biggest issue with not being able to see Epic's in the planning board is there is now no way to prioritize them. Our solution is to just make everything stories until we are ready to start working on breaking it down. At that point the individual stories can be broken down and prioritized and we convert the original story to an Epic. This is a pain in the butt process wise so if this could be automated it would be much easier.
Or just let us plan Epics.
Shaun Clowes
Dec 10, 2012Hi Anonymous,
You can still drag and drop the Epics to prioritize them (i.e put them in the expected implementation order).
Thanks,
Shaun
Anonymous
Dec 10, 2012Is there a (hidden) configuration setting available to disable the new Epic functionality (alike what was in place in 6.0.8 with the setting in Labs)?
Nicholas Muldoon [Atlassian]
Dec 16, 2012Hello,
No, there is no hidden setting to disable Epics.
Thank you,
Nicholas Muldoon
@GreenHopperTeam
Kim Poulsen
Dec 11, 2012I like getting the Epics on the side and having the ability to rank them according to importance.
There is a slight usability issue when finishing one and starting the next or when running stories from two different epics at the same time, where a lot of filtering back and forth is going to happen. In this case it would be neat to allow clicking multiple epics to get only those shown in order to rank the stories interleaved.
Otherwise I am happy and I find the feature useful and along the lines of Agile modelling of themes, epics, stories.
Peter Hill
Dec 11, 2012Kim,
I like your idea about clicking to filter by several epics at once. I think that would be a wonderful addition to the progress being made with epics.
More generally: I have several teams interested in using epics as part of the new rapid board. Before we begin using it we were hoping for some additional features. One, we would like to be able to drop an entire epic into and out of a sprint in one fell swoop. I know it's not typical to tackle an entire epic in a single sprint, but for particularly large epics it may be faster and simpler organizationally to drop the whole epic into the sprint and then pick out the bits you don't want. Also, we are hoping to see some more sophisticated reporting on the status of an epic. For example, we would like to be able to control at what point the contents of an epic are considered complete so as to move the progress bar accordingly. We'd also like to be able to get reports on the progress of epics at some level more sophisticated than a simple progress bar.
Thanks for all of your efforts guys!
Regards,
Peter
Michael Tokar
Dec 17, 2012Hi Peter,
Did you know that you can already achieve this today? If you click on an epic, it will filter down the backlog to just the issues that are part of that epic. Once you have that subset of issues, you can select all of them by clicking on the first issue, then shift+clicking on the last issue. Once you have them all selected, you can drag the issues into any future or active sprint, just like a rank operation.
To rank the issues relative to other issues not in that epic, you can create your selection, then de-select the epic to clear the filtering, then drag the issues.
I hope this helps!
Cheers,
Michael Tokar [Atlassian]
Peter Hill
Dec 17, 2012Interesting, I'll give a brief demo of this flow to the interested parties. Thanks for the tip.
-Peter
Nicholas Muldoon [Atlassian]
Dec 16, 2012Hi Peter, Kim,
Thank you for your constructive feedback on Epics, it is greatly appreciated.
Regards,
Nicholas Muldoon
@GreenHopperTeam
Shawn Maceno
Dec 28, 2012With our previous version of Greenhopper (6.0.5 I believe it was) we had a Planning Board dedicated to the prioritization of Epics. We had created 4 sprints, and divided our epics among them. Surprised to see that after the 6.1.0 upgrade, all of these sprints are empty, and there doesn't seem to be any way to get things back to the way they were. How would we go about replicating this behavior now that it is not possible to display epics inside of sprints?
Nicholas Muldoon [Atlassian]
Dec 31, 2012Hi Shawn,
Thanks for the question. A few thoughts:
1) The Plan mode in 6.1 takes Epics out of the backlog and puts them in a left hand side column. We do this as Epics represent functionality that spans multiple sprints, and the stories that comprise that epic are the pieces that fit within the sprints themselves.
2) The sprint / epic visualisation is something we are looking at under an umbrella we term 'release planning'. We will be exploring this further in early 2013.
Thank you Shawn.
Regards,
Nicholas Muldoon
@GreenHopperTeam
David Tolan
Jan 03, 2013Hi,
Given the new structure for epics, the following tickets in your backlog will be very useful for my projects. I would like to request that they be implemented soon. I tried to vote on them in the ticket, but the option is not available to me.
GHS-6426
GHS-6963
GHS-6392
For our projects, sprints are decoupled from releases, allowing us to release functionality at any time, not just at the end of a sprint. Our projects are structured as follows:
We release features at the epic level. When all the stories for an epic are completed, the epic is marked for the next release. Prior to the upgrade of Greenhopper, we were using the Work view of the rapid board along with the fixVersion field to monitor the progress of epics in a release. I heard that the version fields may be going away shortly.
Any suggestion on how we could track releases outside of sprints with the new Greenhopper structure as our previous approach no longer works since epics do not show up on the Work view of the rapid board (which is based on a sprint) and version fields may be going away?
Thanks,
David
Anonymous
Jan 31, 2013Hi,
It seems as though you can not add points directly to Epics now???!!!! Rather you have to create stories and for that epic and assign them points! When gathering requirements, many are epics and they need to be assigned points for estimation. How do you estimate your points early on when you only have epics and not all the stories?
This has really screwed up my exsisting projects as well. My epics all had points, now I can't see the points!!! Please help!
Thanks,
Drew
Andrew Arnold
Jan 31, 2013