Documentation/ConfigurationOptions

Configuration Options

You may configure your Agile-Trac install by adding options to the conf/trac.ini file.

Adjusting the Normalised Progress Bar Width in the Roadmap

Adding this entry to your conf/trac.ini file allows you to control how wide the progress bar can be before it is increased in height. The area of the progress bar is the total number of points in the milestone. The default value is 200. You could set it to 100 by adding the config entry below.

[agile-trac]
normalised_progress_width = 100

Ignoring past Iterations that will skew future date calculations

You may ask Agile-Trac to ignore iterations that ended before a certain date. This is useful if, for example, your team size changed from 2 to 6 developers overnight and you wanted 'reset' the iteration completion rate history. This is important when you want quick feedback to stakeholders over the impact that the new team is having. The date format expected is the same as that expected in your trac install for entering iteration dates into an iteration itself. For example you might write this.

[agile-trac]
ignore_iterations_ending_before = 20/03/09

Determining how past Iterations are used to Calculate Points Per Iteration

By default agile-trac uses the currently completed portion of the current iteration plus the previous 4 iterations to determine the Points Per Iteration value that it uses to calculate the expected completion dates. You can override this default behaviour by adding an historical_iteration_weights entry to the [agile-trac] section with a space separated list of weights. It should be noted that:

  • The number of weights will be equal to the number of iterations considered when determining the Points Per Iteration.
  • The weights are ordered from current to oldest.
  • You may use floating point numbers.

For example the default behaviour can written as:

[agile-trac]
historical_iteration_weights = 1 1 1 1 1

If you wanted more recent iterations to have more of an impact on the calculation of the Points Per Iteration and you also wanted more iterations to be taken into account you might choose set this value as follows:

[agile-trac]
historical_iteration_weights = 10 7 4 2 1 1 1

To minimise the impact of the extremities you might use:

[agile-trac]
historical_iteration_weights = 1 3 5 7 4 2 1

Adding an 'Overview' to Iterations

It is possible to add an optional generic overview section to iterations. This will appear on both the iteration summary table and individually on each iteration. One purpose of this is to allow the easy association of wiki pages to an iteration. For example you might add the following entry to your trac.ini file.

[agile-trac]
iteration_overview_template = [wiki:iteration/$iteration.id/planning Planning] [wiki:iteration/$iteration.id/evaluation Evaluation]

With the previous entry a column will be added to the to the iterations summary table called Overview which will contain 2 wiki links, one to a planning page and one to an evaluation page for the iteration.

Customising Completion Stages

When agile-trac is first installed the three completion stages are defined under the ticket-completion section of the trac.ini file:

  • test_complete
  • doc_complete
  • acceptance_complete

This is shown below.

[ticket-completion]
test_complete = 
test_complete.label = Test Complete
test_complete.order = 1
test_complete.short_label = Tested
doc_complete = 
doc_complete.label = Documentation Complete
doc_complete.order = 2
doc_complete.short_label = Documented
acceptance_complete = 
acceptance_complete.label = Acceptance Complete
acceptance_complete.order = 3
acceptance_complete.short_label = Acceptance

It is possible to define your own completion stages using the format shown above.

It should be noted that when you change your completion stages no entries are removed from the ticket_completion table in the database, so this is non-destructive. It should also be noted that lazy insertion is used so no entries are added to the ticket_completion table for a ticket unless that ticket is changed. If there is no entry found for a given ticket for a given stage then the default sizing is assumed, which is undefined.

Here are some examples:

Example 1

  • started
  • builds_and_tests_pass (equivalent to test_complete)
  • doc_complete
  • qa_complete (perhaps approval from QA is all that signifies completion)
[ticket-completion]
started = 
started.label = Started
started.order = 1
started.short_label = Started
builds_and_tests_pass = 
builds_and_tests_pass.label = Builds and Tests Pass
builds_and_tests_pass.order = 2
builds_and_tests_pass.short_label = Build Pass
doc_complete = 
doc_complete.label = Documentation Complete
doc_complete.order = 3
doc_complete.short_label = Documented
qa_complete = 
qa_complete.label = QA Complete
qa_complete.order = 4
qa_complete.short_label = QA

Example 2

The following completion stages might be required in the order shown,

  • build_complete
  • presentation_complete
  • qa_complete
  • acceptance_complete

The appropriate [ticket completion] entry in the trac.ini file is as follows:

[ticket-completion]
build_complete = 
build_complete.label = Build Completed
build_complete.order = 1
build_complete.short_label = Build
presentation_complete = 
presentation_complete.label = Presentation Completed
presentation_complete.order = 2
presentation_complete.short_label = Presentation
qa_complete = 
qa_complete.label = QA Complete
qa_complete.order = 3
qa_complete.short_label = QA
acceptance_complete = 
acceptance_complete.label = Acceptance Complete
acceptance_complete.order = 4
acceptance_complete.short_label = Acceptance

Example 3

A single stage might be all that is required, for example,

  • complete

The entry required would be:

[ticket-completion]
complete = 
complete.label = Completed
complete.order = 1
complete.short_label = Complete