Sign in or
Writing Good Issues
I use Jira from Atlassian, so your mileage may vary. But in general, Softwae Development is nothing more complex than accomplishing a list of "to-dos" :-)
A feature is:
A feature is:
- something the product does
- think marketing brochure bullets or finding it in the User Manual
- It might get bugs.
- It might get improvements.
- It might even be dropped.
- something done one time
- Is often an implementation detail for creating features
- never appears on a marketing brochure or in a feature list
- add users for beta;
- get app stood up on PROD;
- write a Flex UI training plan
- Implement the persistence layer (tables, DAO)
- a small bit of effort that you might do to accomplish the parent issue.
- It is often useful to help you track your to-dos
- Is useful to estimate a larger task by breaking it down into visible chunks.
- Is used solely by the dev team... that is, it should not be surfaced and scheduled by the business
- something that is not working according to plan.
- should be considered when doing iteration planning
- Covered in more detail in Writing Good Bugs.
|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.
"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."
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)."
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.
|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|
Latest page update: made by JonKern
, Apr 30 2010, 10:03 PM EDT
(about this update
About This Update
Edited by JonKern
53 words added
4 words deleted
- complete history)
More Info: links to this page
There are no threads for this page. Be the first to start a new thread.