JIRA. Time tracking and issue workflow

Post on 28-Nov-2014

2.939 views 2 download

description

JIRA. Time tracking and issue workflow

Transcript of JIRA. Time tracking and issue workflow

Time tracking and issue workflow

JIRA. Time tracking

Why do I need it ?

JIRA. Time tracking

Why do we need it ?

JIRA. Time tracking

1. Aims of time tracking

JIRA. Time tracking

- “Ordnung muss sein”

1. Aims of time tracking

JIRA. Time tracking

1. Aims of time tracking- “Ordnung muss sein”

- Flexible timetable report

JIRA. Time tracking

1. Aims of time tracking- “Ordnung muss sein”

- Flexible timetable report

- Overtime calculation

JIRA. Time tracking

1. Aims of time tracking- “Ordnung muss sein”

- Flexible timetable report

- Overtime calculation

- Projects analysis

JIRA. Time tracking

1. Aims of time tracking- “Ordnung muss sein”

- Flexible timetable report

- Overtime calculation

- Projects analysis

- Issue retrospective view

JIRA. Time tracking

1. Aims of time tracking- “Ordnung muss sein”

- Flexible timetable report

- Overtime calculation

- Projects analysis

- Issue retrospective view

- Projects bugdeting

JIRA. Time tracking

2. Dashboards configuration- Start your workday with JIRA personal dashboard

- “Assigned to me” gadget (filter results gadget for QA)

- “Tempo User Timesheet” gadget

- Project activity stream, Saved filters, Quick links and other

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

- Log real time spent on project tasks, not 8h/day.

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

- Log real time spent on project tasks, not 8h/day.

- Log time spent for common issues to “Internal” project (Meetings,

Self-development, etc)

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

- Log real time spent on project tasks, not 8h/day.

- Log time spent for common issues to “Internal” project (Meetings,

Self-development, etc)

- Easy-logging with TEMPO

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

- Log real time spent on project tasks, not 8h/day.

- Log time spent for common issues to “Internal” project (Meetings,

Self-development, etc)

- Easy-logging with TEMPO

- Overtime logging with “Plan time” functionality in TEMPO

JIRA. Time tracking

3. Worktime logging- Workload report for each task is mandatory.

- Log time spent just after sending task to QA or before the workday end.

Next day morning all time has to be logged

- Log real time spent on project tasks, not 8h/day.

- Log time spent for common issues to “Internal” project (Meetings,

Self-development, etc)

- Easy-logging with TEMPO

- Overtime logging with “Plan time” functionality in TEMPO

- Work logging is mandatory for managers, designers, QA, etc: rules are

the same for everyone

JIRA. Issue workflow

1. New issue workflow

JIRA. Issue workflow

2. Issue status- Issue creation: new mandatory fields “component”, “fix version”, “estimate”

- Issue author fills in estimates, developer can modify them if needed, before progress start. In future estimates modification will be tech lead role

- Use “start” and “stop” progress button to notify what task you are working on now.

- No more resolving tasks by developers - that’s a QA or manager function.

- There is no need for reopening and reassigning tasks for developers. Just push it to testing

- QA has to see all issues assigned with “In testing” status

- Task can be closed only by manager

YOU

PS. All the worktime, spent for this presentation was logged to JIRA:)