+1 Yes please!
> On 15 Oct 2015, at 10:11, Bernd Mathiske <[email protected]> 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
>
