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 project-tasks.
- Our configuration allows the creation of a sub-task 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 JIRA) 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). 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 (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.
| Epic | Story/Task | Sprint |
|---|
| Introduce (at least) F&S stakeholders (i.e. those most impacted, probably content owners/editors) to WIP II | Obtain approval for all HLS documents: Via PMO to give certainty Additional analysis can happen before or after. | 9 |
| | Obtain approval for the horizontal and vertical scope | |
| | Finalise presentation for key stakeholders: Need a version for PMO, senior stakeholders and content owners | 9 |
| | Prepare high level project plan: Showing at least the F&@S coverage over time, probably with key resources blocked in. At this level is it a roadmap rather than a project plan? | 9/10 |
| | Draft content strategies for all HLS and/or global menu areas | 9/10 |
| | Validate user needs: At least those where the business requirements for WIP II assume specific user needs. Could also create an epic for user research and have one task in this phase. | 10 |
| | Brief all senior stakeholders in F&S: MS to prepare the ground so team can meet with content owners. | 10 |
| | Brief stakeholders/content owners in F&S: Introduce our stakeholders to the project (problem, approach, timing, benefits, solution options, etc). | 11 |
| Complete processes/artefacts required to close the initiation/establishment phase | Draft a project purpose statement and an elevator pitch | 9 |
| | Draft success measures and targets | 9 |
| | Establish a RIDS register | 9 |
| | Establish the required project management methodologies (e.g. change, risk/issue, governance, reporting,release, etc.). | 10 |
| | Establish the required reference groups | 10 |
| | Establish the priorities/order of scope, budget, time and quality | |
| | | |
| | Document all know business requirements in epic-story/task forma | 9 |
| | Document all know user requirements in epic-story/task forma | 10 |
| | | |
Thinking about the structure going forward (as per comments from Anne Nelson (Unlicensed) in the task that led to this page I believe we are at a cross road and must decide which way to turn. The two options I see are:
- Epics by main activity group and stories by area of the site where that activity is required: This would give us an epic of "Content Planning" and then for each website area have a story (or more) "Plan content for Postgraduate"; or
- Epics by area of the website and stories by activity for that areas: This would give us an epic of "Modernised Postgraduate hub live" and stories such as "Plan content for Postgraduate hub"