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
signature.asc
Description: Message signed with OpenPGP using GPGMail
