S P I N P

Agile Project Management

Agile Project management using Jira

One of the main reasons our team relies on Jira is the extensive functionality of the tool. Every project is unique and requires a special approach and a specific toolset for effective software project management with Jira. Jira provides us with an opportunity to choose the needed stack to plan, track, and release even the most complex projects. While there is not a single right way to organize a project in Jira (everything depends on a project), there are some best practices, and we want to share them with you. 

Here, we will check not only some common features (you might already know them anyway) but we will share with you some practices that we at SPINP TECH use internally. They help our project management processes be clear, transparent, and efficient.

Scrum or Kanban? Choose depending on a project

Jira offers the smooth utilization of the extensive functionality of Scrum and Kanban boards. Scrum and Kanban can be used separately or we combine them if we see that it is better for the project.

Kanban is used to visualize the workflow

Kanban boards are used when a team prefers to start working on a project without a detailed plan or when we need to visualize the workflow.

A Kanban board is basically a To-Do, Doing, and Done board. A Kanban workflow organizes tasks in a way to ensure the work moves on. Team members just move the tasks from one status into another while working on them.

In Jira, you can add layers for specific clients, deliverables, and products. In other words, you can customize it and make it as detailed as you need.

 

Scrum is used to plan the work in detail

We use Scrum boards for projects where we need to plan everything in detail. A scrum takes place over a specific time period. This time period is called a sprint. One sprint might take 1 or 2 weeks, depending on the project.

The team checks daily the progress to ensure the tasks within the sprint are completed and identify possible bottlenecks and issues. 

Spring Planning

A sprint is a period of time within which we need to complete a predetermined set of tasks. A sprint can be one, two, three, or even four weeks long. We prefer two-week sprints because they aren’t too short and allow us to manage a good part of the work. They also allow us to regularly control the processes and check whether we are moving in the right direction. Though we don’t exclude the other periods for sprints, too, depending on the project specifics.

When a sprint starts, we organize sprint planning meetings with our team. During the meeting, we discuss the sprint goals and stories that are prioritized in the backlog. The development team creates the tasks they need to complete. Then, we commit to complete a specific number of tasks within the sprint.

Here, we would mention one important thing to focus on:

We use the estimate of tasks for all the above purposes, but we never use them to judge people or measure a team’s productivity. We use them to understand how big the work volume is and how to prioritize it correctly.

Once everything is prepared, a sprint starts. We have our own practices of organizing standups, retrospective meetings, and following all other stages needed to handle the tasks within a sprint. You can read about them in our article here. And here, we move to other important aspects of Jira project management with SPINP Tech.

The best practices from SPINP Tech on workflow management

A standard workflow in Jira looks like this:

To Do (work that hasn’t started yet)
In Progress (work that is being looked at by the team)
Code Review (work that is done and waiting for review)
Done (work that is done).
Jira is a highly customizable tool. Workflows can be customized depending on a project, the stack used by a team, or the way the team is used to work.

We can change the names of the processes or add additional processes such as Awaiting for QA, Tested, or just whatever we need. Our aim here is to make the workflows easy to use for every team member, transparent, and clear. Working processes are different from project to project. We describe all our working processes in case studies which are published on our website.

We also consider such factors as metrics to be reported in the worklog. We have developed some practices to make our working processes smooth, improve the productivity of each team member, and make the processes transparent and traceable.