standard_project
If you choose to use standard_project
then it can be inserted at the same place as the project declaration and you can even mix the two styles together if you want to use them both. Under the covers, standard_project
just creates a full project
declaration with a predefined configuration.
Exporter.configure do
target_path 'target'
jira_config 'improvingflow.json'
standard_project name: 'Maple', file_prefix: 'maple', boards: { 1 => :default }
end
This is intended just as a quick way to get started and there is no expectation that this will do everything you want. In fact, we expect that it won’t be long before you decide that this isn’t good enough and you’ll create your own version that does exactly what you need.
Take a look at the source code for standard_project
to see how you could make your own.
Parameter | Description |
---|---|
name |
The name that you’re giving to this project. It will be used in the report but does not have to match any fields inside Jira itself. |
file_prefix |
This is the file prefix that will be used for all downloaded files. This is for your use only and does not have to match to any fields inside Jira. |
boards |
This is a hash of key/value pairs where the keys are the board ids and the values tell jirametrics how to determine the start and end points of every item passing through. Examples of this below. |
ignore_issues |
It’s common that we want to exclude some specific issues from the report because they’re outliers and they skew the data in undesirable ways. This is a list of ids to exclude. Example: ignore_issues: ['ABC123' ,'ABC456'] |
ignore_types |
By default the tool will ignore sub-tasks and epics. This allows you to customize that. Example: ignore_types: ['Sub-task'] . Added in v2.7 |
starting_status |
While it’s highly undesirable to move items back to the backlog, some teams have to do that and so the tool accommodates it. This status is the one that is considered the starting point. If we move back to this, we consider it in the backlog and not started. If we don’t specify this parameter and this is a kanban board, then we use whatever statuses have been configured as backlog for that. Sprint boards don’t have this concept. |
status_category_mappings |
Allows you to specify extra statuses that have been deleted from Jira. Takes a hash of key/value pairs where the key is the status name and the value is the category. |
rolling_date_count |
Set the number of days of history we want to look at |
no_earlier_than |
Restrict how far back we go by specifying one date |
The value passed into boards
is a little more complicated. It might be :default
which assumes that we start the item when it enters the In Progress
status category and stop it when it crosses into the Done
status category. You might think that all boards would be configured that way and yet we find that only about half the boards we work with, do that.
If it’s not :default
then it will be the same hash that you would normally pass into a cycletime
declaration.
standard_project name: 'Sample', file_prefix: 'sample', boards: {
1 => lambda do |_|
start_at first_time_in_status('Refined')
stop_at still_in_status_category('Done')
end
}