Customers frequently want to review the monthly processing times of requirements across various requirement types in specific Work-in-Progress (WIP) stages like Developed and Tested, categorizing them into four timelines: under 30 days, under 60 days, under 90 days, and above 90 days. This article addresses this request.
The Spira User Interface allows the indenting of requirements to accommodate the hierarchical thought process people envision in structuring the requirements. When these requirements are documented in a report format, the indentation visible in the user interface is missed. Some customers would prefer to see this indentation replicated in the report. This article addresses this requirement.
Often, the project stakeholders want to assess the effectiveness of the team’s development processes to prioritize tasks and allocate resources more efficiently. This request requires a time series analysis of time taken to get things addressed in the development state. Such a request looks at breaking the time taken (t) into various cohorts, such as under 30 days (t<30), falling between 30 and 60 days (30 < t < 60), falling between 60 and 90 (60 < t < 90), and more than 90 (t>90). This article addresses these requests.
Not all tasks are created equal in a project! Some activities may not contribute to the MVP and will be a "nice to have" rather than "must to have." Therefore, the analysis of tasks within a project may also look at the priority types of the tasks. This article addresses this need.
Not all tasks are created equal in a project! Some activities may not contribute to the MVP and will be a "nice to have" rather than "must to have." Therefore, the analysis of tasks within a project may also look at ideas based on the type of tasks. This article addresses this need.
Sometimes, the analysis of tasks may be associated with both known and unknown releases. Simultaneously, analysis may also involve tasks either associated to requirements within a known release or just stand alone without connection to a release. Furthermore, this analysis may be limited only to the tasks in progress or not started at all. This article addresses how to accomplish this request.
Analyzing tasks is not limited to project releases. Sometimes, tasks may be unassigned to a release further impacting how certain project releases can't even start. So, applying Pareto level (80/20 rule) thoughts can be extended to dig deeper into the tasks. This article helps with this approach.
One of the frequent activities that is monitored in a plan-driven project is the schedule delays due to tasks. This article helps visualizing the tasks across the iterations to evaluate any task delay patterns that can be addressed.
As part of ongoing monitoring of risks, one of the the charts that people monitor is called a risk burn down chart. This article helps with creating a risk burn down chart.
One of the customer asked if it is possible to create a bar chart of the estimated duration and the actual duration of a test case against the owner. This article addresses the requirement.
As part of the risk management lifecycle, frequently people look at risks in the identified, analyzed, evaluated, open, closed and rejected. While this is still a very good way to look at the risk management lifecycle, are there other things to monitor. This article reviews that thought process in depth.
As part of the Risk Management Life Cycle, the Risk Evaluation stage reviews unresolved risks for subsequent analysis. There are many types of risk evaluation that can be done but some of the common ones are evaluating by probability and impact assessment done on the risks. This KB article discusses the approach to evaluate the unresolved risks.
The second stage of risk management lifecycle involves analyzing the risks identified. This involves expert judgement or first level subjective analysis to evaluate which risks are worth spending more time on. This article addresses how to report on such an analysis done.
One of the frequent questions that the product or project teams face is knowing the number of risks across the risk breakdown structure. This risks identified metric not only helps with the team's ability to ensure their commitments are met but also increase the confidence that the product or project team is managing the project effectively. This article addresses how to report this metric.
When the data for creation date, start date, and end date are good, we can aggregate the data in a graphical format. This article will demonstrate how to write a simple query to show the trends of these lagging metrics.
When aggregating lead time and cycle time graphically, it is important to ensure correct data is present in the required date fields that mark the appropriate workflow status required for computing the lead time and cycle time metrics. This article explains how to perform some diagnostics before aggregating data in the graphs using the task module.
One of the frequent questions that the Agile Project teams face is computing the cycle and Lead time. Depending upon the team's practices, this computation may be applied for Requirements, Tasks, or Defects. This article addresses how to create a report for lead time and cycle time based on tasks.
One of our customers recently asked about creating a report that brought the test set, test case, and test step in a specific format to help them with their test planning. This KB article explains how this can be done.
One of the customers recently asked about including a link as an additional column in the tabular report so that it is easy for the receiver to directly access the link instead of navigating through the system. This article provides the query to accomplish this request as part of their query.
In a series of EVM articles, part 1, part 2, and part 3, we discussed about implementing the earned value management (EVM) lagging indicators. In this article, we will discuss the forecasting metrics.
This is the final extension to the Earned Value Management. The main difference here is that the the task module contains the details of the costs that needs to be aggregated and added to the cost of time at the blended rate.
This is an extension of the earlier EVM article on implementing schedule metrics alone. In this article, let us explore adding cost metrics, such as the cost variance and the cost performance index, with summarized costs tracked at the release level.
Recently, an attendee in a conference asked me how Spira can support the earned value management (EVM) for project tracking. The question came up as cost is not part of the standard Spira setup. This article addresses this need.
Spira currently limits the statuses available for the requirement artifact due to the support the requirement status level automation. One request, despite infrequent, is to address how to accommodate excluding requirements at a release level or reporting on requirements in this 'required but currently unavailable' requirement status. This article addresses this requirement.
A customer recently asked how to get a list of all risks across all projects within a portfolio. This article explains how to create such a report.
We had a customer ask recently why this clone option at the release level in Spira did not make a copy of all the artifacts associated in the previous release. This article addresses this question.
A customer recently asked about the impact of turning off the Bulk Edit privilege in Spira. This blog addresses the specific areas this Bulk Edit privilege influences.
A customer recently asked how to format the date format removing the time component in the custom report. This article address how it can be done.
A customer once asked how to create a velocity comparison chart for their Scrum Team to measure planned versus actual velocity across the releases. This article addresses how this chart can be created.
A customer recently asked about creating a custom graph based on a set of values in a custom list on an artifact. This article explains how this can be done.
In one of the training sessions on reporting, a request came up on how data in the XSLT can be sorted similar to ordering results using the ORDER BY clause in ESQL. Both ESQL and XSLT offer its own power which is beyond the scope of this article. But, this article explains a simple way to sort the folders and the tasks in these folders by filtering out the tasks in the root folder and filtering tasks that do not have a name filled in.
A customer had a list of custom properties on the requirement artifact. Some of these custom properties on some requirement had data filled in. When they pulled a report of these requirements, some of these empty custom properties took up much of the report space. So, the customer wondered about reporting only those non-empty custom properties on the artifact. This article explains how this can be achieved.
A customer once asked how to create a list of all test cases that have electronic signature approval recorded. For example, let us say that you have electronic signature turned on for a specific transition operation in the Test Case. Then, how do we create a list of all the test cases that have electronic signature recorded?
This article enumerates the different skills you need to be self-certified at the training course: Rapise iRP-100 fundamentals. The article includes the list of skills in a readable format as well as a downloadable spreadsheet that you can fill out.
This article enumerates the different skills you need to be self-certified at the training course: KronoDesk iKD-100 fundamentals. The article includes the list of skills in a readable format as well as a downloadable spreadsheet that you can fill out.
Please download the spreadsheet and use to help self-certify your skills and competency with our products.