Resolving Issues and Logging Work

When a developer starts working on an issue the work will be logged automatically through the use of Start Progress and Stop Progress links.

• A developer should not start progress on a Story, Acceptance Test, or Defect if the issue has not been estimated.

• If a developer is going to stop work on an issue and the issue is not complete the developer should update the estimate. If an issue is not complete it MUST NOT have an estimated time remaining of 0. This makes the issue appear as if there is no more work to be done.

• When a developer resolves an issue with any solution he must make sure the remaining estimate is 0. There should not be estimated work remaining on a resolved issue. This can be updated by editing the issue and setting the remaining estimate to 0.

• Resolving issues should be assigned to the person resolving the issue. The only time this would change is if the issue is being assigned to someone else for followup such as QA

Resolving Issues

A developer may ONLY resolve an issue without comment if the issue is:

1. Complete AND
2. The resolution is Fixed AND
3. The solution is already explained in the issue's description AND
4. The issue was completed in the estimated time AND
5. The issue is not a defect

If an issue does not meet these criteria a developer MUST enter more information.

• If the issue is not complete a developer MUST detail the work done in the comments. This is so a customer or anyone else could look at the issue and tell what the status is or another developer could start working on the issue.

• If a developer has materially gone over the estimated time he MUST explain why in the comments of the issue. This is very important because spending extra time on the issue costs Metova money and costs the customer money. It should be explained while the work is being done. It adds a significant amount of unnecessary work if we have to go back at a later time and figure out why an issue went over if it is not documented in Jira.

• If an issue is resolved with any resolution other than Fixed, a comment must be entered to explain why the issue is being resolved.

• If an issue is resolved as a duplicate it must be linked to the duplicate issue prior to being resolved.

• If an issue is resolved as invalid, add a comment and link to any relevant stories, pages, or other documentation. Examples of an invalid issue would be one that no longer applies due to a change in scope or a defect reported against stories or acceptance tests that are unscheduled and not yet completed.

Defects should not be resolved without a comment. If something is a defect, it should have a description of how it was fixed. This should be a comment on the issue, not the work log.

Resolving an issue as Cannot Reproduce

If information is lacking, it will first be reassigned to the Reporter. Once the correct information is received and if a developer is unable to reproduce an issue, it will be assigned to the project manager to reproduce. If that fails, it will be assigned to a Senior Developer to attempt to reproduce or to hold a code review. Jira issues will not be resolved as "Cannot Reproduce" without going through this process.