In many organizations the potential of JIRA is often underutilized. I have had to see on more than one occasion that it is used practically the same as when it was installed.
The main cause of this is the lack of knowledge of the high degree of customization or configuration that can be achieved in JIRA, mainly when using its APIs, either directly or through a plugin. This potential can be oriented to both operational processes and those found within the IT area.
An example of the latter type is shown in this post: configuring JIRA for project management, in particular maintenance, which are the ones that almost always occur in greater numbers in this area.
Although the use of JIRA is usually associated with project management, in reality JIRA was not designed to manage projects, when by projects we understand what the PMI defines in the framework of the PMBOK, that is:
A set of activities limited in time and destined to produce a single result or product
In fact, JIRA does not meet the definition of a software for PPM (Project Portfolio Management). As we mentioned in this article, JIRA manages issues through flows that allow each issue to be moved through its different states. In JIRA a project is a mere “container of issues”. That’s why in some situations we need a JIRA alternative.
Notwithstanding the above, it is possible to configure JIRA and create a project management process. For this there are 2 ways:
– Configure JIRA taking advantage of the wide range of customization possibilities it offers.
– Use plugins.
In this post we are going to address a model based on the first approach.
The hierarchy of issues
The first thing we have to do is define what types of issues we are going to use to manage our projects. In this case we are going to use the context of an IT area, but the model is perfectly applicable to initiatives of other groups or areas.
In the first place, we have issues that represent INITIATIVES that are developed in an IT area: evolutionary maintenance of applications, developments oriented to web or mobile platforms, infrastructure renewal or expansion, etc. Each of these initiatives has characteristics that distinguish it from one another, but in general we can assume that all are executed following a series of specific STAGES.
Each of these stages contains TASKS where our time is spent: meetings, scheduling, tests, etc. As estimates and schedules always change in reality, we have to have a way to organize and control changes: for this there is a CHANGE CONTROL that we will see how to use in the next section.
In summary, we have that an Initiative can be divided into many Stages and within each stage we execute Tasks. To control changes to the planning of the stages (and therefore of the initiative), we have change controls. In JIRA this hierarchy is implemented using the link functionality.
What we do now is configure all these types of issues in JIRA, which implies defining specific attributes for each of them. One of these attributes is related to the management of dates, since a project is a series of activities limited in time, it is obvious that we need to manage dates. Here we can define two types of dates: plan and actual. That is, for each type of issue we have a planned start and end date and a real start and end date.
Using JIRA flow controls we can restrict who and when these dates are updated. For example, only the JP can change the plan dates of the stages of an initiative, but not the actual ones. The latter are automatically updated when we start the first task in a stage (start) and when we close the stage (finish).
Another characteristic of the configuration is that it must roll-up or totalize from the tasks to the stage and from these to the initiative the planning, actual and estimate data.
The workflow schema
The flow customization possibilities offered by JIRA are many, even more so if you use some plugins such as Jira Workflow Toolbox. In this model that we are building, these customization possibilities are stretched to the maximum, since there are a series of actions that we want to be controlled and automatic.
In the case of Initiatives, the flow will reflect the methodology or paradigm that the organization or group explicitly (or implicitly) follows to execute its projects. If we use a traditional “waterfall” model, the initiatives will move through analysis, design, construction, testing and delivery. If we use a RUP type model, these move in the Start, Elaboration, Construction and Transition phases.
The agile paradigms that are in vogue today are located within the context of a stage in this hierarchy, since these paradigms privilege iterations (or sprints) of short duration (2-3 weeks), at the end of which they can be shown specific deliverables. What interests us in this model is to control the development of the Initiative and its Stages, the tasks included in a sprint can be managed using boards available in JIRA SOFTWARE or through simple JQL filters.
In the case of Stages, the flow is simple: a stage is open while we create and plan tasks, in progress we just begin to record hours in a task and finally closed when the JP establishes it (previously all tasks have to be completed or closed). But since in reality the estimates and schedules change, there is an additional state, in change control, which reflects the fact that we are modifying the estimates of one (or more) stage through a change control. Only while the stage is in this state can its planning attributes be modified, such as the planned start / end date or the estimated hours: for this, the change control must be in the approved state, otherwise it is not allowed to modify the estimates of the stage, and its approval is restricted to only a group of people.
