12

What is the best practice to use the type of an issue (ie, New Feature, Bug, Task) when a new project is started from scratch?

Examples:

  • A new point of development: Task or New Feature?
  • An improvement: Task of Enhancement?

Subsidary question: what can be the role of type "Task"?

Thank you for your answers, Alain

Alain
  • 121
  • 1
  • 1
  • 3

3 Answers3

11

There are two clear phases for most projects. Before you deliver/ship, and after you deliver/ship.

For a new project everything should be marked as a Task BEFORE you deliver the first time.

Once you have delivered something then all subsequent works items can be marked accordingly:

  • New functionality should marked as New Feature
  • Enhancements/improvements to existing functionality should marked as Enhancements
  • Bug reports obviously marked as Bugs
  • Tasks can still be created but usually site before New Features, Enhancements, Bugs as sub-tasks

One tool should be used to manage all item types with appropriate workflow. Using different tools makes no sense as only data fields and workflow vary by item type (e.g. Bug, Requirement, Enhancement).

I hope this helps you.

dsmalls
  • 311
  • 1
  • 4
3

First of all, this may depend on the organization you live in and the tool you are using. Normally, your organization should define the glossary for your development process, and as part of that, the meaning of the different types of issue or work items.

We in our company use 3 different tools depending on the type of problem to tackle:

  • Polarion for doing requirements engineering and the whole following workflow.
  • JIRA for doing mostly issue tracking with a lots of possibilites to tune it.
  • Trac for mostly developing projects with a more simple workflow.

The definitions we gave the different work item types (Polarion) or issues (JIRA) are:

  • Defect: Denotes an error found in a test. Typical relation is child-of Test.
  • Issue: Something that may be a defect, a change request or something different later. Has to be qualified first, and then will be solved by creating a defect or change request from it.
  • Change request: Defines some change to application demanded by a customer, has normally implications to scope, budget, ... Will often be resolved by creating requirements from it, which will then be specified by use cases, ...
  • Requirement: User, system or technical requirement, that will be implemented by a use case later.
  • Use case: Specification of a functionality that the application has to fulfill.
  • Task: Task of a person to do on some of the result oriented work items or issues.

We cluster all work item types in 2 sections: - result oriented: the work item itself stands for the result. Types are: requirement, use case, component, test case, change request, ... - process oriented: the work items stands for the action to do. Types are: defect, issue, task, ...

So to summarize it:

  • Find your glossary that helps you.
  • Define the scope you will address and include only work item types or issues that fall into that scope.
  • Define a workflow for all of them, and keep that as simple as possible.
  • Define the allowed relations between work item types, that help you track the solution.
mliebelt
  • 15,345
  • 7
  • 55
  • 92
  • To create a "defect" or a "change request" from an "issue", we can either create a new issue, or keep the same issue and simply change its issue type from "issue" to whatever is appropriate. Do you think either is fine, or one approach is much better? (We use redmine if that matters.) Thanks! – max Aug 19 '12 at 16:10
  • I don't know Redmine well enough, but normally things are transferable. Normally, special issue types have additional attributes and / or a different workflow. So when migrating from one type to the other, you may loose data or have to migrate it. As long as only "issue data" (consumable for all types) is created, the migration is in my opinion the better way. As long as you don't know which type you need, just create a generic issue. If you later realize that a bug is really a change request, then I would stick to copying data and linking the new CR to the bug. Just my opinion ... – mliebelt Sep 02 '12 at 10:11
2

I've been considering this for my workplace as well. I've been thinking that it's better to have types and sub-types, customized to the "phase" of the artifact, instead of a long list of top-level issue types:

Development (i.e. pre-production)

  • Work element: A collection of work elements and tasks; a work element can be categorized as a feature, phase, or deliverable
  • Task: A unit of work which can be reasonably estimated at not-more then 80 hours effort and assigned to a specific individual; can be categorized as development, analysis, documentation or non-software task
  • Defect: A mistake by the programmer

Production

  • Incident: A disruption to expected service; can have a many-to-one relationship with defects
  • Defect: Something which is preventing the artifact from achieving its intended purpose (two sub-types)
    • Implementation defect: artifact does not conform to specifications
    • Requirement defect: specifications do not produce desired outcome
  • Change request: A change to the specifications
    • New feature: An increase of the scope of the software
    • Enhancement: An improvement to the quality of the software (performance etc.)
    • Adaptive: A change due to external environmental conditions (ex. changing databases etc.)
  • Request for service: A request for previously agreed service to be provided (password reset etc.)
  • Non-software task: An action item that makes no change to the software (documentation, user training, data migration etc.)

This seems to map fairly well for the needs of various departments while remaining pretty simple. For example, we would record all defects, NST's and adaptive work as operational expenses, while new features and enhancements would be capital expenditures. Since we've been trying to use Semantic Versioning, defects, enhancements and adaptive maintenance would be typically be considered patch software changes, NST's wouldn't show up at all, and new features would be minor software changes (major is reserved for a change that prevents backwards compatibility or a total rewrite). Some of the breakdowns (ex. implementation vs. requirement defects) are useful when gathering statistics.

Change proposals I think are best handled outside of this scope (they typically require analysis, then requirements which eventually create the specifications that do make it into this), though release & deployment scheduling should integrate quite well. Ideally the change order would be referenced if an item is modified.

Neil McF
  • 259
  • 1
  • 15