Receive the free whitepaper “Architecting Jira for the Enterprise” by subscribing to our newsletter.
Jira is a tremendously powerful product, both very flexible and highly configurable. This configurability is one of Jira’s great strengths yet its also a potential weakness if not managed properly. In our project management work, we frequently see clients that have allowed teams to use Jira in a “free style” manner. Each team set up their project independently and so definitions (fields, workflows etc) vary between projects. The result is no “shared meaning” (combinable perspective) across projects. This can be a great loss.
To illustrate: one team decides to define a bug only as a software problem; either confirmed or validated. A second team declares all “user initiated issues” as bugs, closed after analysis if the bugs actually turn out to be a different kind of problem (e.g. the user actually wanted the system to behave in a particular way).