CONTENTS. Portfolio. Plans. Scope. Teams. Releases. Reports

Transcription

1 PORTFOLIO FOR JIRA

2 CONTENTS Portfolio Plans Scope Teams Releases Reports

3 Portfolio Portfolio for JIRA is an add-on that leverages the data in JIRA to help you plan and forecast future work. By defining your backlog of work and the team you have available, Portfolio can advise of the most efficient ways to schedule your work and indicate if the proposed release dates fall within your requirements. Plans A plan contains your issues, teams, releases and allows you to calculate your projects' schedule. You can create any number of plans which can be accessed by different users and groups. Plans change and as you gain knowledge and refine remaining estimates, requirements become clearer, things take longer, or are completed faster than expected. Portfolio for JIRA helps you to keep your plans up-to-date by synching them with what actually happened. Having a clear, achievable schedule gives transparency to your team. Knowing what's next helps your team to make better day-to-day decisions, even if plans change frequently. The following sections contain information on how to create and manage a plan. You can see a list of all existing plans (that you have permission to see) under Portfolio > View To create a new plan click Create Plan. 1

4 Now select how you want to choose the scope of work you are planning for. You have 3 main ways of doing this: Connect to a board all issues on that board are included Connect to a project pulls all issues in that project Select a JQL filter for custom issue selection You can connect to multiple sources to create cross-team, multi-project plans. Portfolio automatically pulls in any releases related to the issues you selected above. You can choose to select/deselect any of these. This can be updated later, so don t worry if you are unsure at the moment. 2

5 Portfolio automatically assumes there is a team per board selected. Again, you can update this later. Finally, confirm the issues that you wish to import you can change hierarchy view between epics and stories. 3

6 Scope Live Plans feature a seamless integration with JIRA Software. Every change that happens on the boards and projects you've selected is reflected in your Portfolio for JIRA plan. It also works the other way around; the new "review changes" dialog provides you with a full view of changes that have been made before committing them back to JIRA Software. In addition, the new hierarchy model allows you to create and customize unlimited hierarchical levels. The scope is usually composed of three key hierarchical levels by default: Epics - Once the higher level priorities are settled it's necessary to break them down into large pieces of work, which consist of multiple stories. Stories - User stories capture functionality requirements. Sub-task - Work components that make up stories. Tracking Progress and Status Track the progress of your JIRA application issues directly from your Portfolio plan. When you connect a Live Plan with your boards and projects, Portfolio detects the estimation unit they have: If your items are estimated in hours or days, Portfolio will automatically use the time-based progress tracking. If you estimate your items in story points, point-based aggregation applies. 4

7 If you leave your issues un-estimated, progress is calculated based on the issue s resolution field and the progress of child-issues. Once your plan is created, the progress bar is displayed for individual items, and for parent issues as an aggregate of all their children. You can also check the progress of releases in the release view. Progress Tracking Bar The progress status bar shows the un-estimated issues in relation to items that are estimated. This allows you to see the percentage of work done on estimated items as well as the issues that are still outstanding and require work. Issue Status: It shows the actual workflow status of these issues. Progress: Sum of logged wok on the linked JIRA applications issues, as well as their child elements. When a parent issue is expanded, the bar shows the total progress of all the child stories. Items with no progress are displayed as a faded grey line. Stories that are in progress show the completion percentage as a green line. Completed issues show a full green line. 5

8 Re-prioritising Work Items Portfolio for JIRA lets you easily re-prioritize work items by changing their order in the scope view. The order of work items is taken into account by Portfolio for JIRA's scheduling algorithm; items that are ranked higher will be considered more important, and Portfolio for JIRA will attempt to schedule them before lower ranked items. The orange bar indicates that the item has been reordered. Teams Portfolio for JIRA allows you to add JIRA applications users as team members. You can also work with virtual users that are placeholders to play with what-if scenarios such as, adding a new hire to your team. In your plan you can create new teams and configure them by choosing their scheduling methodology and assigning them tasks. Teams can be plan-specific or shared across plans. Private teams allow you to play around with what-if scenarios and plans that are not formally established. Configuring Team Members Portfolio for JIRA allows you to configure the teams' issue sources, their scheduling methodology and weekly capacity. Go to your plan > Teams. You can change the team name by clicking it and changing it. 6

9 Change a team's issue source by selecting the desired source from the dropdown. You can change a team schedule methodology by clicking the scheduling mode dropdown. If your plan is using story points as estimation method, the Kanban option won't be available. You can define the planning unit following the instructions provided in Configuring plan settings. Configure the iteration length by typing the desired number in the Iteration length field. You can define the default value by following the instructions provided in Configuring plan settings. If you are using time-based estimation: If the team has team members, your team's weekly capacity is a summation of team member's weekly hours. You can set the team members' weekly hours in the field next to each team member. If you are using story points: The team's velocity chart shows forecasted velocity taking into account your team members availability. It also shows the past velocity based on JIRA Software sprints. Click Use suggested velocity to apply the suggested number to the Team velocity field (your team's issue source will have to be a JIRA Software board). 7

10 Configuring Team Members Availability By selecting the team members name, you can select the details for that person. This allow you to set the person s availability to the team. There are a number of options: Add limited Presence like they only work Monday to Thursday Add absence for scheduling upcoming leave, etc. Availability to team number of hours contributing to this team Add exception for times like when other projects demand more of their time, so they have reduced hours for this team. Shared Teams Portfolio for JIRA lets you share teams across multiple plans so you only have to define your teams in one place. This means you can update once for members that work in multiple teams and have vacations planned or limited availability. Shared teams can be accessed from the Portfolio menu: 8

11 Releases Portfolio for JIRA dynamically loads your JIRA Software issues into your plan and suggests releases you can work with. The plan data is always up to date allowing you to track your releases' progress and know if they will be completed on time. Live plans allow you to group project-specific releases into cross-project releases giving you a higher level view of your goals. You can import releases from your JIRA applications projects. You can also create new releases and commit them to your JIRA applications projects. Cross-project releases Cross-project releases are 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 crossproject release. Issues assigned to the cross-project release in Portfolio will be assigned to the respective project-specific release in the issue's JIRA Software project. 9

12 Fixed Date Vs Dynamic Date Depending on the type of release date chosen changes how we use Portfolio to schedule: Dynamic End Dates this is scope-boxed planning, where the proposed release date is calculated based on our backlog of work (including remaining estimates) and the resources (people) we have to tackle it. Fixed End Dates this is time-boxed planning, where the release date is static and Portfolio will calculate if you will meet the target date based on the backlog and people. For dynamic end dates, JIRA Portfolio assumes that the scope is fixed the only items scheduled into the release are those that have a fixed assignment to it. In case of fixed date releases, the scope can either be flexible or fixed, or a combination of both. If it is flexible (i.e. all backlog items have their release assignment set to Calculate), the scheduling algorithm fits in as many backlog items as possible, based on their priority. If both the end date and the scope are fixed, the release will turn into an overbooked status, the only remaining variable are resources. By increasing and decreasing the scope of work and people available, we can propose either expected release dates or propose the scope of work that will get completed. 10

13 Later Release All projects have a "Later release". It's a release pool for all items that have not been assigned to any of the other releases. The Later release has a dynamic end date, depending on the items that are scheduled into that release. It always starts after the last defined release ends. Examples: A fixed end date release is completely filled up, some epics or stories could not be scheduled into it anymore. These get pushed back into the later release. A release with a dynamic end date is defined (let's say release "2.0"), but no backlog items are assigned to it. In this case, it is assumed that these items are not supposed to be in the scope of "2.0", otherwise they would need to have a fixed assignment to it. As a result, backlog items with release set to "Calculate" will get pushed into the later release. No releases are defined at all - in that case everything is scheduled into the later release as well and you see the projected completion date as the end date of the Later release. 11

14 Reports Capacity Reports The capacity report shows how much of a team's potential work capacity is being used. The view provides you with the free capacity, planned capacity and capacity usage per sprint. Capacity Reports The releases 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. Schedule Report The timeline report shows forecasted release dates and allows you to break things down based on projects, teams, team members. 12

15 Epics Stories: Sprint Report The sprints report shows all the sprints in your plan on a per-team basis, its assigned issues and time span. 13

16 Themes Report 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. Themes are concepts used to label and tag backlog elements and are not time-oriented. Themes are focused on relative resource allocation and allow you to compare how many resources you are spending on one theme versus another. A story can only be assigned to one theme, so if the stories within an epic are assigned to multiple themes, the epic is implicitly assigned to multiple themes. Scope Report The scope report shows the global to-do list for the upcoming releases. It is usually composed of three key hierarchical levels by default: Epics - Once the higher level priorities are settled it's necessary to break them down into large pieces of work, which consist of multiple stories. Stories - User stories capture functionality requirements. Sub-task - Work components that make up stories. The new hierarchy model allows you to create and customize unlimited hierarchical levels. 14

17 Next Steps You re now ready to start planning! Remember you can always get help online at Or reach out to GLiNTECH for help with implementation, training, best-practice or licencing. Call one of our experts on (02) or for more assistance or questions. 15