Task Life Cycle

Question

What task life cycle do you follow? and do you mingle tasks and bugs together in the tool you use? A typical Task life cycle is:

• Not Started - entered but not yet started
• In-Progress - being worked on
• Complete - task is done with the exception statuses of:
• On Hold - waiting for something
• Canceled- the task is no longer needed, possibly due to a change in requirements.

The typical bug life cycle could be:

• New - newly entered
• In Progress - being worked on
• QA - going through test
• Client Review - fix being reviewed by the client
• Ready for Promotion - ready for the next release
• Complete - released into production with the exception statuses of:
• On-Hold
• Duplicate Not Reproducible
• Works as Designed

What's your life cycles?

Answer 1

Actually, we manage to have one life cycle for different kind of tasks

• Open
• Working
• Rejected
• To Be tested
• Resolved
• Close

That apply to our tasks based on ITIL (set of concepts and policies for managing information technology (IT) infrastructure, development and operations.):

• case
• change
• dependency (regroup several changes)
• release (regroup several dependencies)

Do not forget:

• a secondary task life cycle may be needed for certain tasks: for instance, before being opened, worked on, etc., a REL (Release) must be submitted first.
• an approbation life cycle can come along certain tasks: one can not submit a REL (Release) without an approbation list.

Answer 2

We're using one tool where we do mix bugs and feature requests (but we flag each entry accordingly so we can see whether it's a bug or a requests).

Since we have several departments working on the tasks, we have a litte more statuses... Our different life cycle statuses are:

• to specify (for product management)
• to reproduce (for testing, to check e.g. whether something is a software problem or just a misconfiguration by the customer)
• to develop (for developers)
• to test/verify (for the testing deparment)
• to document (for documentation, e.g. to include it in the user manual)
• implemented & verified (this is the time when we close the task)
• restriction / rejection / not reproducable

Answer 3

The On-hold part is something I've noticed is important - waiting for external dependencies to get things done or set up something is, I think, a vital task status for management to easily see what they can go ahead and whip in motion... ^^

Answer 4

Simpler than simple

open
error/change analysis
qa review
closed/rejected

Answer 5

I think the only 2 necessary items are "Open" and "Closed" all the rest are gradients.

I use:

• Open
• Pending
• Resolved
• On Hold
• Closed

Sometimes I add to that:

• In Progress
• Billed
• In Test
• Review
• Cancelled

It depends on the team's work flow.