mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Rojas <>
Subject Re: More Project Structure in JIRA
Date Mon, 19 Oct 2015 08:09:31 GMT
+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
> 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

View raw message