Sometimes agile teams have to draft and deliver scope, discovery, requirements or high-level design documentation. I don't want to get into the how or why in this blog entry. Rather, I want to spend the entry discussing how these documents can be shaped as features and broken into discrete, estimated tasks so they can be prioritized, managed and tracked like any other development work in an agile process.

Documents really are a project or team deliverable just like any other feature. All you need is for the team to guess at an Effort Day estimate (and sometimes it really is more guess than estimate). Once included in the Feature Catalog, an estimated document can be prioritized and planned alongside all other features.

Most documents take at least three tasks to complete. These tasks are:

Estimate - Task
---------------
1.5   - Draft Document

.5    - Review and Revise

.1    - Get Sign-Off

The effort day estimates before each task are merely examples. Getting sign-off (when sign-off on a document is required) is always a separate task that carries an effort estimate, even if that estimate (.1 effort days in our example) only reflects an hour's work. We often forget the time we spend getting sign-off on documents: sending emails, making little adjustments, leaving voice mails, finding out the person just left on vacation, etc.

Obviously, the tasks required to complete a document vary greatly depending on the document. The following list might be for a high-level analysis document:

Estimate - Task
---------------
.5      - Interview Users for Feature A and Compile Notes

.5      - Draft Workflow for Feature A

.25    - Detail Requirements for Essential Activities in Feature A

.25    - Review and Revise Feature A with Users

.75    - Interview Users for Feature B and Compile Notes

1      - Mock-up GUI for Feature B

.5     - Define Field Validations for Feature B

.5     - Review and Revise Feature B with Users

.25   - Review and Revise Document with Sponsor

.1    - Get Sign-off from Sponsor

These documentation tasks can be used to define, agree upon, and even reinforce team processes. The interview tasks include "Compile Notes" since merely holding a meeting should not be reason enough to set a task to complete. Rather, the task is complete when the task owner has gathered enough information to move on to the next task. Further, our task list now calls for two distinct reviews: (1) with the user to ensure the task owner collected the correct requirements for the specific feature, and (2) with the sponsor to ensure the details line up with what the sponsor was thinking.

Effort Day estimates for documentation tasks often do have a lower level of fidelity than estimates for development tasks. In other words, even at the task level we often do as much guessing as estimating to put an Effort Day number on each task. But this really doesn't matter much. The same warning signs apply to both documentation and development work. If a team member keeps rolling the same task from one week to the next without completing it, then we have a problem. If new tasks are being added to a documentation feature as fast as the original tasks are being completed, we have a problem. If no one has started on the documentation tasks because other new work has been loaded onto the team mid-iteration, we have a big problem. Whether documentation or development, the issues and possible resolutions are often the same.

Keep in mind that large documents can always be split into multiple features the same way we can split large bits of functionality into multiple features. This allows teams to spread work on a single document across multiple iterations. One simple way to split a document into two features is to have a Draft Document feature and a Review and Finalize feature. Another option is to split the document by functional area, user group, or any other appropriate method of sectioning.

One final note. What I have not discussed in this blog entry is the sort of documentation that works best for an agile team. I'll save this topic for other blogs, but for those currently interested in this topic I recommend checking out an Agile Technique that I detail in my book called Solution Sheets.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview