Leaving aside some realy "big gun" systems like IBM Doors (which the
client's infrastructure mandated) I've seen JIRA used quite well to define
and estimate stories.
If you haven't looked at JIRA 5 or 6 java.net provides, both "Story" and
"epic" are there (same with the clients who use it for full scale Agile
planning and estimation)
That's the idea, not to create bugs or improvements (I don't think "new
feature" is actually offered but maybe it depends on how the java.net
project is set up there)
Werner
On Mon, Mar 9, 2015 at 10:49 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> On Mon, Mar 9, 2015 at 2:37 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> Hi,
>>
>> On Mon, Mar 9, 2015 at 9:52 PM, Les Hazlewood <les_at_stormpath.com> wrote:
>> > Where is discussion of design and features to be done? I see many Jira
>> > issues (presumably that are up for discussion), and thoughts/concepts in
>> > emails. Should we discuss as Jira comments? Or email thread posts?
>>
>> The way that the process is mostly carried out in the other EGs is
>> that JIRA issues are created, which are then discussed on the EG
>> mailing list.
>>
>
> I think creating Jira issues before a high level outline or 'epics' or
> 'stories' (or 'topics' and 'sub topics') are defined is backwards.
> Shouldn't we all be on the same page and have an understanding of the
> higher level picture and (general) topics/sub-topics before we go debating
> specific features and tasks? The JSR is a good start, but too high level,
> and Jira issues are too low level (IMHO). More, they are myopic: when
> looking at a single jira issue, I can't see how it relates to other issues,
> where it aligns with other issues in its 'category', or where it fits in
> the general scheme of things.
>
> In other words, Jira is an issue tracker - it is marginal at best for
> feature management (whereas, Confluence - as just one of many examples - is
> better for that).
>
> My .02,
>
> Les
>