Agile Program Management Tools Overview

Overview

Jira

Jira is project management tool that well integrate with PSKnowHOW application and provides user a seamless experience of managing and understanding the flow of work being done in current and past project iteration/sprints.

Based on the default setting of PSKnowHOW, all of the required fields will be populated. If a user wants to change the default setting, below are some key points to be considered.
SCRUM Dashboard Filters operates on the basis of Sprint and on KPIs, last 5 sprints data are shown.

Iteration Board KPI’s

Iteration board is configured to seek data from different Scrum projects. Based on selected projects and sprint, Iteration KPI’s shall populate with corresponding data points.

^{Points To Be Remember-}
- Only Scrum projects are supported.
- The selected project needs to have at least one sprint available for the KPI’s to show up.
- Any user other than Superadmin shall have access to a Scrum project for data to be displayed on the Iteration board.
- Any update on the Iteration board shall be followed by running the Jira processor from Misc. Settings, subject to availability of new information/data. To know more about the Jira processor, click here.

KPI’s Based on Defects

Defects should be linked to Stories. defects that are not linked with stories will not be considered for these KPI data calculations.
For DSR, the defect should have an identifier discovered on production.
All defects should be linked with a story, even if the story is part of the previous Sprint which has been closed.
Defect status should be reflected via the appropriate stage in the workflow, rather than using comments or using another status.
- Resolved defects should be reflected via their status as done/closed.
- Rejected defects should be reflected via their status as canceled or resolution as configured in PSKnowHOW.
  Similarly, it should be followed for other stages in the defect life cycle like Open, In Progress, In Development, Ready for QA, etc.
RCA drop-down field should be added in the Defect issue type. RCA values drive the info for RCA KPI.
Any Defect/Story being considered to work upon in a particular sprint shall be tagged to same.

KPI’s Based on Test Cases

All Test cases should be linked with a Story (to get In Sprint Automation Percentage value).
if custom fields are used to identify regression and in-sprint test cases, check the custom fields related to it on the setting screen of PSKnowHOW.
Regression KPI can either be set up by Label or Customfield and is not dependent on Sprint.
Only those Test Cases which are to be automated will be considered for calculation and check the corresponding setting.
Test Execution Percentage and Capacity to be updated manually from the settings > upload.

Azure Board

Similar to Jira, PSknowHOW support Azure. Any project that is setup with the application can be configured with either Jira OR Azure.

Functionally Jira and Azure have similar mappings in PSknowHOW and all the KPI’s that originally worked with the Jira tool setup can work with the Azure setup as well.

All the points above for Jira are valid for the Azure tool. Few of Azure specific Guideline/ Limitations are listed below

Area	Behavior	Guideline

Area	Behavior	Guideline
Sprint Status	Last available sprint of the project will show as CURRENT as long as subsequent sprints are not defined, even when the sprint’s end date is out of sync with the calendar date	Projects using Azure Boards must create future sprints in advance to avoid data discrepancies KnowHOW will generate sprint snapshots based on the Sprint Status only, i.e., a sprint will be considered as Active as long as the status is CURRENT in Azure Board, irrespective of the end date of the sprint
Area Path	If workitems are tagged across different area paths and the area paths are not included in the WIQL, KnowHOW will not fetch those as they don’t satisfy the criteria	At KnowHOW, project boards should be configured in such a way that it requires minimal updates
Scope Changes	Daily snapshots are formed at KnowHOW during an active sprint. The final snapshot is frozen on closure of the sprint.	KnowHOW compares the latest snapshot with the previous day’s snapshot to determine the following scope changes Workitems added Workitems removed Snapshot captured on Day 1 of the sprint is considered the Initial Scope of the sprint The sprint snapshots will not get update based on changes that happen after the sprint is completed
Scope Completion		KnowHOW compares the latest snapshot with the previous day’s snapshot to determine the following completed workitems not completed workitems
Spilled issues		Not supported