Scrum tutorial
In this tutorial, we'll give you step-by-step instructions on how to drive a scrum project, prioritize and organize your backlog into sprints, run scrum ceremonies and more, all within Jira.
Time:
10 minute read. Complete over 2 weeks
Audience:
You are new to scrum, agile software development, or Jira
Prerequisite:
You have created a Jira account
Scrum is one of the most popular frameworks for implementing agile. With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping on a regular cadence.
Step 1: Create a scrum project
Once you create and log in to an account in Jira, you can select a template from the library. Select Scrum (you can preview the free scrum template here, or you can learn how to create a Kanban project here).
Next, you’ll be prompted to choose a project type. If your team works independently and wants to control your own working processes and practices in a self-contained space, consider giving our team-managed Scrum template a try. See Getting started with team-managed projects at the Atlassian Community to learn more.
Once you've created your project, you will land on the empty backlog. The backlog is also known as the product backlog and contains an ongoing list of your team's potential work items for the project.
Step 2: Create user stories or tasks in the backlog
In Jira, we call work items like user stories, tasks, and bugs "issues". Create a few user stories with the quick create option on the backlog. If you don't have user stories in mind, just create sample stories to get started and see how the process works.
User stories are used to describe work items in a non-technical language and from a user's perspective. . As a {type of user}, I want {goal} so that I {receive benefit}.
Let's use a website as a simple example to create a user story.
As a customer, I want to be able to create an account so that I can see my previous purchases.
User stories are usually sketched out and prioritized by the product owner, and then the development team determines detailed tasks necessary to complete the story in an upcoming sprint. The development team is also responsible for estimating the relative effort required to complete the work of the story.
Once you've created a few user stories, you can start prioritizing them in the backlog. In Jira, you rank or prioritize your stories by dragging and dropping them in the order that they should be worked on.
These are just the starting stories for your project. You will continue to create stories for the project's lifetime. This is because agility involves continuously learning and adapting.
Step 3: Create a sprint
Create your first sprint in the backlog so you can start planning the sprint.
In Scrum, teams forecast to complete a set of user stories or other work items during a fixed time duration, known as a sprint. Generally speaking, sprints are one, two, or four weeks long. It's up to the team to determine the length of a sprint — we recommend starting with two weeks. That's long enough to get something accomplished, but not so long that the team isn't getting regular feedback. Once a sprint cadence is determined, the team perpetually operates on that cadence. Fixed length sprints reinforce estimation skills and predict the future velocity for the team as they work through the backlog.
Step 4: Hold the sprint planning meeting
At the beginning of a sprint, you should hold the sprint planning meeting with the rest of your team. The sprint planning meeting is a ceremony that sets up the entire team for success throughout the sprint. In this meeting, the entire team discusses the sprint goal and the stories in the prioritized product backlog. The development team creates detailed tasks and estimates for the high-priority stories. The development team then commits to completing a certain number of stories in the sprint. These stories and the plan for completing them become what is known as the sprint backlog.
Add story point estimates to your stories by adding a number in the Story point estimate field. You can also add more details to the stories or click the create subtask icon to further break down the work of the story.
When you're ready, drag the stories agreed to in the sprint planning meeting into the sprint that you just created. This is your sprint backlog.
Attendees: Required: development team, scrum master, product owner
When: At the beginning of a sprint.
Duration: Usually two hours per week of iteration – e.g. a two-week sprint kicks off with a four-hour planning meeting. The meeting ends when its purpose has been achieved.
Purpose: Plan the work of the sprint. The team agrees to the sprint goal and the sprint backlog.
When creating a sprint, the product owner usually identifies a sprint goal. This provides a theme for the work to be completed in the sprint. A sprint goal also provides some flexibility in the number of stories that are completed in a sprint. A sprint is considered a success if the sprint goal is achieved.
Traditional software teams give estimates in a time format: days, weeks, months.
Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work, often in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Estimates help you gauge how much work you should add to the next sprint based on the number of team members you have. After a few sprints, your team will get better at figuring out how much work they can do each sprint, which will help avoid over-committing.
Step 5: Start the sprint in Jira
Name the sprint. Some teams name the sprint based on their sprint goal. If there is a commonality between the issues in the sprint, name the sprint around that theme. Otherwise, you can name the sprint whatever you like.
Add a duration of the sprint and start and end dates. The start and end dates should align to your team's schedule. For example, some teams start sprints on a Monday and then end on a Friday morning in the next week. Other teams decide to start and end their sprints mid-week. It's up to you! If you're unsure how long your sprints should be, we recommend trying two weeks.
Add the sprint goal as agreed to in the sprint planning meeting.
Once you start your sprint, you will be taken to the Active sprints tab in the project.
This is where your team will work to pick up items from the to-do column and move them into in-progress and eventually, done!
If you’re using the team-managed scrum template, this will be called a Board.
Step 6: Hold the daily standup meetings
After your sprint has started, have your team meet daily, typically in the morning, to review what everyone is working on. The purpose of this is to see if anyone on your team is experiencing any roadblocks towards the completion of sprint tasks.
Attendees (Primarily): development team
When: Once per day, typically in the morning
Duration: No more than 15 minutes. Don't book a conference room and conduct the standup sitting down. Standing up helps keep the meeting short!
Purpose: The daily standup is designed to inform everyone quickly of what's going on across the team and to plan the work of the day. It's not a full status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
There's an implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.
ProTip: Some teams use timers to keep everyone on track. Others toss a ball across the team to make sure everyone's paying attention. Many distributed teams use video-conferencing or group chat to close the distance gap. Your team is unique — your standup should be, too!
You can use the active sprints of your scrum board during the daily standup, so that each member can view the tasks they're working on.
Step 7: View the Burndown Chart
It's a good idea to check the Burndown Chart during a sprint. In Jira, the Burndown Chart shows the actual and estimated amount of work to be done in a sprint. The Burndown Chart is automatically updated by Jira as you complete work items. To view this chart, click Reports from the sidebar, and then select the Burndown Chart from the reports dropdown.
A Burndown Chart shows the actual and estimated amount of work to be done in a sprint. The horizontal x-axis in a Burndown Chart indicates time, while the vertical y-axis typically indicates story points.
Use the Burndown Chart to track the total work remaining for a sprint, and to project the likelihood of achieving the sprint goal. By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly.
- The team finishes early sprint after sprint because they aren't committing to enough work.
- The team misses their forecast sprint after sprint because they're committing to too much work.
- The burndown line makes steep drops rather than a more gradual burndown because the work hasn't been broken down into granular pieces.
- The product owner adds or changes the scope mid-sprint.
Step 8: View the sprint report
At any point during or after the sprint, you can view the Sprint Report to monitor the sprint.
The Sprint Report includes the Burndown Chart, and lists the work completed, work not completed, and any work added after the sprint started.
Step 9: Hold the sprint review meeting
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
This is a meeting with a lot of feedback on the project and includes a brainstorming session to help decide what to do next.
Attendees (Primarily): development team, scrum master, product owner.
Optional: stakeholders
When: Typically on the last day of the sprint
Duration: Typically two hours for a two-week sprint
Purpose: Inspect the increment and collaboratively update the product backlog.
Questions to ask:
- Did the team meet the sprint forecast?
- Was there work added or removed during the middle of the sprint?
- Did any work not get completed within the sprint?
- If so, why?
Step 10: Hold the sprint retrospective meeting
After you complete the sprint, have your team do a retrospective. Document your retrospective somewhere. May we suggest Confluence?
Attendees: development team, scrum master, product owner.
When: At the end of an iteration.
Duration: Typically 90 minutes for a two-week sprint.
Purpose: The team inspects itself, including its processes, tools and team interaction. Improvement issues are often added to the next sprint's backlog.
Retrospectives aren't just a time for complaints without action. Use retrospectives to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
Questions to ask:
- What did we do well during the sprint?
- What could we have done better?
- What are we going to do better for next time?
ProTip: Even if things are going well across the team, don't stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
Step 11: Complete the sprint in Jira
At the end of the sprint, you must complete it.
If the sprint has incomplete issues, you can:
- Move the issue(s) to the backlog.
- Move the issue(s) to a future sprint.
- Move the issue(s) to a new sprint, which Jira will create for you.
Step 12: Repeat from step 2
At this point, you've got the basics on building your backlog with user stories, organizing your user stories into sprints, starting your sprint, and holding Scrum ceremonies. You can decide if this is working for your team, or if you'd like to move forward into some more advanced topics.
After you and your team have completed the steps above, move on to the advanced article: How to do advanced scrum practices with Jira.
