Here's a question both to the GreenHopper team and user community: how is Epic Name significantly different from issue's Summary?
Yes it is obvious that Epic Name must be short, in order to be displayed on the Scrum Board and as a "label" on the stories. Is that all the difference? Is that enough to justify having an additional required field that will contain essentially the same information as the Summary? Why it wasn't sufficient just to take the Summary, and if it's too long, then truncate it and add ellipsis? (And also if the Summary is too long, it could have been the Description.)
So, to the GreenHopper team: is there anything else behind the Epic Name, maybe in plans?
To everyone using GreenHopper: do you find Epic Names useful as a separate field? Do you really have significantly different information in Summary and Epic Name?
I have contacted several customers and fellow developers. It's common to have a lot of epics that have the same Epic Name as Summary.
We have decided to use that fact in Structure 2.1, which now automatically assigns a value for Epic Name of a new epic created inside Structure, unless the user has specifically set the name to something else.
i think this is mostly the case, and it will also be suitable for teams like ours that use code words for the Epic that are meaningless in a summary sense. For instance, we might summarise the Epic to set up auto log scanning in JIRA "Set Up Log Scanning in JIRA" but give it the Epic Name "Hercules".
How can we assign value to Epic Name automatically?
I can not put the assignment to Epic Name in the Post Function of Create transition, because the validation has been checked for Epic Name even before that. Furthermore, I assume that we will set Epic Name = Summary only if the issue is a new Epic only. What would be the Epic Name if this is not an epic?
I don't think the name and the summary are generally the same at all. The summary is usually be expressed as a user story (i.e 'As a <x> I would <x> so that <x>') but there's not really sufficient space for that to be shown everywhere, so you need a shorthand, in this case the name.
Hey Shaun, thanks for replying!
Well, I did search in jira.atlassian.com for "project=GreenHopper and type=Epic" :) Only two of the epics are formulated in the way you describe, but there's a bunch named shortly, like "Release Planning" or "Epic Support". And Epic Name for those epics is the same or very similar to the Summary. Sorry :)
Since epics are collections of stories, it seems strange to me that you expect it to be described in the same way as a story - with only one role, one subject and one action.
Regardless, you must know a lot more than me about Agile, being in touch with the community and all. That's why I'm asking this question!
Do you have a plan for Epic Names in the future? Any new functionality that touches the data model or semantics?
The definition of see of Epic everywhere is "a large user story," not a "collection" of user stories. Granted an Epic is eventually broken down into multiple stories, for practical reasons, but...
For this reason it is quite appropriate, though apparently not mandatory, to "name" the Epic "As a.. I would like to.. So that..."
No, it's not.
"Large user story" is one way to get to an Epic, but most Epics are collections of similar stories, built when people notice common patterns in the disparate stories they get. It's quite rare to see Epics written up in a story format in real life, they often collate disparate user types or desires or goals together,
we just have asked the same question in my team to understand the difference between epic name and epic summary.
First we use the summary to handle the story expression but it appears too long in several screens. So we have decided to duplicate summary and epic name for now.
Same question here. Granted, I am new to scrum, but after reading some of the theory, I was expecting JIRA to have just one field, where I would enter the epic name in the form of a user story. So I agree, having both Epic Name and Summary seems totally unnecessary and busywork.
I am confused not by the difference but instead why the default screens tend to have the summary at the top and in bold while the name is small, farther down, and non-obvious. We need to restructure peoples' natural tendencies for it to make sense. A common Epic in our system is:
Name: "Hunt Screen"
Summary: "All things related to the main hunt screen."
With the Summary being the dominate position you get some screens that are hard to find the name and titles that start with meaningless redundant data:
"All things related to ...
"All things related to ...
"Name" - in my view - so be the dominate field at the top of screens and as the only thing that shows on filter result lists. It is really odd to me that a "summary" has ended up having such a dominate role. I am still looking for was to fix this; ideally without having to be the ticket policeman and complain when people write these in the way that is natural to them.
A little explanation about where this is coming from. We're struggling to support epic names in the Structure plugin, which should be able to create epics - per user's input or as a result of cloning.
What we're seeing is that people try to create epics without specifying Epic Name and that fails of course. Cloning is a different story too - the cloned issue will have the same epic name (as another custom field), which does not make sense.
We'll do our best to support the Epic Names in a good way in the upcoming version anyway, but it would be good to know we're doing that for a good purpose!
I think other plugins that have issue creation as a part of their functionality are also affected by this.
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot