Skip to content

Issue tracker guidelines

ronnil edited this page Feb 20, 2013 · 2 revisions

Project backlog

The project backlog is a special milestone that never ends. The user stories does not need to be tangible yet.

Sprints and sprint-logs

Each sprint is created as milestone with a specific deadline. When the sprint is started tasks are not reassigned from the backlog but is created anew and given estimate and priority.

Tasks

A task is created as an issue. A task must never be without a proper description, priority and complexity estimate.

Task types

Internally we divide the tasks as programming and research tasks. Programming tasks should have a technical description (aimed at the developer) and a user story (aimed at the product owner). Research tasks should have a technical description (aimed at the developer) and a research goal (aimed at the product owner) that describes what the product owner will get as result of the task (usually a report with some contents) and why the task is necessary (what are we able to do after completing this task)

Priority

The task priority is configured by adding one of the labels prefixed with "Priority: "

Complexity estimate

The task complexity estimate is configured by adding one of the labels prefixed with "Complexity: "

Status

The task status is configured by adding one of the labels prefixed with "Status: ". A task is implicitly started by assigning it to a sprint. Tasks are completed by the programmer by marking the task with "Status: resolved".

Checkout

When a task is checked out it is done by assigning the task to a team member.

Bug label

The bug label is a special label so that it fits everywhere. Implicitly the task/story is a feature if not a bug ;)

Done and Done done

Programmers specify when a task is done by labeling it "Status: resolved". The product owner accepts that a task is finished by closing the issue, the task is now "done done".

You can’t perform that action at this time.