As we have seen, JIRA comes with a number of project types, depending on what applications you have installed. The business project type, being part of JIRA Core, is available to all installations.
Business projects are very similar to how JIRA worked before JIRA 7, where it works as a highly customizable, generic task tracking system. The focus of business project type and its templates is for users to be able to easily create tasks and track and report on their progress.
Out of the box, you have three built-in templates, each with a set of predefined configurations, such as workflows and fields, to give you some idea on how to set up your projects. You can use them as is or customize them further based on your needs.
The first step to work with Scrum in JIRA is to create a project with the Scrum template:
- Select the Create project option from the Projects drop-down menu.
- Choose the Scrum software development template and click on Next.
- Accept the settings and click on Next.
- Enter the name and key for the new project and click on Submit:
Once the new Scrum project is created, you will be taken to the Scrum interface, as shown in the following screenshot:
The Scrum interface has the following main sections:
- Backlog: This is where all unplanned issues are stored. You can think of it as a to-do list. The product owner and the development team will work together to define the priorities of issues in the backlog, which will then be scheduled into sprints for delivery.
- Active sprints: This view shows the sprints that are currently underway and the issues that are part of the sprints. This is what the development team will use on a day-to-day basis to track their progress.
- Reports: This view contains a number of use report you can generate based on your team's performance. These reports help you and your team to visualize how the project is progressing and provide valuable feedback that you can use in future sprint planning sessions for improvements.
The backlog is the to-do list of your project where you keep all of your incomplete features (usually represented as stories). When you first start, you may have an empty backlog, so the first step is for the product owner and the team to work together to populate it with stories and tasks to be completed. During this activity, it works more like a brainstorming session, where the team works together to translate requirements from customers and other stakeholders into actionable stories and tasks.
Once you have the backlog populated, the next step is to estimate and prioritize the issues, so you can plan and build a schedule on how to complete them. In JIRA, prioritizing issues in the backlog means moving them up and down in the backlog by dragging and dropping. So to increase the priority of an issue, you can simply drag it higher in the backlog list. While this is usually the product owner's responsibility to prioritize what features to deliver first, the team should also be involved in this process to make sure that everyone is in sync on the direction.
Estimating work is a critical part of Scrum, and the success of your sprints heavily depends on how well you and your team can estimate. One thing people often get confused with is that they tend to think of estimation in terms of time; for example, story A will take five hours to complete. While this may seem right at first, what would often end up happening is people will either work extra hard in order to make the estimate seem accurate or give big estimates because they are uncomfortable with the task at hand. This can lead to big problems as the project goes on.
One way to avoid this pitfall is to use something arbitrary for estimation called story points, and this is the default estimation method in JIRA. The idea behind this is to measure and estimate issues based on their complexity, rather than time required to complete them. So, if you start a sprint with a total of 10 story points worth of issues, and at the end of the sprint, you are not able to complete all of them, this might indicate that you have been too aggressive and may need to reduce your expectations. Since the estimation is not done based on the time taken, it simply indicates that perhaps the issues are too complex, and you will need to break them down further into more digestible pieces. This helps to avoid people feeling they are running against the clock, and also help you to better define and break down tasks into a smaller, more manageable size.
Sometimes, however, you might find it difficult to estimate the complexity of your stories. This is usually a sign that you either do not have enough information about the story, or the story's scope is too big can needs to be broken down. It is important for the team and to realize this and not shy away from going back to ask more questions in order to fully understand the purpose of the story before providing an estimate.
Now that we have determined a way to estimate our issues, to enter the estimate is as simple as doing the following:
- Select the issue to estimate from the backlog.
- Enter the number of story points into the Estimate field, as shown in the following screenshot:
With the backlog populated and issues estimated, the next step is to create a sprint for the team to start working on. To create a new sprint, perform the following steps:
- Go to the backlog of your project.
- Click on the Start Sprint button. This will create a new empty sprint.
- Add issues to the sprint by dragging and dropping issues into the sprint box, as shown in the following screenshot:
Once the team has decided on the scope, it is time to start the sprint:
- Click on the Create Sprint button.
- Select the duration of the sprint. Generally speaking, you would want to keep your sprint short. Between one to two weeks is usually a good length.
- Click on the Start button to start your sprint.
Once the sprint is started, you can go to the active sprints view and the team can start working on delivery.
Normally, you will only have one team working on the project at any given time, but if you have a big team, and people will work on different part of the project at the same time, you need to enable the parallel sprints option:
- Log in to JIRA as an administrator.
- Browse to the JIRA administration console.
- Select the Applications tab and then JIRA Software configuration.
- Check the Parallel Sprints option to enable it.
With the parallel sprints option enabled, you can start multiple sprints at the same time. When running multiple sprints, it is best to keep them separate from each other, so they do not get into each other's way. A good example will be two sprints focusing on different areas of the project, such as delivery and documentation.
In JIRA, when you have parallel sprints, the active sprint view will only show one sprint at a time, so you will need to toggle between the sprints, as shown in the following screenshot:
Once the team has prioritized the issues and started a sprint during the sprint-planning meeting, the agile board will switch over to the active sprint view. For normal teams, you will have one active sprint at any given time, and your Scrum board will look as shown in the following screenshot:
The Scrum board is made up of vertical columns that represent various states an issue can be in, and they are mapped to the workflow used by the project. So in our example, we have the default workflow with three states, To Do, In Progress, and Done. As we will see later, the project administrator will be able to customize this.
The board can also be divided into a number of horizontal rows called swimlanes. These help you to group similar issues and make your board easier to understand. For example, we are grouping issues into swimlanes based on the issue assignee in our example. Just like columns, the project administrator can customize how swimlanes should be defined.
On the Scrum board, each issue is represented as a card, and developers can drag them across the board as they work through them.
When a sprint is underway, it is important to avoid introducing scope creep by adding more issues to the sprint, and it falls on the Scrum master and the product owner to make sure that the team is not distracted or blocked by any impediments. However, from time to time, emergency situations that demand certain features or fixes need to be included do arise, and in these cases, you can add new issues into the active sprint from the backlog view.
Do keep in mind though, that this should not become a common habit, as it is very distractive, and it is usually a sign of bad sprint planning or poor communication with stakeholders. JIRA will also prompt you whenever you try to add more issues to an active sprint:
At the end of the sprint, you need to complete the sprint by doing the following:
- Go to the Scrum board and click on Active sprints.
- Click on the Complete Sprint link.
- Click on the Complete button to finish the sprint.
Once you have completed a sprint in JIRA, any unfinished issues will be placed back into the backlog. Sometimes, you may have other sprints planned but not active; in this case, issues that are not completed from the current active sprint can be automatically added to the next available sprint.
It can be tempting to extend the sprint for just a few more days because you have just one more issue to complete. While this is not a hard rule, generally you should avoid this and just let the incomplete issue go back to the backlog and reprioritize it during the next sprint meeting. This is because Scrum is an iterative process and the goal is not to make everyone work as hard as possible, but to be able to retrospectively look at what the team did right and/or wrong in the previous sprint and address that in the next sprint. Perhaps the reason is due to inaccurate estimation or incorrect assumptions made during requirement gathering. The point here is the team should view this as an opportunity to improve rather than a failure to be rushed. Simply extending the current sprint to accommodate incomplete items can turn into a slippery slope where the practice becomes the norm, and the root problem is masked.