Re: More Project Structure in JIRA

[Bernd Mathiske]

All,

thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do this 
from now on!

Bernd

> On Oct 28, 2015, at 2:52 AM, Klaus Ma  wrote:
> 
> +1
> 
> On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin  wrote:
> 
>> +1
>> 
>> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:
>> 
>>> +1
>>> 
>>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
>>> 
 +1 Yes please!
 
 2015-10-19 16:09 GMT+08:00 Alexander Rojas :
 
> +1 Yes please!
> 
>> On 15 Oct 2015, at 10:11, Bernd Mathiske 
>>> wrote:
>> 
>> Proposal: in extension of today’s limited two-level (epic, task)
> approach, make full use of expressive power already available in JIRA
>>> to
> provide more structure for larger projects to facilitate planning,
> tracking, and reporting. This will facilitate dynamically planning of
> sub-projects, which will make us more agile.
>> 
>> The general idea is to use links between epics to provide a
>> recursive
> hierarchical structure, with which one can span trees or DAGs of
> arbitrarily large projects. This does not mean that we want to plan
> everything in minute detail before starting to work. On the contrary.
>> 
>> You can start anywhere in the eventual tree and express part of the
> overall effort, maybe say a short epic with a few task tickets. Then
>>> you
> can LATER make this epic a dependency for a larger effort.
>> 
>> Conversely, you can subdivide a task in the epic into subtasks.
 However,
> this does not mean that you have to literally use the feature
>> “subtask”
 in
> JIRA for this. Instead, staying recursive in our JIRA grammar, so to
 speak,
> convert the task to an epic and then create ordinary tasks in it to
> represent subtasks.
>> 
>> Now the task cannot be a task in its parent epic anymore. We fix
>> this
 by
> putting in a link of type "blocks" to the parent. When you then look
>> at
 the
> parent, it still holds a number of tasks, and it has one dependency
>> on
>>> an
> epic (to which you can add more).
>> 
>> Thus our dependency tree can grow in all directions. You can also
> rearrange and update it in any shape or form if necessary.
>> 
>> Overall, we only use two JIRA elements: epics and tasks (of
>> different
> flavors such as bugs, improvements, etc.). Tasks are the leaves,
 everything
> else is an epic. Review requests only ever happen for tasks.
>> 
>> The epics are there to provide a high level view and to allow
>> dynamic
> (“more agilish”, non-waterfall) planning. Granted, you’d also use a
>>> tree
 if
> you did waterfall. The difference is that you’d spec it all out at
>>> once.
 My
> observation is that not too few of us do exactly this - outside JIRA
>> -
 and
> then try to remember what tickets are where in their tree. Let’s make
 this
> part of JIRA!
>> 
>> Why not use labels? Because they are in a flat name space and we
>> want
 to
> represent tree structure. How would you know that a label denotes a
> subproject of another label? By memorizing or by depicting a tree
>>> outside
> JIRA. Why not use components? Same problem as with labels: flat name
 space.
> We can use labels and components these for many other purposes.
>>> Separate
> discussion.
>> 
>> Aren’t we doing this already? Probably. I have not checked
>>> thoroughly.
> There may occasionally be epics that link to other epics. If so, I
>>> would
> merely like to encourage us to use this powerful expressive means
>> more
> often.
>> 
>> Bernd
>> 
> 
> 
 
 
 --
 Deshi Xiao
 Twitter: xds2000
 E-mail: xiaods(AT)gmail.com
 
>>> 
>> 
> 
> 
> 
> --
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform Symphony/DCOS Development & Support, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: More Project Structure in JIRA

[Adam Avilla]

This is great! I am not one of the devs, but the more transparency and ease
of use there is in our tools, the easier it is to focus on the actual work,
and not the process. I really like Martin Fowler's quote from
http://martinfowler.com/articles/newMethodology.html:

"Agile methods are people-oriented rather than process-oriented. The goal
of engineering methods is to define a process that will work well whoever
happens to be using it. Agile methods assert that no process will ever make
up the skill of the development team, so the role of a process is to
support the development team in their work."

On Mon, Nov 9, 2015 at 4:51 AM, Bernd Mathiske  wrote:

> All,
>
> thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do
> this from now on!
>
> Bernd
>
> > On Oct 28, 2015, at 2:52 AM, Klaus Ma  wrote:
> >
> > +1
> >
> > On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin 
> wrote:
> >
> >> +1
> >>
> >> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
> >>>
>  +1 Yes please!
> 
>  2015-10-19 16:09 GMT+08:00 Alexander Rojas :
> 
> > +1 Yes please!
> >
> >> On 15 Oct 2015, at 10:11, Bernd Mathiske 
> >>> wrote:
> >>
> >> Proposal: in extension of today’s limited two-level (epic, task)
> > approach, make full use of expressive power already available in JIRA
> >>> to
> > provide more structure for larger projects to facilitate planning,
> > tracking, and reporting. This will facilitate dynamically planning of
> > sub-projects, which will make us more agile.
> >>
> >> The general idea is to use links between epics to provide a
> >> recursive
> > hierarchical structure, with which one can span trees or DAGs of
> > arbitrarily large projects. This does not mean that we want to plan
> > everything in minute detail before starting to work. On the contrary.
> >>
> >> You can start anywhere in the eventual tree and express part of the
> > overall effort, maybe say a short epic with a few task tickets. Then
> >>> you
> > can LATER make this epic a dependency for a larger effort.
> >>
> >> Conversely, you can subdivide a task in the epic into subtasks.
>  However,
> > this does not mean that you have to literally use the feature
> >> “subtask”
>  in
> > JIRA for this. Instead, staying recursive in our JIRA grammar, so to
>  speak,
> > convert the task to an epic and then create ordinary tasks in it to
> > represent subtasks.
> >>
> >> Now the task cannot be a task in its parent epic anymore. We fix
> >> this
>  by
> > putting in a link of type "blocks" to the parent. When you then look
> >> at
>  the
> > parent, it still holds a number of tasks, and it has one dependency
> >> on
> >>> an
> > epic (to which you can add more).
> >>
> >> Thus our dependency tree can grow in all directions. You can also
> > rearrange and update it in any shape or form if necessary.
> >>
> >> Overall, we only use two JIRA elements: epics and tasks (of
> >> different
> > flavors such as bugs, improvements, etc.). Tasks are the leaves,
>  everything
> > else is an epic. Review requests only ever happen for tasks.
> >>
> >> The epics are there to provide a high level view and to allow
> >> dynamic
> > (“more agilish”, non-waterfall) planning. Granted, you’d also use a
> >>> tree
>  if
> > you did waterfall. The difference is that you’d spec it all out at
> >>> once.
>  My
> > observation is that not too few of us do exactly this - outside JIRA
> >> -
>  and
> > then try to remember what tickets are where in their tree. Let’s make
>  this
> > part of JIRA!
> >>
> >> Why not use labels? Because they are in a flat name space and we
> >> want
>  to
> > represent tree structure. How would you know that a label denotes a
> > subproject of another label? By memorizing or by depicting a tree
> >>> outside
> > JIRA. Why not use components? Same problem as with labels: flat name
>  space.
> > We can use labels and components these for many other purposes.
> >>> Separate
> > discussion.
> >>
> >> Aren’t we doing this already? Probably. I have not checked
> >>> thoroughly.
> > There may occasionally be epics that link to other epics. If so, I
> >>> would
> > merely like to encourage us to use this powerful expressive means
> >> more
> > often.
> >>
> >> Bernd
> >>
> >
> >
> 
> 
>  --
>  Deshi Xiao
>  Twitter: xds2000
>  E-mail: xiaods(AT)gmail.com
> 
> >>>
> >>
> >
> >
> >
> > --
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform Symphony/DCOS Development & Support, 

Re: More Project Structure in JIRA

[Klaus Ma]

+1

On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin  wrote:

> +1
>
> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:
>
> > +1
> >
> > On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
> >
> > > +1 Yes please!
> > >
> > > 2015-10-19 16:09 GMT+08:00 Alexander Rojas :
> > >
> > > > +1 Yes please!
> > > >
> > > > > On 15 Oct 2015, at 10:11, Bernd Mathiske 
> > wrote:
> > > > >
> > > > > Proposal: in extension of today’s limited two-level (epic, task)
> > > > approach, make full use of expressive power already available in JIRA
> > to
> > > > provide more structure for larger projects to facilitate planning,
> > > > tracking, and reporting. This will facilitate dynamically planning of
> > > > sub-projects, which will make us more agile.
> > > > >
> > > > > The general idea is to use links between epics to provide a
> recursive
> > > > hierarchical structure, with which one can span trees or DAGs of
> > > > arbitrarily large projects. This does not mean that we want to plan
> > > > everything in minute detail before starting to work. On the contrary.
> > > > >
> > > > > You can start anywhere in the eventual tree and express part of the
> > > > overall effort, maybe say a short epic with a few task tickets. Then
> > you
> > > > can LATER make this epic a dependency for a larger effort.
> > > > >
> > > > > Conversely, you can subdivide a task in the epic into subtasks.
> > > However,
> > > > this does not mean that you have to literally use the feature
> “subtask”
> > > in
> > > > JIRA for this. Instead, staying recursive in our JIRA grammar, so to
> > > speak,
> > > > convert the task to an epic and then create ordinary tasks in it to
> > > > represent subtasks.
> > > > >
> > > > > Now the task cannot be a task in its parent epic anymore. We fix
> this
> > > by
> > > > putting in a link of type "blocks" to the parent. When you then look
> at
> > > the
> > > > parent, it still holds a number of tasks, and it has one dependency
> on
> > an
> > > > epic (to which you can add more).
> > > > >
> > > > > Thus our dependency tree can grow in all directions. You can also
> > > > rearrange and update it in any shape or form if necessary.
> > > > >
> > > > > Overall, we only use two JIRA elements: epics and tasks (of
> different
> > > > flavors such as bugs, improvements, etc.). Tasks are the leaves,
> > > everything
> > > > else is an epic. Review requests only ever happen for tasks.
> > > > >
> > > > > The epics are there to provide a high level view and to allow
> dynamic
> > > > (“more agilish”, non-waterfall) planning. Granted, you’d also use a
> > tree
> > > if
> > > > you did waterfall. The difference is that you’d spec it all out at
> > once.
> > > My
> > > > observation is that not too few of us do exactly this - outside JIRA
> -
> > > and
> > > > then try to remember what tickets are where in their tree. Let’s make
> > > this
> > > > part of JIRA!
> > > > >
> > > > > Why not use labels? Because they are in a flat name space and we
> want
> > > to
> > > > represent tree structure. How would you know that a label denotes a
> > > > subproject of another label? By memorizing or by depicting a tree
> > outside
> > > > JIRA. Why not use components? Same problem as with labels: flat name
> > > space.
> > > > We can use labels and components these for many other purposes.
> > Separate
> > > > discussion.
> > > > >
> > > > > Aren’t we doing this already? Probably. I have not checked
> > thoroughly.
> > > > There may occasionally be epics that link to other epics. If so, I
> > would
> > > > merely like to encourage us to use this powerful expressive means
> more
> > > > often.
> > > > >
> > > > > Bernd
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Deshi Xiao
> > > Twitter: xds2000
> > > E-mail: xiaods(AT)gmail.com
> > >
> >
>



-- 
Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
Platform Symphony/DCOS Development & Support, STG, IBM GCG
+86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me

Re: More Project Structure in JIRA

[Shuai Lin]

+1

On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:

> +1
>
> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
>
> > +1 Yes please!
> >
> > 2015-10-19 16:09 GMT+08:00 Alexander Rojas :
> >
> > > +1 Yes please!
> > >
> > > > On 15 Oct 2015, at 10:11, Bernd Mathiske 
> wrote:
> > > >
> > > > Proposal: in extension of today’s limited two-level (epic, task)
> > > approach, make full use of expressive power already available in JIRA
> to
> > > provide more structure for larger projects to facilitate planning,
> > > tracking, and reporting. This will facilitate dynamically planning of
> > > sub-projects, which will make us more agile.
> > > >
> > > > The general idea is to use links between epics to provide a recursive
> > > hierarchical structure, with which one can span trees or DAGs of
> > > arbitrarily large projects. This does not mean that we want to plan
> > > everything in minute detail before starting to work. On the contrary.
> > > >
> > > > You can start anywhere in the eventual tree and express part of the
> > > overall effort, maybe say a short epic with a few task tickets. Then
> you
> > > can LATER make this epic a dependency for a larger effort.
> > > >
> > > > Conversely, you can subdivide a task in the epic into subtasks.
> > However,
> > > this does not mean that you have to literally use the feature “subtask”
> > in
> > > JIRA for this. Instead, staying recursive in our JIRA grammar, so to
> > speak,
> > > convert the task to an epic and then create ordinary tasks in it to
> > > represent subtasks.
> > > >
> > > > Now the task cannot be a task in its parent epic anymore. We fix this
> > by
> > > putting in a link of type "blocks" to the parent. When you then look at
> > the
> > > parent, it still holds a number of tasks, and it has one dependency on
> an
> > > epic (to which you can add more).
> > > >
> > > > Thus our dependency tree can grow in all directions. You can also
> > > rearrange and update it in any shape or form if necessary.
> > > >
> > > > Overall, we only use two JIRA elements: epics and tasks (of different
> > > flavors such as bugs, improvements, etc.). Tasks are the leaves,
> > everything
> > > else is an epic. Review requests only ever happen for tasks.
> > > >
> > > > The epics are there to provide a high level view and to allow dynamic
> > > (“more agilish”, non-waterfall) planning. Granted, you’d also use a
> tree
> > if
> > > you did waterfall. The difference is that you’d spec it all out at
> once.
> > My
> > > observation is that not too few of us do exactly this - outside JIRA -
> > and
> > > then try to remember what tickets are where in their tree. Let’s make
> > this
> > > part of JIRA!
> > > >
> > > > Why not use labels? Because they are in a flat name space and we want
> > to
> > > represent tree structure. How would you know that a label denotes a
> > > subproject of another label? By memorizing or by depicting a tree
> outside
> > > JIRA. Why not use components? Same problem as with labels: flat name
> > space.
> > > We can use labels and components these for many other purposes.
> Separate
> > > discussion.
> > > >
> > > > Aren’t we doing this already? Probably. I have not checked
> thoroughly.
> > > There may occasionally be epics that link to other epics. If so, I
> would
> > > merely like to encourage us to use this powerful expressive means more
> > > often.
> > > >
> > > > Bernd
> > > >
> > >
> > >
> >
> >
> > --
> > Deshi Xiao
> > Twitter: xds2000
> > E-mail: xiaods(AT)gmail.com
> >
>

Re: More Project Structure in JIRA

[Greg Mann]

+1

On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:

> +1 Yes please!
>
> 2015-10-19 16:09 GMT+08:00 Alexander Rojas :
>
> > +1 Yes please!
> >
> > > On 15 Oct 2015, at 10:11, Bernd Mathiske  wrote:
> > >
> > > Proposal: in extension of today’s limited two-level (epic, task)
> > approach, make full use of expressive power already available in JIRA to
> > provide more structure for larger projects to facilitate planning,
> > tracking, and reporting. This will facilitate dynamically planning of
> > sub-projects, which will make us more agile.
> > >
> > > The general idea is to use links between epics to provide a recursive
> > hierarchical structure, with which one can span trees or DAGs of
> > arbitrarily large projects. This does not mean that we want to plan
> > everything in minute detail before starting to work. On the contrary.
> > >
> > > You can start anywhere in the eventual tree and express part of the
> > overall effort, maybe say a short epic with a few task tickets. Then you
> > can LATER make this epic a dependency for a larger effort.
> > >
> > > Conversely, you can subdivide a task in the epic into subtasks.
> However,
> > this does not mean that you have to literally use the feature “subtask”
> in
> > JIRA for this. Instead, staying recursive in our JIRA grammar, so to
> speak,
> > convert the task to an epic and then create ordinary tasks in it to
> > represent subtasks.
> > >
> > > Now the task cannot be a task in its parent epic anymore. We fix this
> by
> > putting in a link of type "blocks" to the parent. When you then look at
> the
> > parent, it still holds a number of tasks, and it has one dependency on an
> > epic (to which you can add more).
> > >
> > > Thus our dependency tree can grow in all directions. You can also
> > rearrange and update it in any shape or form if necessary.
> > >
> > > Overall, we only use two JIRA elements: epics and tasks (of different
> > flavors such as bugs, improvements, etc.). Tasks are the leaves,
> everything
> > else is an epic. Review requests only ever happen for tasks.
> > >
> > > The epics are there to provide a high level view and to allow dynamic
> > (“more agilish”, non-waterfall) planning. Granted, you’d also use a tree
> if
> > you did waterfall. The difference is that you’d spec it all out at once.
> My
> > observation is that not too few of us do exactly this - outside JIRA -
> and
> > then try to remember what tickets are where in their tree. Let’s make
> this
> > part of JIRA!
> > >
> > > Why not use labels? Because they are in a flat name space and we want
> to
> > represent tree structure. How would you know that a label denotes a
> > subproject of another label? By memorizing or by depicting a tree outside
> > JIRA. Why not use components? Same problem as with labels: flat name
> space.
> > We can use labels and components these for many other purposes. Separate
> > discussion.
> > >
> > > Aren’t we doing this already? Probably. I have not checked thoroughly.
> > There may occasionally be epics that link to other epics. If so, I would
> > merely like to encourage us to use this powerful expressive means more
> > often.
> > >
> > > Bernd
> > >
> >
> >
>
>
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com
>

Re: More Project Structure in JIRA

[tommy xiao]

+1 Yes please!

2015-10-19 16:09 GMT+08:00 Alexander Rojas :

> +1 Yes please!
>
> > On 15 Oct 2015, at 10:11, Bernd Mathiske  wrote:
> >
> > Proposal: in extension of today’s limited two-level (epic, task)
> approach, make full use of expressive power already available in JIRA to
> provide more structure for larger projects to facilitate planning,
> tracking, and reporting. This will facilitate dynamically planning of
> sub-projects, which will make us more agile.
> >
> > The general idea is to use links between epics to provide a recursive
> hierarchical structure, with which one can span trees or DAGs of
> arbitrarily large projects. This does not mean that we want to plan
> everything in minute detail before starting to work. On the contrary.
> >
> > You can start anywhere in the eventual tree and express part of the
> overall effort, maybe say a short epic with a few task tickets. Then you
> can LATER make this epic a dependency for a larger effort.
> >
> > Conversely, you can subdivide a task in the epic into subtasks. However,
> this does not mean that you have to literally use the feature “subtask” in
> JIRA for this. Instead, staying recursive in our JIRA grammar, so to speak,
> convert the task to an epic and then create ordinary tasks in it to
> represent subtasks.
> >
> > Now the task cannot be a task in its parent epic anymore. We fix this by
> putting in a link of type "blocks" to the parent. When you then look at the
> parent, it still holds a number of tasks, and it has one dependency on an
> epic (to which you can add more).
> >
> > Thus our dependency tree can grow in all directions. You can also
> rearrange and update it in any shape or form if necessary.
> >
> > Overall, we only use two JIRA elements: epics and tasks (of different
> flavors such as bugs, improvements, etc.). Tasks are the leaves, everything
> else is an epic. Review requests only ever happen for tasks.
> >
> > The epics are there to provide a high level view and to allow dynamic
> (“more agilish”, non-waterfall) planning. Granted, you’d also use a tree if
> you did waterfall. The difference is that you’d spec it all out at once. My
> observation is that not too few of us do exactly this - outside JIRA - and
> then try to remember what tickets are where in their tree. Let’s make this
> part of JIRA!
> >
> > Why not use labels? Because they are in a flat name space and we want to
> represent tree structure. How would you know that a label denotes a
> subproject of another label? By memorizing or by depicting a tree outside
> JIRA. Why not use components? Same problem as with labels: flat name space.
> We can use labels and components these for many other purposes. Separate
> discussion.
> >
> > Aren’t we doing this already? Probably. I have not checked thoroughly.
> There may occasionally be epics that link to other epics. If so, I would
> merely like to encourage us to use this powerful expressive means more
> often.
> >
> > Bernd
> >
>
>


-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com

Re: More Project Structure in JIRA

[Alexander Rojas]

+1 Yes please!

> On 15 Oct 2015, at 10:11, Bernd Mathiske  wrote:
> 
> Proposal: in extension of today’s limited two-level (epic, task) approach, 
> make full use of expressive power already available in JIRA to provide more 
> structure for larger projects to facilitate planning, tracking, and 
> reporting. This will facilitate dynamically planning of sub-projects, which 
> will make us more agile.
> 
> The general idea is to use links between epics to provide a recursive 
> hierarchical structure, with which one can span trees or DAGs of arbitrarily 
> large projects. This does not mean that we want to plan everything in minute 
> detail before starting to work. On the contrary.
> 
> You can start anywhere in the eventual tree and express part of the overall 
> effort, maybe say a short epic with a few task tickets. Then you can LATER 
> make this epic a dependency for a larger effort.
> 
> Conversely, you can subdivide a task in the epic into subtasks. However, this 
> does not mean that you have to literally use the feature “subtask” in JIRA 
> for this. Instead, staying recursive in our JIRA grammar, so to speak, 
> convert the task to an epic and then create ordinary tasks in it to represent 
> subtasks.
> 
> Now the task cannot be a task in its parent epic anymore. We fix this by 
> putting in a link of type "blocks" to the parent. When you then look at the 
> parent, it still holds a number of tasks, and it has one dependency on an 
> epic (to which you can add more).
> 
> Thus our dependency tree can grow in all directions. You can also rearrange 
> and update it in any shape or form if necessary.
> 
> Overall, we only use two JIRA elements: epics and tasks (of different flavors 
> such as bugs, improvements, etc.). Tasks are the leaves, everything else is 
> an epic. Review requests only ever happen for tasks.
> 
> The epics are there to provide a high level view and to allow dynamic (“more 
> agilish”, non-waterfall) planning. Granted, you’d also use a tree if you did 
> waterfall. The difference is that you’d spec it all out at once. My 
> observation is that not too few of us do exactly this - outside JIRA - and 
> then try to remember what tickets are where in their tree. Let’s make this 
> part of JIRA!
> 
> Why not use labels? Because they are in a flat name space and we want to 
> represent tree structure. How would you know that a label denotes a 
> subproject of another label? By memorizing or by depicting a tree outside 
> JIRA. Why not use components? Same problem as with labels: flat name space. 
> We can use labels and components these for many other purposes. Separate 
> discussion.
> 
> Aren’t we doing this already? Probably. I have not checked thoroughly. There 
> may occasionally be epics that link to other epics. If so, I would merely 
> like to encourage us to use this powerful expressive means more often.
> 
> Bernd
> 

Re: More Project Structure in JIRA

[Joris Van Remoortere]

+1 sounds great!
I like the idea of making epics more manageable and the ability to file JIRAs 
based on a design doc while still separating the Epic for the MVP from the 
further phases.

> On Oct 15, 2015, at 10:11 AM, Bernd Mathiske  wrote:
> 
> Proposal: in extension of today’s limited two-level (epic, task) approach, 
> make full use of expressive power already available in JIRA to provide more 
> structure for larger projects to facilitate planning, tracking, and 
> reporting. This will facilitate dynamically planning of sub-projects, which 
> will make us more agile.
> 
> The general idea is to use links between epics to provide a recursive 
> hierarchical structure, with which one can span trees or DAGs of arbitrarily 
> large projects. This does not mean that we want to plan everything in minute 
> detail before starting to work. On the contrary.
> 
> You can start anywhere in the eventual tree and express part of the overall 
> effort, maybe say a short epic with a few task tickets. Then you can LATER 
> make this epic a dependency for a larger effort.
> 
> Conversely, you can subdivide a task in the epic into subtasks. However, this 
> does not mean that you have to literally use the feature “subtask” in JIRA 
> for this. Instead, staying recursive in our JIRA grammar, so to speak, 
> convert the task to an epic and then create ordinary tasks in it to represent 
> subtasks.
> 
> Now the task cannot be a task in its parent epic anymore. We fix this by 
> putting in a link of type "blocks" to the parent. When you then look at the 
> parent, it still holds a number of tasks, and it has one dependency on an 
> epic (to which you can add more).
> 
> Thus our dependency tree can grow in all directions. You can also rearrange 
> and update it in any shape or form if necessary.
> 
> Overall, we only use two JIRA elements: epics and tasks (of different flavors 
> such as bugs, improvements, etc.). Tasks are the leaves, everything else is 
> an epic. Review requests only ever happen for tasks.
> 
> The epics are there to provide a high level view and to allow dynamic (“more 
> agilish”, non-waterfall) planning. Granted, you’d also use a tree if you did 
> waterfall. The difference is that you’d spec it all out at once. My 
> observation is that not too few of us do exactly this - outside JIRA - and 
> then try to remember what tickets are where in their tree. Let’s make this 
> part of JIRA!
> 
> Why not use labels? Because they are in a flat name space and we want to 
> represent tree structure. How would you know that a label denotes a 
> subproject of another label? By memorizing or by depicting a tree outside 
> JIRA. Why not use components? Same problem as with labels: flat name space. 
> We can use labels and components these for many other purposes. Separate 
> discussion.
> 
> Aren’t we doing this already? Probably. I have not checked thoroughly. There 
> may occasionally be epics that link to other epics. If so, I would merely 
> like to encourage us to use this powerful expressive means more often.
> 
> Bernd
>