Are plans considered fiscal plans? Or individual projects?
A plan can be used at different levels. There is no general rule to using plans – how you use plans would typically depend on how you work. You might make different plans for different programs, create a separate plan for the next quarter, or make plans for a particular set of projects. The only rule is that plans are logically separated, and should not share any data, such as resource availability. This means whenever you need to balance resources between projects and teams, put the data into one plan.
イニシアチブとリリースの機能面での目的は何ですか? どのように Jira プロジェクトに関連するのでしょうか?
An initiative groups epics and stories into larger chunks of work. Initiatives typically span multiple releases, with intermediate deliveries along the way. Business initiatives will typically encompass substantial scope and investment, and will thus likely represent the level of granularity approved by and reported to top management. Initiatives don't have a direct, binding relation to Jira projects. In many cases, the epics and stories grouped to an initiative live in multiple Jira projects. In other cases, all the issues for an initiative might be in one dedicated Jira project.
Is there a separation between dynamic planning and the commitment of changes?
In Portfolio for Jira, you can play with different scenarios before deciding to commit changes back to Jira. The total number of changes made in your scenario is indicated in an orange bubble at the top of your plan.
You can confirm changes by committing them to your Jira application, or discard them by reverting them.
The issue 'x' doesn't appear in my plan
Make sure that:
- the fixVersion field is not hidden for that issue type.
- there are no filters set in the portfolio plan/setup wizard that are excluding it
- the issue is has not been resolved otherwise It won't be visible in the import wizard.
- if you are in plan view, go to More > status > open and completed issues and/or More > status > completion date.
- the issue is not within a release that has been excluded.
- the issue was not manually excluded in the wizard.
Portfolio for Jira doesn't exactly "import" issues, but lets you set projects/boards/filters as an issue source so that any new issue added to those sources from Jira are automatically added to your plan.
Initiatives are still possible to use in Portfolio for Jira. However, due to the new integration functionality, Portfolio for Jira 2.0 requires you to configure new levels of hierarchy, and link the new levels to an issue type in Jira.
Jira Software のスプリントに課題を追加するにはどうすればよいですか?
You can assign issues to a specific sprint in Portfolio for Jira, but it requires a small amount of configuration and only works for "Board" issue sources.
I need to manage a mixture of teams that use Scrum, Kanban, and Waterfall. Can I still use Portfolio for Jira?
Yes, it is possible that some teams work in Scrum mode, and others in Kanban or with traditional methodologies. Common to both modes is that the scheduling algorithm always focuses on finishing individual work items completely before starting new ones. This means that in Kanban mode, when design of a story has started, the first the implementation if it will be scheduled before starting design work on another new feature (unless of course there is sufficient capacity to do it in parallel).
Portfolio for Jira で 1 つのストーリーに複数のユーザーを割り当てることはできますか?
Yes, Portfolio for Jira lets you assign multiple users to the same story. The maximum number of people that can be assigned to a single story is configurable in the settings.
Can Portfolio for Jira suggest the best teams to assign to initiatives based on the schedule?
If you don't assign a team manually, Portfolio for Jira will make an automatic assignment, and suggest the teams who can deliver the work the fastest.
How do you model a release sprint, regression, or stabilization effort inside a release date being calculated?
There are different options to achieve this goal.
- Put a placeholder epic with an effort estimate to represent the stabilization effort. You could size it in such a way that it fills out the capacity for a full time for a sprint. You might have to work with dependencies or an earliest start date constraint to ensure the capacity is reserved only after the other work is done.
- Another approach is modify the start date of the next release to leave a time buffer in-between for example, the subsequent release starting 2 weeks after the end of the previous release.
Any plans for sprint capacity planning? I'd like to know where my resource bottlenecks are during a two-week iteration. Jira doesn't do that natively, and as a result, I have to create a capacity plan in Excel.
Any plans for sprint capacity planning? I'd like to know where my resource bottlenecks are during a two-week iteration. JIRA doesn't do this natively, and as a result, I have to create a capacity plan in Excel.
Portfolio for Jira should be able to help you with that today. It might be a bit counter-intuitive since you work in sprints, but in order to plan exact capacities on a day to day basis you would have to switch the team to Kanban mode (in the people section, team schedule column). You could use releases to represent sprints instead. This will give you a day-to-day plan within your sprints to see how people are allocated.
Does Portfolio for Jira support exporting for reports?
We currently have CSV exports available for the scope and releases. To download a CSV, go to the particular report, and click the export button located on the right.
Please refer to Scheduling and timeline for more information about this topic.