You can use TODO keywords to indicate different, possibly sequential states in the process of working on an item, for example(note: Changing the variable org-todo-keywords only becomes effective after restarting Org mode in a buffer.):

(setq org-todo-keywords
      '((sequence "TODO" "FEEDBACK" "VERIFY" "|" "DONE" "DELEGATED")))

The vertical bar separates the TODO keywords (states that need action) from the DONE states (which need no further action). If you do not provide the separator bar, the last state is used as the DONE state.

With this setup, the command C-c C-t cycles an entry from TODO to FEEDBACK, then to VERIFY, and finally to DONE and DELEGATED. You may also use a numeric prefix argument to quickly select a specific state. For example C-3 C-c C-t changes the state immediately to VERIFY. Or you can use S-RIGHT and S-LEFT to go forward and backward through the states. If you define many keywords, you can use in-buffer completion (see Completion) or a special one-key selection scheme (see Fast access to TODO states) to insert these words into the buffer. Changing a TODO state can be logged with a timestamp, see Tracking TODO state changes, for more information.

The second possibility is to use TODO keywords to indicate different types of action items. For example, you might want to indicate that items are for "work" or "home". Or, when you work with several people on a single project, you might want to assign action items directly to persons, by using their names as TODO keywords. This type of functionality is actually much better served by using tags (see Tags), so the TODO implementation is kept just for backward compatibility.

Using TODO types, it would be set up like this:

(setq org-todo-keywords '((type "Fred" "Sara" "Lucy" "|" "DONE")))

In this case, different keywords do not indicate states, but rather different types. So the normal work flow would be to assign a task to a person, and later to mark it DONE. Org mode supports this style by adapting the workings of the command C-c C-t=(note: This is also true for the =t command in the agenda buffer.). When used several times in succession, it still cycles through all names, in order to first select the right type for a task. But when you return to the item after some time and execute C-c C-t again, it will switch from any name directly to DONE. Use prefix arguments or completion to quickly select a specific name. You can also review the items of a specific TODO type in a sparse tree by using a numeric prefix to C-c / t. For example, to see all things Lucy has to do, you would use C-3 C-c / t. To collect Lucy's items from all agenda files into a single buffer, you would use the numeric prefix argument as well when creating the global TODO list: C-3 M-x org-agenda t.

Sometimes you may want to use different sets of TODO keywords in parallel. For example, you may want to have the basic TODO/DONE, but also a workflow for bug fixing, and a separate state indicating that an item has been canceled—so it is not DONE, but also does not require action. Your setup would then look like this:

(setq org-todo-keywords
      '((sequence "TODO" "|" "DONE")
        (sequence "REPORT" "BUG" "KNOWNCAUSE" "|" "FIXED")
        (sequence "|" "CANCELED")))

The keywords should all be different, this helps Org mode keep track of which subsequence should be used for a given entry. In this setup, C-c C-t only operates within a sub-sequence, so it switches from DONE to (nothing) to TODO, and from FIXED to (nothing) to REPORT. Therefore you need a mechanism to initially select the correct sequence. In addition to typing a keyword or using completion (see Completion), you may also apply the following commands:

C-u C-u C-c C-t, C-S-RIGHT, C-S-LEFT

These keys jump from one TODO sub-sequence to the next. In the above example, C-u C-u C-c C-t or C-S-RIGHT would jump from TODO or DONE to REPORT, and any of the words in the second row to CANCELED. Note that the C-S- key binding conflict with shift-selection (see Packages that conflict with Org mode).

S-RIGHT, S-LEFT

S-LEFT and S-RIGHT walk through all keywords from all sub-sequences, so for example S-RIGHT would switch from DONE to REPORT in the example above. For a discussion of the interaction with shift-selection, see Packages that conflict with Org mode.

If you would like to quickly change an entry to an arbitrary TODO state instead of cycling through the states, you can set up keys for single-letter access to the states. This is done by adding the selection character after each keyword, in parentheses(note: All characters are allowed except @, ^ and !, which have a special meaning here.). For example:

(setq org-todo-keywords
      '((sequence "TODO(t)" "|" "DONE(d)")
        (sequence "REPORT(r)" "BUG(b)" "KNOWNCAUSE(k)" "|" "FIXED(f)")
        (sequence "|" "CANCELED(c)")))

If you then press C-c C-t followed by the selection key, the entry is switched to this state. SPC can be used to remove any TODO keyword from an entry.

It can be very useful to use different aspects of the TODO mechanism in different files. For file-local settings, you need to add special lines to the file which set the keywords and interpretation for that file only. For example, to set one of the two examples discussed above, you need one of the following lines, starting in column zero anywhere in the file:

#+TODO: TODO FEEDBACK VERIFY | DONE CANCELED

You may also write #+SEQ_TODO to be explicit about the interpretation, but it means the same as #+TODO, or

#+TYP_TODO: Fred Sara Lucy Mike | DONE

A setup for using several sets in parallel would be:

#+TODO: TODO(t) | DONE(d)
#+TODO: REPORT(r) BUG(b) KNOWNCAUSE(k) | FIXED(f)
#+TODO: | CANCELED(c)

To make sure you are using the correct keyword, type #+ into the buffer and then use M-TAB to complete it (see Completion).

Remember that the keywords after the vertical bar—or the last keyword if no bar is there—must always mean that the item is DONE, although you may use a different word. After changing one of these lines, use C-c C-c with point still in the line to make the changes known to Org mode(note: Org mode parses these lines only when Org mode is activated after visiting a file. C-c C-c with point in a line starting with #+ is simply restarting Org mode for the current buffer.).

Org mode highlights TODO keywords with special faces: org-todo for keywords indicating that an item still has to be acted upon, and org-done for keywords indicating that an item is finished. If you are using more than two different states, you might want to use special faces for some of them. This can be done using the variable org-todo-keyword-faces. For example:

(setq org-todo-keyword-faces
      '(("TODO" . org-warning) ("STARTED" . "yellow")
        ("CANCELED" . (:foreground "blue" :weight bold))))

While using a list with face properties as shown for CANCELED should work, this does not always seem to be the case. If necessary, define a special face and use that. A string is interpreted as a color. The variable org-faces-easy-properties determines if that color is interpreted as a foreground or a background color.

The structure of Org files—hierarchy and lists—makes it easy to define TODO dependencies. Usually, a parent TODO task should not be marked as done until all TODO subtasks, or children tasks, are marked as done. Sometimes there is a logical sequence to (sub)tasks, so that one subtask cannot be acted upon before all siblings above it have been marked as done. If you customize the variable org-enforce-todo-dependencies, Org blocks entries from changing state to DONE while they have TODO children that are not DONE. Furthermore, if an entry has a property ORDERED, each of its TODO children is blocked until all earlier siblings are marked as done. Here is an example:

* TODO Blocked until (two) is done
** DONE one
** TODO two

* Parent
:PROPERTIES:
:ORDERED:  t
:END:
** TODO a
** TODO b, needs to wait for (a)
** TODO c, needs to wait for (a) and (b)

You can ensure an entry is never blocked by using the NOBLOCKING property (see Properties and Columns):

* This entry is never blocked
:PROPERTIES:
:NOBLOCKING: t
:END:

C-c C-x o (org-toggle-ordered-property)

Toggle the ORDERED property of the current entry. A property is used for this behavior because this should be local to the current entry, not inherited from entries above like a tag (see Tags). However, if you would like to track the value of this property with a tag for better visibility, customize the variable org-track-ordered-property-with-tag.

C-u C-u C-u C-c C-t

Change TODO state, regardless of any state blocking.

If you set the variable org-agenda-dim-blocked-tasks, TODO entries that cannot be marked as done because of unmarked children are shown in a dimmed font or even made invisible in agenda views (see Agenda Views).

You can also block changes of TODO states by using checkboxes (see Checkboxes). If you set the variable org-enforce-todo-checkbox-dependencies, an entry that has unchecked checkboxes is blocked from switching to DONE.

If you need more complex dependency structures, for example dependencies between entries in different trees or files, check out the module org-depend.el in the org-contrib repository.

The most basic automatic logging is to keep track of when a certain TODO item was marked as done. This can be achieved with(note: The corresponding in-buffer setting is: #+STARTUP: logdone.)

(setq org-log-done 'time)

Then each time you turn an entry from a TODO (not-done) state into any of the DONE states, a line CLOSED: [timestamp] is inserted just after the headline. If you turn the entry back into a TODO item through further state cycling, that line is removed again. If you turn the entry back to a non-TODO state (by pressing C-c C-t SPC for example), that line is also removed, unless you set org-closed-keep-when-no-todo to non-nil. If you want to record a note along with the timestamp, use(note: The corresponding in-buffer setting is: #+STARTUP: lognotedone.)

(setq org-log-done 'note)

You are then prompted for a note, and that note is stored below the entry with a Closing Note heading.

You might want to automatically keep track of when a state change occurred and maybe take a note about this change. You can either record just a timestamp, or a time-stamped note. These records are inserted after the headline as an itemized list, newest first(note: See the variable org-log-states-order-reversed.). When taking a lot of notes, you might want to get the notes out of the way into a drawer (see Drawers). Customize the variable org-log-into-drawer to get this behavior—the recommended drawer for this is called LOGBOOK=(note: Note that the =LOGBOOK drawer is unfolded when pressing SPC in the agenda to show an entry—use C-u SPC to keep it folded here.). You can also overrule the setting of this variable for a subtree by setting a LOG_INTO_DRAWER property.

Since it is normally too much to record a note for every state, Org mode expects configuration on a per-keyword basis for this. This is achieved by adding special markers ! (for a timestamp) or @ (for a note with timestamp) in parentheses after each keyword. For example, with the setting

(setq org-todo-keywords
      '((sequence "TODO(t)" "WAIT(w@/!)" "|" "DONE(d!)" "CANCELED(c@)")))

You not only define global TODO keywords and fast access keys, but also request that a time is recorded when the entry is set to DONE, and that a note is recorded when switching to WAIT or

CANCELED ¹⁵. The setting for WAIT is even more special: the ! after the slash means that in addition to the note taken when entering the state, a timestamp should be recorded when leaving the WAIT state, if and only if the target state does not configure logging for entering it. So it has no effect when switching from WAIT to DONE, because DONE is configured to record a timestamp only. But when switching from WAIT back to TODO, the /! in the WAIT setting now triggers a timestamp even though TODO has no logging configured.

You can use the exact same syntax for setting logging preferences local to a buffer:

#+TODO: TODO(t) WAIT(w@/!) | DONE(d!) CANCELED(c@)

To record a timestamp without a note for TODO keywords configured with @, just type C-c C-c to enter a blank note when prompted.

In order to define logging settings that are local to a subtree or a single item, define a LOGGING property in this entry. Any non-empty LOGGING property resets all logging settings to nil. You may then turn on logging for this specific tree using STARTUP keywords like lognotedone or logrepeat, as well as adding state specific settings like TODO(!). For example:

* TODO Log each state with only a time
  :PROPERTIES:
  :LOGGING: TODO(!) WAIT(!) DONE(!) CANCELED(!)
  :END:
* TODO Only log when switching to WAIT, and when repeating
  :PROPERTIES:
  :LOGGING: WAIT(@) logrepeat
  :END:
* TODO No logging at all
  :PROPERTIES:
  :LOGGING: nil
  :END:

Org has the ability to track the consistency of a special category of TODO, called "habits." To use habits, you have to enable the habit module by customizing the variable org-modules.

A habit has the following properties:

1. The habit is a TODO item, with a TODO keyword representing an open state.
2. The property STYLE is set to the value habit (see Properties and Columns).
3. The TODO has a scheduled date, usually with a .+ style repeat interval. A ++ style may be appropriate for habits with time constraints, e.g., must be done on specific days of week (++1w), or a + style for an unusual habit that can have a backlog, e.g., weekly reports. See Repeated tasks for more details about repeat intervals.
4. The TODO may also have minimum and maximum ranges specified by using the syntax .+2d/3d, which says that you want to do the task at least every three days, but at most every two days.
5. State logging for the DONE state is enabled (see Tracking TODO state changes), in order for historical data to be represented in the consistency graph. If it is not enabled it is not an error, but the consistency graphs are largely meaningless.

To give you an idea of what the above rules look like in action, here's an actual habit with some history:

** TODO Shave
   SCHEDULED: <2009-10-17 Sat .+2d/4d>
   :PROPERTIES:
   :STYLE:    habit
   :LAST_REPEAT: [2009-10-19 Mon 00:36]
   :END:
   - State "DONE"       from "TODO"       [2009-10-15 Thu]
   - State "DONE"       from "TODO"       [2009-10-12 Mon]
   - State "DONE"       from "TODO"       [2009-10-10 Sat]
   - State "DONE"       from "TODO"       [2009-10-04 Sun]
   - State "DONE"       from "TODO"       [2009-10-02 Fri]
   - State "DONE"       from "TODO"       [2009-09-29 Tue]
   - State "DONE"       from "TODO"       [2009-09-25 Fri]
   - State "DONE"       from "TODO"       [2009-09-19 Sat]
   - State "DONE"       from "TODO"       [2009-09-16 Wed]
   - State "DONE"       from "TODO"       [2009-09-12 Sat]

What this habit says is: I want to shave at most every 2 days—given by the SCHEDULED date and repeat interval—and at least every 4 days. If today is the 15th, then the habit first appears in the agenda (see Agenda Views) on Oct 17, after the minimum of 2 days has elapsed, and will appear overdue on Oct 19, after four days have elapsed.

What's really useful about habits is that they are displayed along with a consistency graph, to show how consistent you've been at getting that task done in the past. This graph shows every day that the task was done over the past three weeks, with colors for each day. The colors used are:

Blue

If the task was not to be done yet on that day.

Green

If the task could have been done on that day.

Yellow

If the task was going to be overdue the next day.

Red

If the task was overdue on that day.

In addition to coloring each day, the day is also marked with an asterisk if the task was actually done that day, and an exclamation mark to show where the current day falls in the graph.

There are several configuration variables that can be used to change the way habits are displayed in the agenda.

org-habit-graph-column

The buffer column at which the consistency graph should be drawn. This overwrites any text in that column, so it is a good idea to keep your habits' titles brief and to the point.

org-habit-preceding-days

The amount of history, in days before today, to appear in consistency graphs.

org-habit-following-days

The number of days after today that appear in consistency graphs.

org-habit-show-habits-only-for-today

If non-nil, only show habits in today's agenda view. The default value is t. Pressing C-u K in the agenda toggles this variable.

Lastly, pressing K in the agenda buffer causes habits to temporarily be disabled and do not appear at all. Press K again to bring them back. They are also subject to tag filtering, if you have habits which should only be done in certain contexts, for example.