Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form
Once Frontlog is installed, it does the following things automatically:
On the right-hand side Frontlog adds a panel that contains the following information:
On the top-right side of the Backlog page, next to the Board dropdown, you will see the new Frontlog dropdown that gives you access to the following functionality:
You can also do additional setup to your Backlog screen to make the priority scores more visible.
Cloud version of JIRA has certain limitations when it comes to displaying proprietary data, such as Frontlog's priority score. As part of those limitations, it is not possible to display issue priority scores in the backlog - the priority score can only be seen per issue on the Issue screen.
You can, however, set up card colours to indicate the priority score value.
Since it makes little sense to assign individual colours to every possible score value (1-100), we recommend using a 9-step scale, with examples provided in the table.
Note that the range of the lowest priority step is the biggest since the need to differentiate between the least important issues that usually are at the bottom of the backlog is minimal.
When configuring card colours, select they Query based option and add colour values as per example in the screenshot below.
Feel free to use a different number of steps or your own colour palette. Please refer to this useful resource for colour palette ideas.
The Roles screen can be accessed on the left-hand side navigation on JIRA board (selected in the screenshot below). On this screen you can:
Well written user stories usually follow this pattern:
As a <user role>, I want to <perform a task> so that I can <do my job>
As you can see, a story contains elements such as role, job (or job-to-be-done) and task. For example, in a story "As an accountant, I want to create a report so I can manage company cashflow", we will tag "accountant" as a role and "manage company cashflow" as a job-to-be-done.
Tags are useful because roles and jobs-to-be-done not only make you think about the Who and the Why in your user stories, thus increasing the quality of requirements for your software, but also help prioritise your backlog based on your business decisions to focus on a specific role or its job via setting their relative priorities.
As you write a story title, we parse it through our Natural Language Parsing (NLP) engine, which extracts the tags from the story title. This way you get all your stories tagged without any additional effort.
In those rare cases that our NLP engine gets it wrong, you can edit tags manually.
A role indicates the type of user the new functionality is designed for. Think personas or user segmentation.
Every application has different users. In the simplest case, you have users with an account and users without one. It's easy to see how you would design, e.g. the landing page of your application, differently for these different users - the user without an account is interested in finding out the features and benefits of your product and then potentially sign up for an account, while the user with an existing account would like to get straight to login and start using your application.
More complex applications can have a number of different user roles. Think about an online bank that would have users such as an accountant, a finance clerk, company CFO or an account manager who needs to handle different entitlements for services for roles previously mentioned. Each of these roles will want to use your application to achieve different goals, or perform different jobs, therefore it is very useful to think about functionality and features of your application in terms of who will be using them, and why.
The concept of a job-to-be-done has been developed to empower product managers and designers to create products that help users do specific jobs better. The concept argues that users hire products in order to do a job, therefore designing a product with this in mind helps the product become a valuable tool for the user's specific purpose.
Read more about the jobs-to-be-done (or JTBD) concept here.
Every role has certain jobs-to-be-done that they hire your product or service to help them do. This means that jobs are unique to roles, and a role can have several jobs-to-be-done related to it.
Yes, you can create new roles and jobs-to-be-done.
One way to do it is to simply write new stories. Once a story contains a role or job-to-be-done that hasn't been featured in other stories, these new values are saved and can be seen on the Roles page.
You can also create new roles or jobs-to-be-done directly on the Roles page. Just click on the "+ Add new role" or "+ Add new job-to-be-done" buttons and add the values you need.
Note that job-to-be-done values are unique for every role value, so when creating new jobs-to-be-done, please have the right role value selected.
Yes, you can edit roles and jobs-to-be-done.
If you want to edit the role or job-to-be-done for a specific issue, you can simply edit the story title itself. Once you finish editing, Frontlog will parse the new story title and tag it automatically. If you wish, however, to edit tags manually, you can do so on the Issue screen, in the Frontlog panel on the right-hand side of the page. You can delete a tag by removing the current tag label, and then type to add a new tag. As you type, you will see suggestions of tags used in other stories in your projects. If you want to create a new tag, just type it fully, and you will see an option to save it as a new tag. The new tag value will also replace the old tag value in the story title.
If you want to edit roles and jobs-to-be-done and apply changes to all related stories, you can do so on the Roles page; hovering over a role or job-to-be-done will display an edit icon - click on that icon to initiate an edit dialogue where you can edit the name accordingly.
Please note that if you enter a name that already exists for that context, you will be offered the option to merge the two values. For instance, you had two roles - 'accountant' and 'chief accountant'. Then you decide to edit 'chief accountant' and you delete 'chief'. Because there already is a role called 'accountant', and since you cannot have two roles with the same name, you will have an option to merge these roles into one role.
Yes, you can delete roles and jobs-to-be-done.
If you want to delete the role or job-to-be-done for a specific issue, you can do so on the Issue screen, in the Frontlog panel on the right-hand side of the page - just click on the remove icon on the current tag label.
If you want to delete a role or job-to-be-done for all related stories, you can do so on the Roles page; hovering over a role or job-to-be-done will display a delete icon - click on that icon to initiate a delete dialogue where you can confirm deletion.
Please note that deleting a tag does not remove the tag text from user story title. This means that if you edit the story title and leave the said text, Frontlog will parse the new story title and create a tag again automatically, but only for that individual story.
At the bottom of the Roles page you will see all stories - new, in progress or completed - for a selected context.
You can select a role in the list to see all stories for that role. Selecting a job-to-be-done will show all stories for this job-to-be-done. Clicking on a role again will clear the job-to-be-done selection.
A priority score is an aggregate priority value assigned to each actionable issue type (story, bug, task, etc.). The score is calculated from several criteria. The purpose of the priority score is to help the Product Owner/Manager prioritise the backlog easier with a single and consistent approach.
Backlog prioritisation is a complicated task. When you compare two items in a backlog, you need to consider the following:
This is difficult enough when comparing two items, and becomes ever more complex when applied to the entire backlog. Not to mention the inconsistency of your assessments from one day to another, or even more so across different team members.
Building the wrong thing is one of the biggest challenges a Product Manager faces, so leaving backlog prioritisation to whoever did it last or whatever he/she mood was in is too big a cost.
Frontlog not only allows you to (a) make prioritisation decisions on product strategy level, such as which user role you are focusing on this period, but it also (b) remembers all decisions, such as whether the issue is trivial or critical, that you made for issues individually. By converting all these decisions into numeric values and aggregating them into a single priority score, Frontlog applies those decisions to the entire backlog consistently.
As a result, all items in the backlog have an explicit priority score that provides an aggregate view of smaller decisions about what is important to you.
Priority sliders next to roles and jobs-to-be-done allow you to set relative priorities between them. For instance, if you are just starting to build your application, it probably makes sense that 'user without an account' will be more important than other types of users, as you need to build functionality that would allow your users to sign up. You would then increase the slider value for 'user without an account', which will translate into a higher priority score for all issues related to this role.
At a later time, you might have other roles that become more important, so you would change relative priorities. This would update priority scores for your backlog items and allow you to prioritise the backlog easier.
Scope of impact is a new bug-only value that Frontlog has added to your JIRA instance. The purpose of this value is to indicate the level at which a defect affects your users. The values are:
When you think about it, a bug that affects just a small fraction of your user base, even if it crashes the application for them, may be of lower priority than a less severe defect that affects all of your users. Thus, the value of this selection helps calculate a more accurate and meaningful priority score for your bugs.
A priority score is an aggregate value of individual numeric values that we have assigned to your prioritisation decisions, such as relative priorities for roles and jobs-to-be-done, and explicit JIRA priority values (from trivial to critical).
Each individual value ranges from 1 to 100. By default, each individual value has the same weight in the priority score formula, but these can be changed.
If a role or job-to-be-done is not set, Frontlog uses the average score of 50 to fill the gaps.
A priority score for these issue types is calculated the same way it is calculated for stories. However, since only stories are tagged and can have a role and a job-to-be-done associated directly, we encourage you to link bugs and other issue types to stories, even if they are completed - after all, it makes sense that a bug is raised against a functionality (story) that has already been delivered. This way we link these issue types with a role and a job-to-be-done indirectly, and use that information to calculate a more representative and relevant priority score.
If an issue is linked to more than one story, Frontlog uses the highest value of linked role and job-to-be-done values.
If an issue is not linked to any story, i.e. there is no role and no job-to-be-done, we use the average score of 50 to fill the gaps.
When calculating the priority score for bugs, Frontlog also takes into account the value of its scope of impact field.
We don't calculate a priority score for epics because an epic is a non-actionable issue type and is used in JIRA either as a placeholder (a large story that will eventually be broken down into smaller stories) or as a label-like entity to group stories and other issue types together.
We don't calculate priority score for sub-task issue types. The purpose of the priority score is to prioritise the backlog, and since sub-task move along with their parent issue, we only calculate priority scores for parent-level issue types.
Frontlog can automatically prioritise your backlog. When you think about it, it's very easy - once all issues in your backlog have priority score values, it's just a matter of sorting the list descendingly.
To make it easy for you, we have created a 1-click prioritisation feature. On JIRA Backlog screen, find the Frontlog dropdown (next to the Board dropdown) and select the 'Auto-prioritise backlog' option.
Yes, you can edit priority score formula weights. For instance, if you want the relative priority of your roles to be the most important argument when calculating a priority score, you can increase the value of the priority slider for role thus affecting the final scores.
To access the formula editing dialogue, go to JIRA Backlog screen, find the Frontlog dropdown (next to the Board dropdown) and select the 'Edit priority formula' option.
Your backlog on steroids
.png){kind=small}