Portfolio for Jira glossary
Use Control + F to find terms within this page
| Backlog | A list of the outstanding features in Jira, which could be for your product, service, project, etc. Backlogs are typically used by Scrum teams, however Kanban teams can also use a backlog of outstanding work items by using Jira's Kanplan feature on Kanban boards. |
|---|---|
| Board | Displays issues from one or more projects, giving you a flexible way of viewing, managing, and reporting on work in progress. There are three types of boards in Jira Software:
|
| Calculate | When any change is made to a Portfolio plan, such as creating new issues or modifying dates, you must click Calculate. This refreshes the visual schedule to reflect the most recent data in the plan. |
| Capacity | Represents the total amount of work a team or team member is able to complete during the length of a sprint. It is based on the number of hours they have available to complete work items in the sprint. |
| Capacity report | Offers a visual summary of the total available capacity and how much of this available capacity is projected to be used by upcoming work. You can filter the capacity report to view capacity by team or team member. |
| Circular dependencies | A circular dependency is created when you have two issues that depend on each other. |
| Completion date | A filter you can use to specify how far back Portfolio should look to include completed issues in your scope table and reports. The completion date filter only works when you have the Status filter set to the default Open and completed issues. |
| Cross-project release | They're used to manage joint releases, dates, and milestones across multiple individual projects. When you create a cross-project release and commit it to Jira Software, the release will be transformed into a regular release in each of the Jira projects that are part of the cross-project release. |
| Custom fields | Custom fields in Jira applications let you add to the built-in fields. They are fields that you can define and add to an issue type. |
| Default velocity | The default velocity is the velocity value Portfolio automatically assigns to teams in your plan if no velocity has been set for them. You can change the default velocity value used by going to the scheduling settings section of your plan configuration. |
| Dependencies | A relationship between Jira issues where one issue blocks or is blocked by another issue. Dependencies can be added to individual issues in the scope table of your Portfolio plan. |
| Dependencies report | Shows a list of all the issues in you plan that have dependent relationships between them. All dependencies between issues are visualized in a simple manner, showing the two affected issues, the type of dependency, and which way the dependency flows. For example, "TIS-17" is needed by "TIS-39". The purpose of this report is to help you manage risk better by having a clear view of all dependencies. |
| Dependency scheduling | A scheduling setting accessed via your plan configuration that defines how dependencies are ranked during scheduling. Given an item, A, that has a lower ranking prerequisite, B. When set to Rank dependent work item below required item, A will be ranked below B. When set to Rank required work item above dependent item, B will be ranked above A. When set to Off, dependencies are highlighted but don't impact the schedule. |
| Dependent story constraint | A setting accessed via your plan configuration. It defines how issues with dependencies will be scheduled by Portfolio. If set to On, work items with dependencies cannot be worked on at the same time.
|
| Dynamic release date | A dynamic release date means your release date will continue to stretch out in time, based on the amount of work in the release and the capacity of your team. Choose this option when you edit your release's 'end' date. Releases with dynamic release dates will never be shown as overbooked in Portfolio. |
| Earliest start date | The earliest start date is a user-specified date that can be added to an issue via a column in the Portfolio scope table. This date informs Portfolio of the earliest possible date the issue can be scheduled to start on, but never before. This date only appears on the issue in Portfolio. |
| Empty release | An empty release is a release in a Portfolio plan that has no issues assigned to it. |
| Enforce concurrent work | Enforce concurrent work is a scheduing setting accessed via your plan configuration. If set to On (default behaviour) and where multiple team members are assigned to a single issue, the scheduling algorithm ensures that all the work for that item is scheduled into a single sprint. If set to Off, individual team members' work can be scheduled whenever there is free capacity, allowing a work item to span multiple sprints. |
| Epic | A very large user story, that is expected to take multiple sprints to complete. An epic is broken down into multiple stories, and is represented as an issue type in Jira. |
| Estimate | Represents the expected effort to complete a Jira issue and can be measured in story points, hours, or days. |
| Estimate conversion | It can be set inside each Portfolio plan, per issue source, allowing multiple Jira issue sources that use different estimate types to be included in a single plan. This conversion aligns all issue sources to a common planning unit, which Portfolio can use to generate an accurate plan. |
| Filter (issue source) | A JQL query which will return all issues which match the query. They can be used to define a specific set of Jira issues which can be added to a plan. |
| Filter (plan view) | Portfolio's plan view filters are simple drop-down filters displayed at the top of a plan. They allow the issues to show in the schedule, scope table and reports to be refined based on criteria including hierarchy level, Jira Project, Team, Releases and by date. |
| Fix Version | A Fix Version is a field in Jira that allows you to add versions. Commonly, this is the version where issue will be resolved or released. Changes to an issue's release assignment in Portfolio will update this field. |
| Fixed release date | A fixed release date means a specific end date has been added, inferring there is a hard deadline for a release. Based on this date, Portfolio can forecast if there is too much work assigned to a fixed release (i.e. the release is overbooked), causing the timeline on the schedule will go red. On the schedule a filled circle will indicated the fixed date and Portfolio's forecasted realistic release date to be indicated by an empty white circle further down the timeline. If the release is not overbooked, the schedule will show as green. If there's too little work, an empty white circle will indicate how soon the assigned work can be done. |
| Global availability | The global availability defines the calendar availability of team members across all teams in a Portfolio plan. |
| Initiative | An initiative is a very large body of work, which spans multiple epics and sometimes, multiple teams. Initiatives can be re-named to match a specific agile framework of an organisation. An initiative is also an issue type in Jira. |
| Issue | An issue is a story, epic, initiative, bug, task or customize issue types that can be created both in Jira or Portfolio. |
| Issue assignee | An issue assignee is a person to whom an issue has been assigned to in Jira. |
| Issue assignee import level | The issue assignee import level is a scheduling setting accessed via your plan configuration. It will define up to (and including) which hierarchy level Portfolio tries to match the assignee of an issue to the same team member shown in the scope table. For example, you may have the Product Manager assigned to an epic, and individual developers assigned to the stories within that epic. In this case, set the issue assignee import level to story and Portfolio will then take the story assignees into account, but not the epic assignees. |
| Issue key | The issue key is a unique identifier. It includes the project key the issue belongs to and an issue number, for example: "TIS-304". |
| Issue source | A Jira board, project or filter is where all the issues in a user's Portfolio plan come from. Any change that a user makes to an issue which is within a connected issue source, for example, create, delete or edit an issue will reflected in their plan when the page is refreshed or reloaded. Any change that a user makes to an issue in Portfolio's sandbox environment (e.g. use the scope table to create, delete or edit an issue) will only be reflected in their Jira issue source once these changes have been committed back to Jira. |
| Labels | Labels can be added to issues to categorize and group related issues. |
| Maximum assignees per story | The maximum assignees per story is a scheduling setting accessed via your plan configuration. It defines the maximum number of people who can be scheduled to work on an individual story. |
| Minimum work package size | The minimum work package size is a scheduling setting accessed via your plan configuration. This configuration defines the minimum work package size for all issues above the story level of hierarchy. This setting prevents free capacities from being filled up with unrealistically 'small' issues, which would not exist once a high level work item is broken down into stories. Set this to the estimate of a typical small story to schedule high level work items as realistically as possible or, set this to 0 intentionally maximize all spare capacity. |
| Original story points / Original estimates | Original Estimates or Orginial Story Points (depending on your estimation unit) is a column that can be added to the Scope Table in your plan. It allows a rough estimate of the amount of work that is needed to get your issues delivered to be added, which you can reference as you break down and provide more detailed story estimates. This field is not used in scheduling. Rather it allows you to compare the accuracy of original estimates with actual, providing teams with data for future long-term planning, so that you can feed these learnings into a team's estimation practices. |
| Permissions | Permissions are a group of settings accessed via your plan configuration. These define who can access your Portfolio plan and whether they are able to edit or only view it. |
| Plan | A Portfolio plan is an aggregated view of the issues, teams and releases for one or more projects in Jira, represented as a data-driven roadmap. Changes to Jira issues can be made in Portfolio, but will only appear updated after a commit has been made from Portfolio. |
| Planning unit | The planning unit defines the estimation type used to estimate issues. In Portfolio, the planning unit used can either be story points, hours or days, and will apply to all issues in a plan. If the planning unit is set to story points, all estimates for scheduling will be read from the Jira Story Point field, estimate totals and planned/available capcities will be displayed and reported in story points. If an issue source is not estimated in the planning unit, apply a Portfolio-only conversion ratio to easily calculate these values. |
| Priority | An issue's priority is represented by its rank. This is a key consideration for the scheduling algorithm in helping to determine which issues are scheduled first. Note: the Jira standard 'Priority' field has no impact on how an issue is scheduled in a Portfolio plan. |
| Project | A Jira Software project is simply a collection of issues (stories, epics, initiatives, bugs, tasks and so forth). You would typically use a project to represent the development work in Jira Software. This could be the work related to a product, a team and so on. |
| Release | A release is a set of features and fixes released together as a single update to your product. In Portfolio, a release can also be viewed as a milestone. |
| Release report | The release report shows all the releases that each project has, including cross-project releases. In the report view, you'll see the release date, progress, and all the associated issues. |
| Reports | The reports section gives you several graphical overviews of the different aspects of your plan. |
| Scenario | A live copy of your current working Portfolio plan that can be used to play with different variables in your plan and compare the outcomes. Multiple scenarios can be created, saved and compared. Note: updating changes in one scenario by clicking Calculate will not affect other scenarios. However, if you commit changes in one scenario, these changes affect all your other scenarios. |
| Schedule | The schedule shows a visual roadmap of all the work items in your plan. It is presented in the upper part of the screen in the Scope, Teams and Releases sections of your Portfolio plan. |
| Schedule report | The Schedule Report is a visual copy of your plan's schedule. It shows a visual roadmap of all the work items in your plan. |
| Scheduled end date | The date Portfolio predicts an issue will be completed by. It is calculated by Portfolio's scheduling algorithm. |
| Scheduled range | The scheduled range is a filter that can be used to only show issues on your roadmap that have been scheduled during a specific time period. |
| Scheduled start | The date Portfolio predicts work will be started on an issue. It is calculated by Portfolio's scheduling algorithm. |
| Scope report | The scope report is a shareable and exportable copy of your plan's scope table. It shows a global list for all the work in your plan. |
| Scope table | The scope table is the lower part of your scope view that displays the core to-do list of your plan. In this section, you can create new issues, add estimates, and view other associated information such as assigned releases. |
| Scope/scope view | The scope, also referred to as "scope view" in the documentation, shows an overview of all the work comprised in your plan. It contains the issues that are pulled from the project, board or filter you used to connect your plan. The scope consists of two main parts: schedule and scope table. |
| Skills | Abilities that team members must have in order to complete specific work items. |
| Sprint | Also known as an iteration, it's a short (ideally two to four week) period in which the development team implements and delivers a discrete product increment. |
| Sprint length | Sprint length is the amount of time assigned for one sprint (i.e. iteration) to be completed. |
| Sprint report | A visual summary of all the current and future sprints for each team in your plan. It shows each sprint's start and end date and lists all issues assigned to the sprint. |
| Stage sprint constraint | A scheduling setting accessed via your plan configuration that controls how issues with assigned stages are scheduled by Portfolio. If set to On, the separate stages of an issue are scheduled sequentially into separate sprints. If set to Off, work on multiple stages can happen in parallel in the same sprint. |
| Stages | Activities that are done sequentially per work item. |
| Status | They're used to represent the position of an issue in its workflow in Jira. |
| Story | A small body of work that represents a product requirement. Multiple stories can be used to make an epic. |
| Story points | A measurement unit expressing an estimate of the effort required to implement a work item. |
| Sub-tasks | A unit of work contained within a story. A sub-task can be created for an issue to either split the issue into smaller chunks or to allow various aspects of an issue to be assigned to different people. |
| Team | A Team in Portfolio is a group of real and virtual Jira users. Portfolio teams are defined by the amount of work they can get done during a given time period. Teams are the resource element of your plan. |
| Team member | A real or virtual user in Jira that is part of a Portfolio Team. Team members can have individual capacity, calendar availability and skills assigned to them. |
| Team-specific availability | The team-specific availability defines the available working hours and dates of each team member for a specific team in a plan. |
| Theme | Themes are high-level strategic focus areas, value streams or investment categories used to set priorities and define where teams will devote most of their time. Assigning themes to issues in your plan is great for stakeholders to see where the organization is spending time vs. what was planned. |
| Uncommitted changes | Uncommitted changes are changes that have been made to issues in your Portfolio plan but haven't been committed back to Jira. Note that Portfolio is a sandbox environment where changes you make to your plan are not reflected in Jira until you decide to commit them back. |
| Unestimated item scheduling | Unestimated item scheduling is a scheduling setting accessed via your plan configuration that defines how unestimated items are handled by Portfolio's scheduler. When set to Base on default estimates, the default estimates defined below are applied to all unestimated childless items of all hierarchy levels. When set to 'Base on target dates', unestimated items will be scheduled to last the duration of their assigned sprint, release, or target dates. When set to Off, unestimated items are ignored and don't impact the schedule. |
| Velocity | Velocity is a measure that shows the amount of work a team can complete during an iteration. In Portfolio, the team's velocity is calculated as an average of the amount of work the team has been able to complete in the past five work iterations. Note: velocity can only be calculated by Portfolio if a board or project has been assigned to the team. Otherwise, the velocity is the default velocity or manually entered value by the user. |
| Virtual User | A virtual user is a non-real user that can be created and added to a team in Portolio. They can be used when testing what-if scenarios to see the impact on a plan of adding real team members. For example, a virtual user with capacity of 40 hours is added to a team to see how much faster an upcoming release could be shipped if a new developer was actually hired. |
| Warning levels | Warning levels is a scheduling setting accessed via your plan configuration that defines whether errors and warnings are displayed in your plan. These can refer to multiple issues such as data conflicts or a plan misconfiguration. |
Last modified on Nov 6, 2018
Powered by Confluence and Scroll Viewport.