Introduction in a Nutshell
Do you exactly know which issues types to use for your issue tracker and when to use which? Does everyone in your project know about your approach? Are issue types always used consistently in your project? Should you use Technical User Stories or not? Do you use issue types at all? Do you find it reasonable that different issue trackers have such different default issue types? Have you ever thought about issue types at all?
If your answer to one or more of the questions above is “no”, or “don’t know” or “I don’t care”, you are not alone, and this post might be of interest to you. It reveals the chaos behind the often mindless, uncertain and inconsistent usage of issue types in many software projects. It shows why a conscious and purposeful application of issue types can lead to better code comprehensibility as well as better quality monitoring and decision making in projects. It suggests a minimal set of reasonable issue types along with understandable rules for their usage. In particular, it reasons why a separate issue type is needed to deal with technical debt.
Recent Comments