Assumptions

• We want to move forward with Jira and Confluence

• Anything we do, we can change later

• Dedicated tools NOW, and learning those tools, outweighs waiting for the perfect structure to manifest itself

Recent realizations

• Everything is an issue of some description, and ties back to a previous “Epic”, in Jiraspeak.

  • Maybe we don’t have documentation of how or why or whose epic, or maybe it was something I did last week that had downstream consequences, but everything we do is attached to something bigger

• “Tickets”/ tts-slate e-mail isn’t an area— in Getting-Things-Done parlance, it’s an Inbox—a place where stuff waits to be added to the workstream as a bug or a task or a story that is part of an Epic.

• Documentation and client training are part of every issue. There is a bigger Training/Outreach/Knowledge Management “Area” in PARA terms, as well, but every issue also includes both.

• Was thinking that we should connect Confluence → Jira but recently realized the big benefit might be pulling Jira into Confluence… Saw some videos where people created pages in Confluence to display high-level info about ongoing projects.

Jira Issue Types

Suggestions for structure

• Jira Projects are the top level; for now, Slate is our one and only top level project.

• Initiatives are the biggest chunks—these are the PARA areas

  • Training/Documentation/Outreach

  • Requested Updates/Development (aka ‘unnecessary updates’)

  • Necessary Updates/Cycle Prep

• Epics, Stories, Bugs, Tasks, and Subtasks are all types of Issues

  • Epics are the things we typically identify as the ‘things we are working on’; examples include setting up data for Marketing dashboard for NUTR, PTCAS 2024 Cycle prep, Cleanup of Dept App query base

  • Bugs are the immediate need this-is-broken e-mails or chats; typically this would roll up to a Cycle Prep Initiative (aka ‘something we didn’t update), but there are use cases for broken documentation.

  • Tasks are the base unit of work, broken down even further into sub-tasks as necessary.

  • Stories are the least clear. It may be the initial client request, or the thing an office wants to do, but we shall see if this really lives in Jira, or works better in Confluence

• There are functional areas in Slate (forms, rules, queries, reports, workflows), which I think are labels in Jira (and in Confluence)

• The instance(s) the work is related to also needs to be tracked somehow

• Thinking about this team as a global provider of services, perhaps also some way to track how this issue is scalable/relates to other instances/aligns with our goals

• For the next two months, it doesn’t seem like we are going to have a lot of time to developing any sort of organized system. I suggest we set ourselves some basic principles, and then work ‘our system’, whatever that looks like, until we can actually spend some time together looking at what works.

  • As much as I hate it, for Jira that probably means not deactivating a billion fields and cleaning up the views, by letting everything ride (and maybe adding more) to find things that capture the sort of data we want.

  • I think Confluence will benefit from us just building pages that work for whatever we are documenting, and over time figuring out how all of the pieces fit together.

    • Make all the labels for everything we can think of in Confluence, and use them all over everything. By August we can pare them down and figure out what actually makes sense. 

    • Learn more about page structure and how it intersects with macros; that is, thinking about how we organize content within a page to maximize its usefulness/adaptability

      • using headings and tables of contents

Suggested Resources

https://youtu.be/5p3QzaS33GA This video really helped me “get” Confluence… it’s long but it covers a lot (and I listened at 2x speed).

https://community.atlassian.com/t5/Jira-articles/Difference-and-use-cases-of-Jira-issue-types-Epic-vs-Story-vs/ba-p/1655157 This article helped me get a better sense of using epics vs. stories vs. tasks.