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.
Sprint goal - this one is really important. It doesn’t matter that you delivered the tasks in one area or the other as planned if your team doesn’t have a common objective and a wider perspective. At Netguru, we try to maximize business value delivered to our clients with each iteration. In order to maximise this process, we are always trying to state our objective for the next iteration. This should be specific and measurable. It helps the team to focus and set priorities when things go south and it helps the team to support each other in order to achieve this goal.
Planning a release
JIRA provides great tools to plan our deployments, which are a part of delivering what we accomplished with each of our iterations.
If the team is big, there is a good chance that you have many issues each sprint that need to be deployed and with that comes the risk that something can be lost by accident. Releases help us manage this by adding a fix version to each issue. Each release can contain a number of issues that we want to deploy. It also shows a progress bar so we can see how much work we still have left before all the issues in the release are ready to be deployed. Thanks to our integration with Github we can also see the status of all pull requests for certain issue.
The Release feature is a great tool for the team, but also for our clients. Our clients often use JIRA along with our team. This way they can always check the release notes, dates, and statuses of particular issues in order to see what has been deployed and what is still waiting to be deployed. Releases therefore help us be very effective with our reporting - the report is always there waiting for us if we need it!
