How to Plan Iterations with Jira?

We strongly believe that the tools we use should facilitate our process and needs and not the other way around. That is why we chose JIRA as one of our project management tools.

JIRA covers a lot of different project types and workflows and can be customized to fit our purposes in each of the projects individually.

Every project needs planning. After all, failing to plan is planning to fail. Fortunately, JIRA helps us be very efficient in this aspect.

Planning an iteration

When discussing the planning of iterations, we can look at two main aspects - the first one is planning the next sprint (iteration) before we start work. The second is planning a release. Let’s take a look at sprint planning first.

In Agile frameworks, a sprint can last from one to four weeks. The length is chosen according to the flow and dynamics that we have in the project. If we need to review our goals more often and control progress closer, we choose one-week sprints. If we have more ground to cover with each iteration, we can go with two week sprints. We can create many sprints at once on top of the backlog and plan for a longer period of time if needed.
Teams need to be cross-functional, so they often include multiple specialists in different areas - backend, frontend, design, quality assurance.
One of the great features is having quick filters, which helps us sift through the tickets in order to find the ones that we want to work on in the next sprint. These filters can be highly customizable and we can choose to filter by assignee, any label we enter (some most popular are of course labels describing backend, frontend, mobile or the name of the technology), and many other things.

The new JIRA view also provides fast access to these filters from the backlog or the active board - no more searching, just filter it out with one click:

While planning, we use a Definition of Ready in our tickets. This means that, before an issue can be added into a sprint, it must include a user story and acceptance criteria and it must be estimated. In other words, an issue must be ready (pun intended) to be included in a sprint.

We use different estimation methods and JIRA facilitates all of them fine.
The most popular estimation method we use right now is Story Point Estimation. This means that, instead of looking at a product backlog item and estimating it in hours, the teams consider only how much effort a product backlog item will require relative to other product backlog items. Once we have a few sprints under our belt we can predict the velocity of the team and therefore plan accordingly.
But sometimes we need a more concrete value in order to predict the cost of delivery. In that case we can use time estimations, which JIRA also allows us to put into issues. We can even track the time spent on each issue to ensure that we improve our estimation each time we plan the next iteration.

The cool thing about it is that one system does not exclude the other - we can estimate in story points and measure the team velocity, but at the same time we can put in some rough data about the time spent with each issue in order to be able to predict timelines for our clients and not overload the sprint. Time estimation also helps us realize and take into account other processes such as peer code reviews and quality assurance testing, which are the standard for all our development workflows.

Another helpful tool that we can use is placed under the action icons at the top of each issue. These icons will help us link issues with each other, add an InVision preview with a design of the feature, create sub-tasks or add any other integration that we think is useful for us.
Linking certain issues together (different options available, such as is connected with, follows, is followed by, etc.) helps to find all dependencies and remember what goes first and what goes later in order to avoid developers blocking each other. You can choose ticket priorities according to these links if you find that some tickets should be prioritised by a certain team to unblock the other.