We are happy to announce the beta release of historical reports for all On-Demand accounts (with the exception of private clouds, for now).
You can see the basics of how to start using it in the image below.
A full explanation on how to use historical reports can be found in our guide article: How to create a historical report
We will really appreciate your feedback on this beta release of historical reports. What do you like about it? What could be improved? Let us know what you think at firstname.lastname@example.org
Capacity calculation: highly anticipated and finally here! From now on, you can calculate the capacity of each user while planning Releases, Iterations, and Team Iterations. Finally, you will be able to see if a user is overloaded with tasks, or if they can take on more work in this particular iteration.
This will make it so much easier to plan your resources across one or many projects. We didn't forget those who work part-time, or those who are allocated by n% of their time for a particular project and period of time.
Available capacity will be summarized across one or many projects based on:
- Work days in a “work container” (Release/Iterations/Team Iteration)
- Weekly available hours by user
- User allocations, if there are any
Capacity can be calculated for User Stories, Bugs, Tasks and Test Plan Runs. It also works for Initial Estimates for Features and Epics if there are no child entities. In other cases, they will be estimated by the sum of child entities’ effort.
Please keep in mind that effort from Tasks is not included in User Story effort for capacity calculations.
Let’s dig into a few cases and see what it looks like.
Case 1: One Project, no Allocations
This is the easiest way to plan resources if you have one project and don't use allocations.
On Boards where you see cards grouped by users and Releases/Iterations/Team Iterations, you will notice a small box in the right corner of a cell. It shows the assigned effort and capacity of a person:
When you move cards from the Backlog to a Release, the values for assigned effort and capacity are updated:
Based on weekly available hours, we know that John works full-time, 8 hours each day. In August, we have 23 work days, so John’s capacity for July’s Release is 23*8, which equals 184 hours. When we assign a card to John, the system calculates assigned effort and compares it with available capacity.
On the next screen, you can see that John is overloaded for August's Release by 4 hours. It’s already easy to notice whether there is some spare capacity or an overhead. Cells with spare capacity are highlighted green, and cells with overhead are highlighted red.
To check the details of assigned effort and capacity, just hover your mouse over the tooltip in the right corner of a cell:
If some supported cards are not being displayed on a board (perhaps there are some filters applied), and there is some hidden work assigned to you, the cell will show the aggregate sum of all assigned effort, including hidden cards.
If you use points for estimation, you will be able to see the sum of assigned effort for a user in a particular Release/Iteration/Team Iteration, but not the capacity
Case 2: One Project + Allocations
Let’s dig into a case with more than one Project and user Allocations.
John will be allocated to Project Irol System for 40% of his hours, and to Mobile Platforms for 60%.
The John’s capacity for July for Irol System Project was immediately updated, 40% from 184 hours equals 73.6 h
If at least one of the users is allocated to a Project you should allocate others as well. Otherwise their capacity will be calculated on assumption that their allocation is 0%
Case 3: More than one Project + Allocations
Let’s now plan a Cross-Project Release (the scope can include work from one or more projects).
John’s allocations mean that he can dedicate 73.6 hours to Irol System and 110.4 hours to Mobile Platforms (40% and 60% accordingly):
You can click on a few cards and see the sum of their effort. This is especially convenient when moving a few stories from the backlog!
If you have more than 500 cards in one cell, Effort will be calculated by the first 500.
If you estimate work entities in points, capacity will not be updated. Capacity is calculated in hours only.
Case 4: Team Iterations
As you know, Teams and Team Iterations can be assigned to multiple Projects. Just keep in mind that Capacity and Assigned effort will be calculated based on work that is included in a particular Team Iteration, not based on all Projects to which a Team is assigned.
When Releases/Iterations/Team Iterations begin, their capacity value will be regularly updated based on the remaining amount of work days
As many of you know, searching for data in Targetprocess can sometimes be more time consuming than expected. Since we would all like to save some time (and search more effectively), we have reworked our global search to make it faster and more reliable.
We plan to start rolling out this new search for customers in the near future. It will be enabled gradually, because it will take some time to re-index all the data. In this regard, the new search will not be immediately available for everyone. Stay tuned. After passing all the checks, we will turn it on for every account.
Search engine replacement
Let me unveil the main change we've made to search. We deprecated our old search engine and built a new one from scratch using Elasticsearch. We chose Elasticsearch because they are a leader in the search engine market. Their engine allows us to improve results for common search tasks, such as relevant search, filtering, aggregation, etc. Replacing the old engine with a mature one simplifies any development related to search, allowing us to move faster. It will now be much easier to implement new features, such as searching by attachments, advanced filtering, and custom orderings.
Relevance of search results
As with many full text search engines, results in Elasticsearch are ordered by relevance by default. We followed the same direction, so search results in Targetprocess will now be ordered by relevance. But, as usual, the devil is in the details.
Relevance algorithm (for those who are hungry for details)
Elasticsearch uses the Term Frequency/Inverse Document Frequency (TF/IDF) algorithm for scoring document relevance.
Once we have a subset of matching documents (entities in our case), they need to be sorted by relevance. Some documents contain all the terms, while others don't. It's important to note that some terms are more important than others. The relevance score of the whole entity depends on the weight of each query term that appears in that document.
So, relevance score is determined by three factors:
1. Term frequency. How often does the term appear in this document? The more often, the higher the weight.
2. Inverse document frequency. How often does the term appear in all documents in the collection? The more often, the lower the weight.
3. Field-length norm. How long is the field? The shorter the field, the higher the weight.
Results view redesign
First, you will notice the redesigned search results view. We tried to make it more visual. Comments now are shown in search results (if you search for keywords found inside them) in a tree-style manner. This makes the search results view more consistent with our entity details view, and makes it easier to quickly scan through results. Any keywords found are highlighted, both in comments and entity fields.
Moreover, if the searched keywords are found in Custom Fields (which are all searchable now), they are also highlighted on the results view.
We've also taken some steps to improve the user experience of anyone who uses the QA area in Targetprocess. From now on, when searched keywords are mentioned in test steps, they will appear in the test case result view in a tree-style manner, similar to comments.
Thanks to the changes mentioned, the results view has become more informative and allows you to easily recognize the entity you wanted to find. If the displayed meta data isn't enough, you can open the entity details view by clicking on either the 'Name' or '#ID' of the entity. Due to the fact that we improved navigation back to the search results (they are actually cached), it's now extremely fast and should save a bit of time.
Search by itself just got better. But what if your searched keywords yield too many results, and you cannot find what you're looking for? Sure, you can go through all the pages and eventually discover what you wanted to find, but there should be a better way. For this, you can use filters.
Filters allow you to narrow your search results. You can find the filters area to the left of the result list on the search view.
In many cases you are interested in only one or several types of entity. For this, you can just use the 'ENTITY TYPE' filter and only desired type of entities will be searched among. The filter allows you to select one, several and all types and even have it's own search for faster navigation to the target type.
If you know which states your target entity could be in, use the 'ENTITY STATE' filter, which is identical to the type filter functionality.
It's worth mentioning that type and state filters are dependent on each other. Once you select some types, you can only choose states that are relevant for the for the selected types, and vice versa.
In some other real situation, you may want to find entities that are either hot (were created during the past month) or completely archaic. Just use the brand new 'CREATE DATE' filter. It signals search to take into account only entities that were created during the selected period.
As it was before, the 'All Projects and Teams' checkbox is still present in the filters area and available for usage. It is now enabled by default. Uncheck it to search through currently selected Projects and Teams. Otherwise entities from all Projects and Teams available for you will be considered. We assume that global search should behave globally by default, while narrowing should be an option, not a preset setting.
We did our best to make search relevant and useful right out of the box. In most cases, you won't need to take any steps beyond writing several keywords in the search input. If needed, search can be fine-tuned to solve the most exacting cases. These are cases where the advanced grammar of search can help you get things done. The following table describes a bunch of special characters which can be used in the search input:
|+||big + elephant|
"big elephant" + "small giraffe"
|Signifies AND operation. Searches for entities with both words included (or for phrases, if enclosed in quotes).|
||||elephant | giraffe||Signifies OR operation. Searches for entities with at least one of these words included.|
|""||"Exact phrase"||Exact match. Finds all entities which contain the exact phrase from the search query.|
|*||eleph*||Search by prefix. Finds all words starting with 'eleph' (slows down searching significantly!).|
|After a word, this signifies edit distance (fuzziness). Suppresses emphasizing of mistakes on the search string (slows down searching significantly!).|
After a phrase, this signifies slop amount. Allows other words to appear between words in the phrase (slows down searching significantly!).
Global Search scans the following fields of Targetprocess entities: 'Name', 'Description', and text from all 'Custom Fields'. Searching by Tags, Time Descriptions, and Attachments is not yet supported yet, nor is searching through entities in inactive Projects.
Compared to the old search, we have added a couple of new search sources. So, it's now possible to search among Projects and Teams.
Added private and pinned comments for Requests
You can now mark comments on Requests as private, or pin them to the top of the discussion. This is mostly designed to improve the Service Desk experience. You can read more at this dedicated blogpost.
Visual Reports: Changed Formulas Editor
We have disabled the ability to save invalid and previous versions of graphical report formulas. Find out more at this dedicated blogpost.
We really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at email@example.com
Deprecating TestTrack integration
The TestTrack integration plugin will be no longer supported. You can find out why at this dedicated blogpost.
- Fixed: duplicate notifications were sent when mention user and workflow notifications were ON
- Fixed improper word wrapping in comments
- Fixed time recalculations for parent entities when time is changed for any related entities
- Fixed an exception that would happen when unlinking a Bug from a Test Case Run
- Fixed: failure to send notifications configured for a Project entity (such as a state change or an added comment)
- Fixed incorrect printable view for custom reports
- Non-admins can now assign a Team to a Project using Quick Add
- Added the ability to open Process setup and Settings in a new tab