Jira Team Project Details vs Company Managed Projects | Jira ACP620 Cert...

Understanding the difference between Jira team managed projects and company managed projects is one of the most important foundational concepts in Jira Cloud. This topic comes up frequently in real world administration and is also tested directly and indirectly on Atlassian certification exams. This video explains how these two project types differ, why certain project details are unavailable in team managed projects, and how this knowledge ties into Jira certification paths such as ACP 120 and ACP 520.

Company managed projects are designed for organisations that require governance, standardisation and central administration. In these projects, administrators can configure project level metadata such as description, category and project URL. These fields are not just cosmetic. Project categories are used for reporting, permissions grouping and portfolio level views. Descriptions help large organisations document purpose, ownership and scope across dozens or hundreds of projects. Custom project URLs support naming conventions and predictable navigation, which is especially important in enterprise environments with compliance or audit requirements.

Team managed projects are built around autonomy and speed. They allow teams to create and configure their own space without needing Jira administrators to manage workflows, fields or screens. Because of this design, team managed projects do not expose description, category or project URL settings. These elements exist at a global configuration layer in Jira Cloud. Allowing every team managed project to modify them would break consistency, reporting integrity and administrative controls across the site. Jira intentionally removes these options to keep team managed projects lightweight, isolated and safe to create at scale.

This distinction is not a limitation but a trade off. Team managed projects prioritise independence over centralised control. Company managed projects prioritise consistency over flexibility. Knowing when to use each is a key skill for Jira administrators, scrum masters and product owners. This decision affects automation scope, reporting accuracy, permission models and long term maintainability of the Jira instance.

From a certification perspective, this topic is especially relevant to the ACP 120 exam, which focuses on Jira administration for Cloud. ACP 120 expects candidates to understand project types, configuration ownership, global versus project level settings, and how these choices affect governance and scaling. Questions often test whether a feature is available in team managed or company managed projects and why. Understanding the reasoning behind these differences helps candidates avoid memorisation and instead reason through scenario based questions.

ACP 520 focuses more on Jira workflows, automation and advanced configuration. While it does not focus as heavily on project metadata, the concepts still matter. Workflow schemes, permission schemes and shared configurations only apply to company managed projects. Team managed projects operate independently. Candidates preparing for ACP 520 must understand how configuration scope changes depending on project type, and why some administrative actions are simply not possible in team managed spaces.

Becoming an Atlassian Certified Professional provides real benefits beyond passing an exam. Certification demonstrates that you understand Jira at a system level rather than just as an end user. It signals credibility to employers, clients and stakeholders. ACP certifications are widely recognised in consulting, enterprise IT, Agile coaching and product management roles. They also provide a structured learning path that helps professionals avoid costly configuration mistakes in real environments.

Certified professionals make better architectural decisions. They know when to use team managed projects for speed and experimentation and when to use company managed projects for scale and governance. They understand the impact of these choices on automation, reporting and security. This knowledge directly improves Jira implementations and reduces long term technical debt.

This video ties these ideas together by explaining not just what Jira allows, but why it behaves the way it does. That deeper understanding is exactly what Atlassian certification exams are designed to test and exactly what distinguishes an Atlassian Certified Professional from a casual Jira user.

How to Set Done Column Time Limits in Jira for Resolved Work Item Issue ...

How to Delete a Jira Ticket #scrum #agile #kanban #jirasoftware #jsm #ac...

Deleting a Jira ticket is something many people assume is simple, but it is actually one of the most controlled actions in the entire platform. Jira treats the removal of a ticket as a permanent and irreversible event. There is no recycle bin for individual work items. Once a ticket is deleted it is gone for good. Because of this Jira only allows users with the Delete Work Items permission to perform this action. If the option does not appear for you it almost always means your permissions do not include deletion.

Every type of Jira ticket can be deleted, including stories, bugs, tasks and even epics. The impact of deleting a ticket depends on what type it is. Removing a story affects sprint velocity and historical reporting. Removing a bug can affect quality trend analysis. Removing an epic breaks the grouping of related work and can make reporting less accurate. This is why many experienced Jira users and administrators strongly recommend avoiding deletion when possible.

Deleting a ticket follows a straightforward path. You open the ticket, select the More options menu and choose Delete. Jira then asks for confirmation because the action cannot be undone. Once confirmed the ticket disappears from the backlog, board, issue search and all reports. The platform wants users to be fully aware that deletion removes all history, comments and attachments associated with the item.

Jira offers several safer alternatives that preserve data while still keeping your workspace organised. One option is to change the status to something like Cancelled or Won’t Do. This tells the team that the work is no longer planned but keeps the full record intact. Another option is to move the ticket to a different Jira space when it belongs somewhere else. This keeps the information available to the right team without disrupting reports.

You can also link or merge tickets that duplicate one another. This prevents clutter without losing important conversations or attachments. Some teams place unused or low priority tickets into a parking lot or holding area so they remain available for future planning. This approach keeps the backlog clean while maintaining visibility of ideas that might return later. When dealing with older or inactive work at a wider scale, archiving an entire Jira space is also possible, although that applies at the project level rather than individual tickets.

Choosing whether to delete or preserve a ticket is an important part of Jira administration. Metrics, sprint reporting and long term product analysis all depend on accurate historical data. Once a ticket is removed those insights disappear. This is why deletion should be considered a final option rather than the default solution to clutter.

Understanding the impact of deletion and the alternatives available helps teams maintain a clean and reliable Jira environment. It also reflects the knowledge expected in Jira certification paths such as ACP 120 and ACP 620. By choosing the right approach teams protect their history, maintain accurate reporting and keep their development process transparent and well structured.

Cameron McKenzie is an AWS Certified AI Practitioner,Machine Learning Engineer,Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel has well over 30,000 subscribers.

How To Automatically Remove Done Work Item Issues on Jira Boards

The Done column in Jira is the final resting place for work items that have completed their journey. When a task, story or bug reaches its final status it moves into Done to show the team that everything required has been finished. Over time though, especially on busy teams, the Done column can fill up with older items. When too many completed issues remain visible the board becomes crowded and it becomes harder to focus on the active work that truly needs attention. Jira helps solve this by giving teams control over how long completed issues stay on the board.

In the board settings you will find an option that lets you choose how long issues remain in the Done column before they fall off the board automatically. Jira allows several timeframes. You can select one week, two weeks or four weeks. There is also a never option for teams that want to keep every completed item visible. Once a timeframe is chosen Jira begins to remove items from the board once they have aged past the selected limit. They are not deleted or archived. They simply disappear from the board view while still being available in searches, reports and the project itself.

This automatic cleanup is especially helpful for Kanban teams. Because Kanban boards do not reset in the same way Scrum boards do at the end of a sprint, the Done column can easily grow and grow. Without automation someone would need to constantly remove old items, which takes attention away from meaningful work. Allowing Jira to manage this keeps the board light, clean and easy to scan. It supports the Kanban principle of keeping attention on the flow of current work rather than on items that were completed long ago.

The process to configure this is simple. In the board settings you open the column configuration or details page and look for the section related to the Done column. There you select how long completed issues should stay visible. Once saved, the board automatically follows that rule. This ensures that the Done column remains useful and tidy without any manual effort. For example, a team that delivers continuously may choose one week so that only very recent work appears. A team that needs more time to review completed tasks may select a longer period. If a team prefers permanent visibility, the never setting keeps everything in view.

This feature improves clarity across the board. During standups the team sees only what matters. During backlog refinement and planning sessions the Done column shows recent progress rather than months of history. Team members are not distracted by long lists of completed issues and can focus on what is still moving through the pipeline.

Automatic removal of completed work items is a small feature with a meaningful impact. It keeps the board accurate, improves visibility and supports a clean workflow. With a simple configuration, Jira helps teams maintain a clear and focused Kanban board without having to manually manage the Done column.

Cameron McKenzie is an AWS Certified AI Practitioner,Machine Learning Engineer,Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel has well over 30,000 subscribers.

How to Block Jira Work Items and Add Blocked By Links Between Issues, Ep...

A manual trigger in Jira is a type of automation trigger that activates only when a user chooses to run it. Instead of firing automatically when an issue is created or updated a manual trigger places full control in the hands of the user. This makes it especially useful for tasks that should not occur on every change but still benefit from automation when the timing is right.

When a rule with a manual trigger is published Jira adds an option inside the issue view that lets the user start the automation. Clicking this option runs the rule exactly as it was designed. This gives teams a safe and predictable way to automate work without worrying about the rule firing at the wrong time. It also lets users confirm that the moment is appropriate before the system makes changes.

There are many situations where a manual trigger makes sense. One common use case is generating subtasks only when a story is ready for development. A product owner or developer can open the issue and run the trigger once they confirm the story is clear and actionable. Another helpful use case is performing cleanup after backlog grooming or sprint planning. A team lead might want to reset fields, adjust priorities or update labels on specific issues. Instead of making each change manually they can run a single manual trigger that performs all of these actions in seconds.

Teams also rely on manual triggers to support consistent processes. If a task requires several steps that must be repeated exactly the same way every time a manual trigger ensures that the process is followed. This reduces mistakes and helps maintain structure within the project. Manual triggers also shine in situations where full automation would be too broad. For example, some issues need extra compliance steps or documentation checks only in special situations. A manual trigger gives the user the ability to start the process only when it applies.

Even with their flexibility manual triggers still share the limits of all Jira automation triggers. Some events cannot act as triggers because Jira does not capture them in a way automation rules can detect. There are also limits on how many components a single automation rule can contain and how often rules can run. Very large or complex automation structures can reach these limits. Manual triggers must also respect user permissions. If the action requires editing or transitioning an issue the automation will not run unless the user has the proper access.

Manual triggers combine the speed of automation with the precision of human judgment. They help teams complete work consistently, reduce repetitive tasks and take action only when the timing is correct. For teams looking to improve workflow quality while keeping control over important decisions manual triggers offer a valuable and flexible solution inside Jira.

Cameron McKenzie is an AWS Certified AI Practitioner,Machine Learning Engineer,Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel has well over 30,000 subscribers.

How to Block Jira Work Items and Add Blocked By Links Between Issues, Ep...

A blocked work item in Jira is an issue that cannot move forward because something else must be completed first. It represents work that is stuck, waiting for another team, another task, an approval or missing information. When an item is blocked the delay affects planning, sprint progress and team flow, so it is important to make the dependency visible. Jira allows teams to do this by linking issues together, giving everyone a clear understanding of what is causing the holdup and who owns the next step.

To show that an issue is blocked, you create a link between the two work items. You open the issue that cannot continue and select the option to link it to another issue. Jira then asks you to choose a link type. If the issue is being blocked, you select the is blocked by link. If the issue is the one causing the blockage for another item, you choose the blocks link. For example, if Issue A must be finished before Issue B can begin, then A blocks B. Once this relationship is created it appears on both issues and becomes part of your workflow. This helps teams react more quickly because blocked work is easy to identify during standups, sprint reviews and backlog grooming sessions.

Jira supports several types of issue links because not every relationship is a blocker. The relates to link indicates two issues share context but do not depend on each other. These links are useful when items involve the same feature, environment or customer outcome and benefit from being reviewed together. This link type does not imply waiting or delay but helps maintain awareness between connected pieces of work.

Jira also offers clone links. Cloning creates a new issue based on an existing one. This is helpful when similar work needs to be repeated in another environment or for a different customer. The clone link shows the connection between the original and the new copy so the team understands where the work came from. Another link type is duplicate. This is used when two issues describe the same request or problem. In these cases one issue is closed as a duplicate and the other remains active. The duplicate link preserves the relationship and keeps the project clean.

By using these link types teams gain visibility into how work items relate to one another. Blocked items become easier to track and resolve. Duplicate items are cleaned up more quickly. Related items stay grouped in a meaningful way. Cloned tasks maintain a clear history. All of this supports faster collaboration and reduces confusion about which issues must be addressed first.

A blocked work item is not just a status problem but a signal that something in the process needs attention. When blockers are visible teams can adjust workloads, communicate with the right people or take corrective action to clear the path. Jira’s linking features allow teams to represent these dependencies accurately so that decision making becomes smoother and bottlenecks can be removed early. By understanding and using blocks, is blocked by, relates to, clone and duplicate links, teams build a system of clarity that helps their projects move forward with confidence.

Cameron McKenzie is an AWS Certified AI Practitioner,Machine Learning Engineer,Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel has well over 30,000 subscribers.

How to Enable Time Tracking in Jira with Original Estimate & Time Remain...

Time tracking and story points in Jira often appear side by side, but they are designed for very different purposes. Story points help agile teams measure the relative effort, complexity and uncertainty of work. They are not based on hours and they do not describe how long something will take. Instead they help teams compare tasks, plan sprints more realistically and understand their overall delivery pace. Time tracking, however, is grounded in real hours. It allows teams to estimate the number of hours a task will take, record the time spent and review how actual work compares to the original estimate.

To use time tracking in Jira, the feature must be enabled by a Jira admin or the space owner. In the site settings there is an issues configuration area where time tracking can be turned on for all spaces. Once enabled, new fields become available on every issue. These include original estimate, remaining estimate and time spent. Users can then log work as they complete tasks and adjust remaining hours so the board always shows an accurate picture of progress.

There are meaningful benefits to using time tracking instead of relying only on story points. Time tracking gives teams a clear and detailed view of how hours are used across the project. Managers can see which tasks consume the most time and whether workloads are balanced across team members. It supports billing when hours need to be captured for clients or cost centers. It also helps with forecasting because actual hours reveal how long similar tasks might take in the future. Story points do not provide this level of operational detail.

Time tracking also strengthens capacity planning. When teams know how many hours they have available during a sprint or week, they can allocate work more responsibly. Logging time also highlights bottlenecks, such as when a particular team member is overloaded or when work items take longer than expected. These insights allow teams to adjust processes, training or resource distribution.

Even though story points and time tracking measure different things they can coexist effectively. Story points help with agile planning while time tracking reveals the real effort behind the work. Together they provide a more complete view of both team performance and individual workload.

Cameron McKenzie is an AWS Certified AI Practitioner,Machine Learning Engineer,Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel has well over 30,000 subscribers.