Jira

Purpose / Outcome

Get comfortable moving around Jira so you can always find the right space, board, or work item. The goal is speed: fewer clicks, less confusion, and less time hunting.

• Understand the main sidebar vs in-space navigation.
• Use the “For you” page to resume recent work.
• Star (favorite) spaces/boards you visit daily.
• Use search for work items, then refine with filters.

Where in navigation + Related tabs

This content maps to Jira Cloud’s sidebar navigation and the “For you” experience.

• Related: Work items, Boards/Backlog, Dashboards, Permissions (when you can’t see something).
• When to switch tabs: If you can’t find items, check Permissions & roles.

Mental model / Flow

Think of Jira navigation as two loops:

1. Global loop: pick a space, open dashboards, run saved filters.
2. In-space loop: work through views (board/backlog/list/timeline) and update work items.

Objects & Terms

Key objects you’ll see in this area.

• Sidebar: Main navigation for spaces, filters, dashboards, and starred items.
• For you: A page that helps you resume work you interacted with recently.
• Starred: Your pinned shortcuts for quick access.
• Filter: A saved query that returns a set of work items.

Core jobs-to-be-done

• Open the right space quickly (and avoid similarly named ones).
• Pin the 3–5 views you use most (board, backlog, dashboard).
• Find work assigned to you today using search + filters.
• Share a link to a specific work item or board with a teammate.

Do / Don’t & Pitfalls

• Do: Star frequently used spaces and dashboards.
• Do: Use consistent project keys and prefixes so search is predictable.
• Do: Save filters for common views (e.g., “My open items”).
• Don’t: Rely only on browsing; learn search refinements early.
• Don’t: Share screenshots when a deep link works better.
• Don’t: Assume “missing” items are deleted—often it’s permissions.

What good looks like

• You can open your team board and “My work” views in under 3 clicks.
• You have at least one saved filter for your weekly routine.
• You can quickly tell whether you’re in the correct space.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Set up a fast daily navigation routine.

1. Open “For you” and locate a recently viewed work item.
2. Star your main space and main board/backlog.
3. Create a saved filter for “Assigned to me AND not done”.
4. Use the saved filter and confirm it returns the right items.

Happy path #1 — Set up your daily shortcuts

1. Open your main space and identify the view you use most (board/backlog/list).
2. Star the space and the key view so it stays pinned.
3. Open dashboards you care about and star the best one.
4. Create a saved filter for your personal queue (e.g., assigned to you, not done).
5. Add the filter to your sidebar/favorites (if available).
6. Do a quick test: close the tab and navigate back using only starred items.

Happy path #2 — Find a work item quickly (search → refine)

1. Use global search and type a distinctive keyword from the summary.
2. Open the likely work item and confirm project key and status.
3. If too many results, refine by project/space or assignee.
4. Use history/recents if you viewed it before.
5. Copy the link and share it with the teammate who asked.
6. Optionally, save a filter if you’ll run the same search again.

Decision points

Common mistakes (and how to avoid them)

• Not starring key pages
  Avoid: Star the 3–5 pages you open daily.
• Relying on board scrolling to find items
  Avoid: Use search and saved filters instead.
• Forgetting to confirm project key
  Avoid: Always sanity-check project/space before editing.
• Assuming empty results mean no items exist
  Avoid: Treat it as a permissions or filter issue first.
• Saving too many filters
  Avoid: Keep only the ones you use weekly; delete or rename the rest.

Purpose / Outcome

Configure a Jira space (project) so it matches how your team actually works. You’ll set up views (boards/backlog/list/timeline), structure (components/versions), and navigation.

• Decide space type (team-managed vs company-managed) based on governance needs.
• Configure boards/views your team uses daily.
• Use components and versions to organize work when helpful.
• Keep the space navigation tidy so new users aren’t overwhelmed.

Mental model / Flow

A space is a container with settings and views. Changes you make affect how the team creates and moves work items.

1. Choose the space type (governance decision).
2. Set up the primary board/backlog or list view.
3. Define structure (components, versions/releases) if needed.
4. Review navigation and permissions so the right people can work.

Objects & Terms

Key objects you’ll see in this area.

• Space / Project: A workspace for a team, containing work items, views, and settings.
• Company-managed: Centralized configuration and standardized schemes.
• Team-managed: More team autonomy within the space.
• Component: A way to group work (often by subsystem or area).
• Version / Release: A way to plan and track delivery milestones.
• Timeline: A view to visualize schedule and dependencies at a higher level.

Core jobs-to-be-done

• Create or restructure a space so work is organized logically.
• Set up Scrum/Kanban views and keep columns/statuses aligned.
• Use components to route work to the right group.
• Track releases/versions for shipping and reporting.
• Adjust space navigation to highlight the most-used views.

Permissions & Roles

Space-level access is controlled by Jira permissions and roles. If you’re not an admin, this may be limited.

• Confirm who is allowed to create work items and transition them.
• Use roles to group users (e.g., Developers, QA, Stakeholders).
• Test changes with a non-admin account before announcing.
• If you can’t find permission settings: coordinate with a Jira admin.

Do / Don’t & Pitfalls

• Do: Keep one “source of truth” board per team.
• Do: Align columns with real workflow steps.
• Do: Use components/versions only when the team will maintain them.
• Don’t: Create multiple overlapping boards for the same work.
• Don’t: Rename statuses without explaining what changed.
• Don’t: Change settings mid-sprint without a rollback plan.

What good looks like

• New work lands in a clear inbox/backlog and gets triaged quickly.
• Board columns and statuses stay stable for at least a sprint.
• Components and versions are used consistently (not half-filled).
• Stakeholders can view progress without editing core workflows.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Make a space usable for a new teammate.

1. Open the space and identify the primary view (board/backlog/list).
2. Rename or reorder navigation items so key views are easy to find.
3. Create one component and apply it to a work item.
4. If relevant, create one version/release and assign a work item to it.

Happy path #1 — Configure a team space for daily use

1. Open the space and select the primary view (board/backlog or list).
2. Confirm the workflow statuses match your real process.
3. Set up components if you need routing or ownership by area.
4. Set up versions/releases if you track delivery milestones.
5. Tidy navigation: pin the primary view and hide distractions.
6. Run a pilot: ask a teammate to create and move a work item end-to-end.

Happy path #2 — Add structure without making it heavy

1. List the 2–4 most common work categories your team uses.
2. Create components only for categories with clear ownership.
3. Define a simple version naming pattern (e.g., 2026.02 or v1.4).
4. Update one work item to include component + version.
5. Review with the team and adjust names based on their language.
6. Document the rule: when to use component, when to use version.

Decision points

Common mistakes (and how to avoid them)

• Too many components
  Avoid: Create components only when there is an owner and a clear use.
• Board columns don’t match statuses
  Avoid: Align columns with workflow statuses so movement is meaningful.
• Changing configuration without telling the team
  Avoid: Announce changes and provide a 1-minute ‘what changed’ note.
• Creating duplicate boards for the same work
  Avoid: Define one primary board and archive the rest.
• Using versions but never updating them
  Avoid: Assign an owner and review versions regularly.

Purpose / Outcome

Learn the day-to-day skills: creating, updating, searching, and progressing work items in Jira. The outcome is reliable execution: work items stay accurate and the board reflects reality.

• Create a work item with the right fields (summary, description, owner, priority).
• Progress work through statuses and keep it up-to-date.
• Search and filter to find your queue quickly.
• Collaborate using comments, mentions, and attachments.

Mental model / Flow

Work items move through a workflow (statuses). Your job is to keep the item’s state, ownership, and context accurate.

1. Create work item → clarify scope → assign owner.
2. Plan it (backlog/sprint) → start work.
3. Update progress (status, comments, links).
4. Complete and verify done criteria.

Objects & Terms

Key objects you’ll see in this area.

• Work item / Issue: A task, bug, story, or other trackable unit of work.
• Status: A step in the workflow (e.g., To do, In progress, Done).
• Assignee: Who is responsible for next action.
• Reporter: Who created/raised the item.
• Priority: How urgent or important the item is.
• Work item security: Restricts visibility for sensitive items (if enabled).

State machine / Lifecycle

Typical lifecycle is status-based. Your instance may vary.

• To do → ready to be started.
• In progress → actively worked on.
• In review / QA → verification step (if your workflow uses it).
• Done → meets the team’s Definition of Done.

Core jobs-to-be-done

• Create new work items quickly with consistent formatting.
• Update fields and status so the board is accurate.
• Bulk edit a batch (e.g., set component/version) safely.
• Link related work (duplicates, blockers, parent/child).
• Integrate with dev tools so code and deployments show up on the item.

Do / Don’t & Pitfalls

• Do: Write a clear summary (verb + object) and keep descriptions actionable.
• Do: Keep assignee accurate—one owner for next action.
• Do: Use comments to record decisions and next steps.
• Don’t: Move statuses without updating context (it creates confusion).
• Don’t: Use bulk edit blindly—preview changes first.
• Don’t: Create duplicates; search first and link if related.

Data & Integrations

Work items can carry context from other tools (docs, chats, code). Use this to reduce “where is the info?” messages.

• Link Confluence pages for specs and decisions.
• Enable development information so items show branches/PRs/deployments (if your org uses it).
• Use forms (if available in your space) to standardize intake.
• When sensitive, apply a security level or classification (if enabled).

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Create and progress a work item with good hygiene.

1. Create a work item with a clear summary and short description.
2. Add 2 acceptance criteria bullets.
3. Assign it to yourself and set priority.
4. Move it to “In progress”, add a comment describing your next step.
5. Move it to “Done” and add a final comment with the outcome.

Happy path #1 — Create a high-quality work item

1. Search first to avoid duplicates (keyword + project).
2. Create the work item and write a clear summary.
3. Add a short description and 2–5 acceptance criteria bullets.
4. Set assignee, priority, and any labels/components your team uses.
5. Link related items (blocks/duplicates/parent) if applicable.
6. Save, then share the link with the team if coordination is needed.

Happy path #2 — Progress work item from start to done

1. Move status to the first ‘active’ state (e.g., In progress).
2. Add a comment with your immediate next step (so others can follow).
3. As work changes, update fields (priority, component, due date) rather than leaving stale info.
4. If blocked, link the blocker and add a short note on what you need.
5. When complete, confirm acceptance criteria is met.
6. Transition to Done and record outcome (and links to proof).

Decision points

Common mistakes (and how to avoid them)

• Vague summaries like ‘Fix bug’
  Avoid: Use a summary that names the area and expected behavior.
• Leaving items unassigned too long
  Avoid: Define a triage owner or routine to assign quickly.
• Moving statuses without context updates
  Avoid: Add a comment or update description when status changes meaningfully.
• Forgetting to link dependencies
  Avoid: Use link types (blocks/relates/duplicates) early.
• Bulk-editing without preview
  Avoid: Test on 1–2 items first, then apply to the batch.

Purpose / Outcome

Use Jira boards to plan and track work. Scrum teams typically use a backlog + sprints; Kanban teams focus on continuous flow and WIP. The outcome is a board the team trusts.

• Understand Scrum vs Kanban views and when to use each.
• Use backlog to rank and prepare work.
• Create and manage sprints (for Scrum).
• Keep board columns meaningful and stable.

Mental model / Flow

Scrum loop vs Kanban loop:

Objects & Terms

Key objects you’ll see in this area.

• Board: Visual view of work items moving through columns.
• Backlog: Prioritized list of upcoming work (Scrum).
• Sprint: Time-boxed iteration where work is committed and delivered.
• WIP limit: A cap on how many items can be in progress at once (common in Kanban).
• Epic: A large body of work that groups related items (if your project uses it).

Core jobs-to-be-done

• Groom and rank backlog items so they’re ready to start.
• Create a sprint and move prepared items into it.
• Run daily execution on the board and keep statuses accurate.
• Split work when an item is too large for a sprint.
• Use insights/reports to improve planning and flow.

Do / Don’t & Pitfalls

• Do: Keep columns aligned to real statuses and definitions.
• Do: Groom backlog weekly so sprint planning is fast.
• Do: Use WIP limits (even informal) to reduce context switching.
• Don’t: Move items to Done without meeting acceptance criteria.
• Don’t: Let the backlog become an unreviewed graveyard.
• Don’t: Start too many items at once; finish more than you start.

What good looks like

• Backlog top items are ready (clear scope, owner, dependencies known).
• Sprint has a realistic commitment and finishes mostly as planned.
• Board shows true state; stakeholders can trust it at a glance.
• Blocked work is obvious and acted on quickly.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Run a mini sprint planning exercise.

1. Open your backlog and pick 3 small ready items.
2. Create a sprint and move the 3 items into it.
3. Start the sprint, then move one item to In progress.
4. Complete the item and move it to Done with a brief outcome comment.

Happy path #1 — Groom backlog → plan a sprint

1. Review top backlog items and remove obvious duplicates.
2. Clarify each item’s scope and add acceptance criteria.
3. Estimate or size items using your team’s method (if used).
4. Link dependencies and identify blockers.
5. Create a sprint and pull in only ready items.
6. Set a sprint goal and start the sprint.

Happy path #2 — Daily execution on the board

1. Start with the board: identify what is blocked or aging.
2. Pull the next highest-priority item when capacity frees up.
3. Update status as work moves (avoid stale columns).
4. Add quick comments for handoffs or decisions.
5. Limit WIP: finish items before starting new ones.
6. End the day with board reflecting reality (no ‘secret progress’).

Decision points

Common mistakes (and how to avoid them)

• Backlog never groomed
  Avoid: Set a weekly grooming ritual and keep top items ready.
• Columns don’t match workflow
  Avoid: Align columns/statuses so transitions mean something.
• Overcommitting in sprint planning
  Avoid: Use capacity and past throughput as guardrails.
• Starting too many items
  Avoid: Use WIP discipline; finish more than you start.
• Treating Done as ‘dev done’ only
  Avoid: Use clear Definition of Done and verification steps.

Purpose / Outcome

Turn Jira data into visibility. The goal isn’t more charts—it’s better decisions: spotting scope creep, bottlenecks, and delivery risk early.

• Pick 2–3 reports that match your team’s process (Scrum vs Kanban).
• Create a dashboard for stakeholders (progress without micromanagement).
• Use insights on board/backlog for quick health checks.
• Review metrics on a cadence (weekly is usually enough).

Mental model / Flow

Reporting works best as a loop:

1. Decide the question (e.g., “Are we on track for the sprint goal?”).
2. Choose the right view (report, dashboard gadget, or insights).
3. Interpret with context (scope changes, blockers, holidays).
4. Take one action (adjust scope, swarm, unblock).

Objects & Terms

Key objects you’ll see in this area.

• Report: A prebuilt visualization about work trends (sprints, versions, etc.).
• Dashboard: A collection of gadgets showing real-time info; can be shared.
• Gadget: A widget on a dashboard (charts, filters, summaries).
• Insights: A quick insights view accessible from board/backlog/deployments (where available).

Core jobs-to-be-done

• Create a simple dashboard for your team (My work, Sprint progress, Blocked items).
• Create a stakeholder dashboard (high-level progress, roadmap signals).
• Use insights to spot bottlenecks while planning or executing.
• Share dashboards in Confluence for broader visibility.

Do / Don’t & Pitfalls

• Do: Start with one dashboard and iterate based on questions people ask.
• Do: Use consistent field usage (components, versions) to improve report quality.
• Do: Share read-only dashboards to reduce “status meeting” load.
• Don’t: Use metrics as weapons (it drives bad behavior).
• Don’t: Build dashboards from messy data—fix hygiene first.
• Don’t: Create a dozen gadgets no one checks.

What good looks like

• Team uses dashboards weekly without prompting.
• Stakeholders self-serve status from shared dashboards.
• Reports trigger actions (unblock, re-scope), not debates.
• Insights helps the team spot risk during planning/execution.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Build a tiny dashboard that answers one question.

1. Pick a question: “What is blocking us this week?”
2. Create a filter that finds blocked items (use your team’s convention).
3. Create a dashboard and add a gadget that uses that filter.
4. Share the dashboard with your team (view-only).

Happy path #1 — Team dashboard in 10 minutes

1. Create a saved filter for ‘My open work’ (or a team queue).
2. Create a new dashboard with a clear name (Team — Weekly).
3. Add 3 gadgets: filter results, sprint progress (if Scrum), and recently updated items.
4. Reorder gadgets so the most important is top-left.
5. Share with the team as view-only.
6. Ask one teammate: ‘What’s missing?’ and iterate.

Happy path #2 — Stakeholder visibility without extra meetings

1. Identify what stakeholders care about (delivery date, scope, risk).
2. Create a stakeholder dashboard with high-level gadgets (avoid noise).
3. Include a gadget showing top risks (blocked/aging items).
4. Share it in Confluence so it lives with project context.
5. Review weekly and remove gadgets people don’t use.
6. Use the dashboard in status updates instead of slide decks.

Decision points

Common mistakes (and how to avoid them)

• Using dashboards as vanity metrics
  Avoid: Tie every gadget to a decision/action.
• Sharing dashboards without permissions set
  Avoid: Verify viewers can see the underlying projects and filters.
• Keeping outdated gadgets
  Avoid: Review monthly; delete what’s not used.
• Not standardizing fields
  Avoid: Agree on simple conventions (blocked label, components, versions).
• Reading charts without context
  Avoid: Discuss scope changes and blockers alongside metrics.

Purpose / Outcome

Automation helps your team move faster by handling repeatable steps: assigning, labeling, updating fields, or notifying. The outcome is fewer manual clicks and more consistent process execution.

• Understand core rule building blocks (trigger, condition, action).
• Create one simple rule and validate it with test work items.
• Monitor rule status (enabled/disabled/draft) and audit output.
• Avoid noisy rules that spam people or loop endlessly.

Mental model / Flow

Automation rules follow a predictable structure.

1. Trigger: when the rule starts (e.g., work item created).
2. Condition: checks whether it should continue.
3. Action: what it does (set fields, notify, create item).
4. Branch (optional): apply actions to related work items.

Objects & Terms

Key objects you’ll see in this area.

• Rule: A set of automation steps that run based on criteria.
• Trigger: The event that starts a rule.
• Condition: A check that must be true for actions to run.
• Action: The operation performed by the rule.
• Branch: Runs actions on related issues (parent/child/etc.).
• Audit log: Where you see what ran, what changed, and errors.

State machine / Lifecycle

Automation rules have a simple operational lifecycle.

• Enabled: rule runs when triggered.
• Disabled: rule does not run.
• Draft: changes exist but aren’t published.

Core jobs-to-be-done

• Auto-assign items based on component/label.
• Auto-set priority or due date when a certain type is created.
• Notify a channel when a high-priority item is created.
• Create a follow-up task when an item is transitioned to Done.
• Branch to update child items when a parent changes.

Permissions & Roles

Automation access depends on your Jira configuration and your role. If you can’t create rules, ask a project admin or site admin.

Not applicable for this tool/tab if your role does not allow automation configuration.

Do / Don’t & Pitfalls

• Do: Start with one simple rule and test on a non-critical project/space.
• Do: Add conditions to narrow scope (avoid firing on everything).
• Do: Review audit logs after changes.
• Don’t: Create rules that notify on every small change (spam).
• Don’t: Create circular rules (A triggers B triggers A).
• Don’t: Leave draft changes for weeks—publish or discard intentionally.

What good looks like

• Rules save time and reduce errors (measurable by fewer manual edits).
• Audit logs show consistent successful runs with few failures.
• Notifications are targeted and meaningful.
• Rule owners are known and rules are documented briefly.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Create one safe rule: auto-add a label on new items of a certain type.

1. Create a rule with trigger “work item created”.
2. Add a condition for a specific work item type.
3. Add an action to add a label (e.g., triage).
4. Create a test work item that matches, and one that doesn’t.
5. Review audit log to confirm correct behavior.

Happy path #1 — Build your first automation rule

1. Open automation settings for your Jira Cloud context (project/space or global, depending on setup).
2. Select Create rule.
3. Choose a trigger that matches the event (e.g., item created).
4. Add conditions to narrow scope (type, project, label).
5. Add an action (set field, notify, create item).
6. Save/publish, then test with 2–3 work items and check the audit log.

Happy path #2 — Improve a rule safely (draft → publish)

1. Open the existing rule and note its current behavior.
2. Make a small change (one condition or one action).
3. Keep it in draft and run tests if your setup allows safe testing.
4. Check audit logs after the change for errors or unexpected edits.
5. Publish changes and monitor for a day.
6. If noise appears, disable quickly and iterate.

Decision points

Common mistakes (and how to avoid them)

• Creating rules without conditions
  Avoid: Always narrow scope to avoid triggering on everything.
• Notification overload
  Avoid: Notify only on high-signal events and to the right channel.
• Circular automation loops
  Avoid: Check triggers and actions for feedback loops.
• No rule owner
  Avoid: Assign an owner and document purpose in the rule name/description.
• Ignoring audit logs
  Avoid: Use audit logs to validate behavior and troubleshoot errors.

Purpose / Outcome

Make access predictable and safe. The outcome is simple: the right people can create and move work, and sensitive work stays restricted.

• Understand types of permissions (global, space/project, and work item security).
• Use permission schemes to control space access.
• Use roles/groups to manage membership at scale.
• Troubleshoot access issues systematically.

Mental model / Flow

Permissions are layered. Start broad, then narrow.

1. Does the user have access to the Jira site (global permission)?
2. Does the user have access to the space/project (permission scheme)?
3. Is the specific work item restricted (security level/classification)?
4. Is the action blocked by workflow conditions/validators (if configured)?

Objects & Terms

Key objects you’ll see in this area.

• Global permissions: Controls site-wide abilities (e.g., access to Jira).
• Permission scheme: Defines what users can do in a space/project.
• Role: A named bucket of users used in permission schemes.
• Group: A set of users often managed via identity provider.
• Work item security: Restricts visibility per work item (when enabled).

State machine / Lifecycle

Not applicable for this tool/tab.

Core jobs-to-be-done

• Grant a teammate access to a space/project.
• Allow certain users to transition or edit items (but not everyone).
• Restrict sensitive work item visibility using security levels (if configured).
• Diagnose why a user cannot see or edit something.

Permissions & Roles

Key practices for maintaining permissions safely.

• Use roles in schemes (e.g., Developers, Viewers) instead of individual users.
• Prefer groups for large orgs; prefer roles for per-project assignment.
• Change permissions in small increments and test with a non-admin user.
• Document who owns permission changes (site admin vs project admin).

Do / Don’t & Pitfalls

• Do: Use permission schemes to standardize access across projects when needed.
• Do: Troubleshoot by checking global → project → issue security.
• Do: Keep an audit trail (who changed what and why).
• Don’t: Grant broad admin rights to fix a one-off access issue.
• Don’t: Put individual users everywhere in schemes; it won’t scale.
• Don’t: Ignore issue security/classification when dealing with sensitive data.

What good looks like

• Access requests are handled quickly with a repeatable checklist.
• Projects have consistent roles and minimal “special-case” permissions.
• Least-privilege: users have what they need, not everything.
• Sensitive work stays visible only to approved audiences.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Run a permissions troubleshooting drill.

1. Pick a teammate account (or a test user) with limited access.
2. Attempt to open a project and perform an action (e.g., create item).
3. If blocked, check global permissions then project scheme.
4. Adjust role membership (preferred) rather than granting admin.
5. Retest and confirm only the intended access changed.

Happy path #1 — Give a teammate access to a project

1. Confirm what they need to do (view only vs create/edit/transition).
2. Check they can access Jira at all (global permission).
3. Add them to the right group/role for the project.
4. Validate the permission scheme grants the needed permissions to that role.
5. Have them log out/in (if needed) and retest.
6. Document the change (who, what, why).

Happy path #2 — Troubleshoot ‘I can’t see this work item’

1. Confirm the exact work item key and project.
2. Check whether the user can view other items in the same project.
3. If not, investigate project permission scheme/role membership.
4. If yes, check issue security level or classification restrictions.
5. Check whether filters/boards are hiding it (not a permissions issue).
6. Apply the smallest fix and retest with the user.

Decision points

Common mistakes (and how to avoid them)

• Fixing with admin access
  Avoid: Grant least privilege: role/group membership instead.
• Putting individuals directly in schemes
  Avoid: Use roles/groups so it scales.
• Skipping issue security checks
  Avoid: For sensitive items, verify security level/classification settings.
• Not documenting access changes
  Avoid: Record changes for audit and future troubleshooting.
• Assuming it’s always permissions
  Avoid: Also check filters, board queries, and search scope.

Purpose / Outcome

Protect sensitive information in Jira so only the right people can access it. The outcome is safer collaboration without slowing down everyday work.

• Apply a default data classification level for work items (if available).
• Use work item security levels to restrict visibility.
• Verify access after changes (test with typical users).
• Avoid placing sensitive data in unrestricted fields/comments.

Mental model / Flow

Security is prevention + verification.

1. Decide what is sensitive (and what isn’t).
2. Set defaults to prevent mistakes (classification/security).
3. Apply stricter controls only where needed.
4. Test access and adjust permissions as required.

Objects & Terms

Key objects you’ll see in this area.

• Data classification: A label/level to indicate sensitivity of work items.
• Security level: A setting that restricts who can view a work item.
• Permission scheme: Controls general access; security level can further restrict.

State machine / Lifecycle

Not applicable for this tool/tab.

Core jobs-to-be-done

• Set a default classification for new work items to reduce mistakes.
• Change a work item’s security level for sensitive items.
• Audit and review sensitive work regularly.
• Train the team on where sensitive info should/shouldn’t be stored.

Permissions & Roles

Security settings interact with permissions. If you tighten security, ensure the right roles/groups still have access.

• Identify who must access sensitive items (roles/groups).
• Test access using a non-admin user account.
• Document the rule: when to use a security level vs normal access.
• Coordinate with admins if security schemes are centrally managed.

Do / Don’t & Pitfalls

• Do: Use defaults for classification when possible.
• Do: Apply security levels only when needed (avoid over-restricting).
• Do: Verify access after changes.
• Don’t: Put secrets in unrestricted comments or attachments.
• Don’t: Assume ‘private dashboard’ protects a sensitive work item.
• Don’t: Make security decisions ad-hoc; define a simple policy.

What good looks like

• Sensitive items are clearly labeled/classified.
• Only intended users can view restricted items.
• New users don’t accidentally post sensitive details in public fields.
• Security settings are understandable and documented.

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Secure one work item safely.

1. Create a test work item with non-sensitive placeholder text.
2. Set or verify default classification (if your project supports it).
3. Change the work item’s security level to a restricted audience.
4. Ask a teammate without access to try opening it (or use a test user).
5. Revert or adjust if access is too broad or too narrow.

Happy path #1 — Set a safe default for new work items

1. Identify the common sensitivity level for the project’s work.
2. Set a default classification level for work items (if available).
3. Create a test item and confirm the classification applies automatically.
4. Explain to the team what the labels mean and when to override.
5. Review after a week: are overrides used correctly?
6. Adjust the default if it’s too strict or too loose.

Happy path #2 — Restrict one sensitive work item

1. Open the work item and confirm it contains sensitive context.
2. Set the appropriate security level / restriction.
3. Validate that required roles still have access.
4. Verify a non-authorized user cannot view it.
5. Replace any sensitive content in unrestricted fields with safe references.
6. Document the reason and what was changed.

Decision points

Common mistakes (and how to avoid them)

• Assuming ‘private’ dashboard equals secure data
  Avoid: Secure the work item itself with classification/security levels.
• Posting secrets in comments
  Avoid: Use secure vaults; link references instead of embedding secrets.
• Over-restricting everything
  Avoid: Restrict only what needs it; keep normal collaboration easy.
• Not testing access
  Avoid: Always validate with a non-admin user after changes.
• No shared policy
  Avoid: Write a short guideline: what to classify and when to restrict.

Purpose / Outcome

Plans let you coordinate work across multiple spaces (projects), teams, and releases. The outcome is alignment: a shared picture of scope, timing, and dependencies.

• Create a plan and connect the right work sources.
• Schedule work using sprints, dates, or releases.
• Manage dependencies and capacity signals.
• Share/export plan views for stakeholders.

Mental model / Flow

Plans are an aggregation layer on top of spaces and work items.

1. Add work sources (spaces/projects/boards) to your plan.
2. Pick scheduling model (sprints vs dates vs releases).
3. Review dependencies and warnings.
4. Iterate using views (timeline/list/calendar/program board).

Objects & Terms

Key objects you’ll see in this area.

• Plan: A multi-space planning view that aggregates work items.
• Work source: A space/project/board included in the plan.
• Dependency: A relationship showing work blocked by or related to other work.
• Iteration: Often sprint-based scheduling periods.
• Program board: A view to plan a quarter and manage dependencies at a higher level (if available).

State machine / Lifecycle

Not applicable for this tool/tab.

Core jobs-to-be-done

• Build a plan that includes the right teams and spaces.
• Schedule work items by sprints or dates.
• Track releases across spaces.
• Identify and manage cross-team dependencies.
• Share or export plan data (CSV/image/embed) for stakeholders.

Data & Integrations

Plans often get shared across tools for alignment.

• Embed plans in Atlassian apps (where supported) for visibility.
• Export CSV for offline analysis when needed (avoid making this the default).
• Use consistent sprint/release naming across spaces to reduce confusion.
• Keep plan size reasonable for performance.

Do / Don’t & Pitfalls

• Do: Start with a plan covering 2–3 teams and expand after it’s stable.
• Do: Define a consistent sprint and release calendar.
• Do: Review dependency warnings regularly.
• Don’t: Use plans as a replacement for team-level boards/backlogs.
• Don’t: Ignore performance recommendations and limits.
• Don’t: Schedule everything to the day if your org doesn’t operate that way.

What good looks like

• Teams agree the plan reflects reality (not fantasy dates).
• Dependencies are visible and owned (someone is responsible for resolving).
• Stakeholders use the plan to understand tradeoffs, not to micromanage tasks.
• Plan views answer specific questions (timeline for dates, list for scope, calendar for milestones).

Checklist: Pre-check + Post-check

Practice lab (5–15 min)

Goal: Create a small plan that spans two spaces.

1. Create a plan and add two work sources (spaces/projects).
2. Switch to timeline view and filter to a small scope.
3. Schedule one work item using sprints or dates.
4. Add one dependency between items (if applicable).
5. Save changes and share view with a teammate.

Happy path #1 — Build a small cross-team plan

1. Identify the 2–3 teams/spaces you need to coordinate.
2. Create a plan and add those spaces as work sources.
3. Choose your scheduling approach (sprints or dates) based on how teams work.
4. Use timeline/list view to verify the right work appears.
5. Add/verify key dependencies and assign owners to resolve them.
6. Save changes and share the plan with stakeholders.

Happy path #2 — Quarterly planning with a program board (if available)

1. Prepare: ensure teams have sprints/releases configured consistently.
2. Open the plan’s program board view.
3. Place key work items into target sprints/iterations.
4. Review dependency lines and resolve obvious conflicts.
5. Adjust capacity and sequencing as needed.
6. Publish/share the plan view for alignment.

Decision points

Common mistakes (and how to avoid them)

• Trying to plan the whole org at once
  Avoid: Start small and scale gradually.
• Using plans to micromanage task-level work
  Avoid: Keep plans for alignment; teams run execution on boards.
• Inconsistent sprint/release naming
  Avoid: Standardize calendars and naming across spaces.
• Ignoring warnings and missing work items
  Avoid: Review warnings regularly and fix root causes.
• Overly precise scheduling
  Avoid: Use the right level of granularity for your organization.