Page Comparison

...

As a team we wish to make good use of JIRA to plan, manage and report on work during WIP II, while also allowing a shared view across the core team as well.. The following are some thoughts or insights as to how we might make good/better use of it, with a special focus on the high level analysis phase. I expect we will need to revisit this when we enter the proper development phase.

• JIRA has a simple yet configurable hierarchy for project management. Within a project (the highest level we are using although it can do portfolio management, where a portfolio is a collection of projects) there are issues and each issue has a type. While the standard issue types are Bug, Improvement, New feature, Improvement task, and Custom Issue, these have been modified for our instance to give the issue types of Bug, Epic, and Story.
  
  • Further, each of these issue types can be broken down into sub-tasks, which we are calling 
  • Our configuration allows the creation of a sub-task under an issue under an issue, giving us a three tiered system within a project of Epic, Story/Task/Bug and Project Task
    • The above has been made possible, despite JIRA not allowing sub-task under a sub-task, but it appears a work around, as the linking/breadcrumbs is less than idea. For example, for "Draft 'Experiential learning' page", a project task in CAD, one can clearly see the project and the task in the breadcrumbs, not not the epic (which is not even available in the details section. 
  • All of this said, we can still make the tool meet our needs with the way it works, or modify the settings if necessary. No show stoppers, just useful background understanding.
    
    
    
• Expressing requirements in the user stories format is desirable, as it drives a user focus throughout all activity.
• However, much of the work during this phase does not easily lend itself to a user story, so lets not force it into this form just for the sake of doing so.
• As such, tasks (as the same level as story in JiraJIRA) are likely to be the main "activity container" for this phase, with some of tasks having multiple project tasks underneath.
  • Estimate and log work at the lowest task level available (either project (or sub) tasks where they exist, if not then at the task level.
• We are committed to writing stories and tasks such that they can be started and finished within a sprint (a good habit to form for the development phase for reasons of velocity, motivation, tracking, etc)
• Epics are blocks of larger activity that are larger than a story or task (i.e. will cross multiple sprints). It may be possible to break them down into stories (sometimes down at a latter date) or they may An epic might be a collection of stories (even if not yet broken down) or it might be based on a goal or outcome (improve web ranking by X) that requires time to measure/prove .They may be  than represent a collection of stories and/or tasks (and all the associated project/sub tasks) that either have not yet been broken down into stories (in which case there would be some stories and some "waiting" for the output of the stories to translate in to an outcome.
• Agile theory does not require that all stories/tasks have an associated Epic, but if the team decide that this is desirable we can create epics to hold them. I think this is a good thing to aspire to and suggest we use high level descriptors ideally linked to an output or outcome but we can also use the activity if necessary) .
  • If we do want to map all work to an Epic we will probably also need a general "Other high level analysis tasks" that can have stories and tasks mapped to.

Thinking about all of the above and the team members involved I propose the following Epics - story/task breakdown, at least until the high level analysis is completed. This is an approach and the start but is not yet complete.