Sign in or 

| Issue Type | |||||||||||||||||
| Summary (Title) | Make the title clear and concise. It should indicate something the user does or the system does. If it is a Group-type issue, preface with "Group: " just so that it stands out in the various views.
| ||||||||||||||||
| Description | NOTE: For lengthy descriptions that also serve as "corporate memory" of the major requirements, do the bulk of docs on the wiki, summarize in the issue and paste a URL. Be sure to describe the issue fully so that the "client-valued" aspects shine through. Here are some templates (search Google for more) to help you word the issues properly. One template "As a role, I should be able to feature, so that benefit" "As an Agent, I should be able to choose class of business easily (searching by name or SIC code), so that I can quickly and accurately prepare a quote for my client." FDD template Another template (from Feature-Driven Development) is: <action> <result> <object> "Display the detail & summary premium data (to the agent)." "Create a PDF of the detail & summary premium data (so the agent can send to client)." Scenario Template Be sure to also include how to know when an issue is complete and testable. Describe various scenarios if needed, when there are different conditions to consider. The point here is to make it clear to the developer and the tester what is expected.
Examples:
| ||||||||||||||||
| Component | Useful to link the issue to a specific area of the application or work efforts. | ||||||||||||||||
| Version | a.k.a. "Iteration" -- implies when the feature is scheduled for completion | ||||||||||||||||
| Assign | Set during issue handling process. Generally should be based on person's knowledge and skills in inverse proportion to the criticality and complexity and deadline. Should not simply be any warm body. | ||||||||||||||||
| Priority | Often known in advance. Helps team understand relative importance of an issue. Macro priority is the Version. This priority can sometimes be used to help a developer sort their work tasks in proper order. | ||||||||||||||||
| Estimate | Developer doing the task can enter their estimate (see process) | ||||||||||||||||
| Due Date | Used when an issue needs to be done by a date other than end of milestone (used infrequently). | ||||||||||||||||
| Attachment | Upload any useful attachments, or reference those that are on a wiki page! | ||||||||||||||||
| Links | If there are related issues or dependencies, add them via link. For example see Linking Issues |
|
JonKern |
Latest page update: made by JonKern
, Apr 30 2010, 10:03 PM EDT
(about this update
About This Update
53 words added 4 words deleted view changes - complete history) |
|
Keyword tags:
agile
process
requirements
More Info: links to this page
|