Functional overview
Typical use case
The nominal use case is to setup a Scrum Dashboard that should provides high level indicators but for a team that doesn't practice (yet?) estimations. They will create Stories, some of them will be split in tasks and we want to have some indicators about effort / velocity / etc. Everything will be computed out of number of cards, workflow post actions and triggers.
Stories have
- Initial effort (computed field, default value: 10)
- Remaining effort (computed field, default value: 10)
Tasks have:
- Initial effort (float, default value: 1)
- Remaining effort (float, default value: 1)
The team populate the top backlog with 3 stories:
- Story A: initial effort 10 (default value), remaining effort: 10 (default value)
- Story B: initial effort 10 (default value), remaining effort: 10 (default value)
- Story C with 2 tasks: initial effort: 2 (sum of tasks default values), remaining effort: 2 (sum of tasks default values)
Then they Create a new release 1.0 and assign the 2 stories to it:
- Release 1.0 initial effort: 22 (sum of the 2 default values + autocomputed), remaining effort: 22
- The burn-down initial value should be 22
- The burn-up total effort should be 22
During the life of the iteration:
- When Story A is completed, the burn-up line climbs-up to 10 (default value)
- Burn-down will only change when story C is modified
- When a task will be closed, due to workflow post actions, the line will drop by 1 (remaining effort from 1 to 0)
- Without a manual intervention, when story A or B will be done, the line won't move (remaining effort still with default value)
Functional details
As a tracker admin, In tracker admin fields usage, "Computed" fields can now have a default value.
This default value can be empty (no value) or any float value.
When a default value is configured, any new artifact will have a manual value set to the default value. In order to switch from the default value to the autocomputed, the user will have to:
- Add new linked artifacts (otherwise autocomputation is meaningless)
- Explicitely switch from "Manual value" to autocomputed (like any other manual values)
Rational behind the default value as manual value
The default value must be managed as a "Manual value" (as opposed to a "faked" autocomputed) for several reasons:
- From a user point of view the history record is clear. The initial value was set to X (default value, manual) and at some point it was decided to switch to autocomputed, the history trail is clear, easy to understand.
- As a side effect, its also easier for the user (and for the support team that will have to answer the question) to undersand how the various graphs (brun-up, burn-down, velocity) are computed. It might already be a bit complex to get it (due to the fact that it takes into account the historical values), when the magic of default + autocomputation is added, it will be impossible to tell if a point in the graph was accurate or not.
- From a technical point of view, we don't have the mean to "connect" the update of 2 fields that would be required here (the update of artifact link under some condition should toggle the default value of another one).
- We don't have to manage the following use case:
- Artifact is created (default value applies)
- A link is added (default value is gone, computed value is used)
- The link is removed => what should we have