JIRA is a software tool for project management, which allows tracking of incidents. Originally born to manage incidents, but in recent years it has evolved, but the original heritage as manager note incidents throughout the tool. In any case, it is today, project management, the most popular; very style to others like Red mine, but involve payment.
JIRA Agile has a complement to JIRA for Agile project management, providing boards Scrum or Kanban boards for monitoring tasks in this series of post i ‘ll focus on Scrum with JIRA.
However, it is fashionable JIRA, JIRA Agile is fashionable, agility is fashionable, Scrum is fashionable … but the application of the agile management using JIRA creates many teams still many more questions than solutions.
In this article, I will focus on the basic characteristics of the Product Backlog and terminology of JIRA (complicated sometimes if you come from the agile world), JIRA Agile Agile terminology
Let’s start with terminology. The terminology is often messy in JIRA when previously you come from world of agile or have read some Scrum. First, I will show a list containing the relationship between the terminology of JIRA Agile and Scrum can be more problematic Backlog, period, as used in JIRA Agile, refer to Product Backlog.
An incident can be of many types. What more we’ll use in this context is the incidence of type “story” that are “user stories “. Eye that this is confusing at first, since by “incidence” often comes to mind error in production and this incident will also be “user story “.
Here is one of the most difficult terminology troubles: Tasks.
Sprint Backlog tasks in JIRA Agile
Scrum terminology tasks compose a Spring Backlog (are how to do what you ask us business, usually through user stories), usually derived from user stories.
In JIRA there are two ways to do this:
a) Incidents ( of course ) task type, the only problem is that these would be the same level as the incidence of type user story (in fact, when you create an incident can choose from a dropdown that is history, task, etc. ) remain in the Product Backlog and also could not link from which user story are these type incidents task. Therefore, it is usual for the task type incidents remain in the Product Backlog to stories style techniques.
b) Use subtasks, namely technical tasks, stemming from an incident, usually classified as history (user).
In short, once created the story incidence type enters it and subtasks are created. These subtasks not now appear in the Product Backlog (as happened in the case a) and will only be in the Sprint Scrum boards is performed where user story that corresponds to them, boards would become the sprint backlog.
The Product Backlog in Jira Agile
Starting with the basics, as described in the book ” agile project management ” and many other sites, Scrum Product Backlog is an ordered list and prioritized with all that is necessary to add to the product that has value, thus showing a unique insight throughout the project.
This is the origin of the requirements and needs to develop and modify the product, including errors that will be corrected in future releases. The product backlog stored items, ie, user stories or other needs.
The Product Backlog is continuously evolving and seeks to increase the value of the software product from the point of view of business. When prioritizing responsible for initiating and maintaining the Product Backlog is the Product Owner.
In JIRA Agile Product Backlog is called, as we saw earlier, simply Backlog where all incidents (eye which incidents can be type are stored user stories , technical stories, etc.) and are then assigned to Sprint that corresponds.
–Slimane Zouggari