Spaces

Promoting Team Autonomy in Planning and Delivery

Jira Spaces are instrumental in promoting team autonomy by providing a dedicated, customisable environment for teams to manage their own processes. Autonomy is fostered through several key features:

• Self-Contained Configuration: Each Space can have its own unique configuration, including custom issue types, workflows, and permission schemes. This means a team can design its own workflow (e.g., from "To Do" to "Done," or something more complex) that perfectly matches their unique delivery process without needing external approval or affecting other teams. This ownership over their working mechanism is a core driver of autonomy.

• Decentralised Planning and Tracking: Within their Space, teams have full control over their backlogs, Scrum boards, and Kanban boards. This allows them to autonomously prioritize their work, scope sprints, manage their capacity, and track their progress in real-time. Team members can move issues between columns, assign work, and log time without waiting for centralized management, leading to faster decision-making and a stronger sense of ownership over the product.

• Transparency and Trust: The boards and reports within a Space provide real-time visibility into the team’s work-in-progress, completed items, and performance metrics (like velocity or cycle time). This high level of transparency builds trust between the team and stakeholders, reducing the need for micromanagement and allowing the team to be accountable for their own outcomes. By defining and controlling how they execute their work within their Space, teams are empowered to plan, track, and deliver products with minimal friction.

Core Configuration Options in a Jira Space

The ability for a team to configure their own Jira Space is the heart of the autonomy we discussed. The degree of configuration available often depends on whether you are using a Team-managed or Company-managed Space, but for a team to fully own its process, here are the key configuration options they can control:

Workflows and Statuses

This is the most critical area for process autonomy. A team can define the precise path an item of work takes from start to finish.

• Custom Statuses: The team can create statuses that exactly match their development stages (e.g., "Ready for Design Review," "In Code Review," "Blocked by Infrastructure").

• Workflow Transitions: They define the specific rules and screens that must be followed to move from one status to the next. For example, a transition from "In Progress" to "Done" might require a "Resolution" field to be filled out. In a Team-managed Space, teams can easily manage these statuses and workflow rules directly from the board settings.

Issue Types and Hierarchy

Teams don't have to be limited to the default "Story" and "Bug." They can tailor the work item types to their needs.

• Unique Work Item Types: A UX team might create an "Inquiry" or "Design Asset" type, while a DevOps team might create a "Maintenance Task" type.

• Sub-Tasks: They can configure whether a specific issue type can be broken down into smaller, traceable Sub-tasks, allowing them to manage granularity as they see fit.

Boards (Scrum and Kanban)

The board is the team's visual planning and tracking tool, and it is fully customizable.

• Column Mapping: Teams can map the columns on their board directly to one or more of their custom workflow statuses, visually representing the workflow.

• Card Layout: They can decide which fields (like Assignee, Priority, or a custom field) appear directly on the issue cards on the board, giving them the data they need at a glance.

• Swimlanes and Filters: Teams set up visual dividers (Swimlanes) to group work by person, Epic, or other criteria, and apply quick filters to instantly see subsets of their work (e.g., "My assigned Bugs").

Custom Fields and Screens

Teams often need specific, unique data points to track their work.

• Custom Fields: A team can create unique fields like "Customer Impact Score," "Compliance Mandate," or "Backend Service Affected," and decide where these fields appear when an issue is viewed or edited.

• Field Layout (Screens): They control which fields are visible and in what order on the issue detail view, ensuring that key information is always prominent.

By controlling these settings, a team transforms a generic tracking system into a bespoke project management tool that perfectly mirrors their reality, which is the ultimate goal of team autonomy in product delivery.

Crucial distinction! 

The difference between Team-managed and Company-managed Spaces in Jira is fundamentally about who controls the configuration and the balance between team autonomy and organisational standardisation.

Here is a breakdown of the two models and how they impact a team's autonomy:

In short, Team-managed gives you immediate and complete control over your space, while Company-managed provides long-term stability and standardisation by centralising that control with the Jira Admin team.