What is Scrum?
​Scrum is an Agile project management methodology that includes a small team led by a Scrum Master.
​Scrum consists of short iterations or sprints, which last as a rule 2-3 weeks and that is the main difference from Kanban. Team members meet daily to discuss current tasks and blocks that need clearing.
​Scrum can be used for developing a complete software, for developing only some parts of bigger systems, for customers or internal projects.
To be short, Scrum Framework consists of the components:

What is a user story?
​A user story in Agile is the smallest unit of work. It simply reflects the basic info about who the users are, what their goal is and what they want to achieve.
​A product owner is responsible for sketched out the user stories. After this done, the team determines detailed requirements.
​As an example: A customer X wants to create an account to track the purchases he/she made last month to optimize the budget.

Once you login to Hygger Software, you can start creating a new project.
On the header click + > Project.

When you’ve created a project you can invite members to it. Or you can do it later through Company Settings. Project’s Settings. You can open them by clicking the three dots menu near the project name.

After that you may add boards to your project.
You can create a new board the same way you add a project: on the header click + icon > Board > Blank/Template > Kanban/Sprint.

Hygger’s software offers you a template for managing a Product Backlog. Backlog is storage for your suggestions, requests from your customers and requirements for your product.

Remember to add teams to the board so they could start working on the tasks. 

To add members to the board, open a board’s menu (in the right corner of the webpage) > click

On Backlog you can structure, rank insights and plan a product iterations. Those insights come to you from different sources: from Intercom, Zendesk, Satismeter, from private talks with your clients, from your employees. It’s becoming more difficult to pick things for development. The cost of a mistake is really high. It’s a risk to make a feature that won’t be popular among the audience and won’t bring expected benefits. 

To resolve those issues, you can use Value and Efforts rate, which will help you identify the most valuable tasks for your product.

For each of the parameters you can choose a value from 1 to 100. Try to move the slider for Value and Efforts to set or change the Rate of the task.

You can easily define tasks priority and optimize them by using Priority Chart. Priority chart is a visual representation of your ideas. The chart consists of two axes: 

These axes will help you to choose which tasks you should implement and the ones you should avoid if you want to make the most of your time and opportunities. 

There are four sections on the chart:

Big Bets – tasks with both high Value and Efforts rates: these tasks might be valuable, but are time-consuming and require a lot of attention.

Quick Wins – tasks with a high Value rate and a low Efforts rate: these tasks bring you maximum benefit with little efforts required. Lucky you to have many Quick Wins on the board.

Time sinks – tasks with a high Efforts rate and a low Value rate: these tasks require a lot of efforts from your team and probably won’t bring you a lot of value. It’s advisable to start working on such tasks only once your priority tasks are completed.

Maybes – tasks with both low Value and Efforts rates. These tasks neither require many efforts nor will bring you a lot of value. Think twice before you start to develop these tasks.

After the selection process tasks can be developed. Push the tasks you choose to develop from a Backlog to a Sprint board. Preferably those are the features/ideas from Quick Wins section on Priority Chart. 

Push option allows you to send a task from a Backlog to Sprint/Kanban board for its implementation with the help of task link. The pushed task is linked to the original one from Backlog which shows you its development status.
​

With the help of tasks link pushed items will be automatically synchronized. Once a pushed task is completed and moved to the Done column, its parent task will be automatically moved to Done column on a Backlog.

This connection also work backward. You can link a task from development board to a task on Backlog. 

You can push several tasks to different boards at the same time. For example, you gathered all the requirements and created an Epic or a Story and splitted it to 10 tasks for a realization. Some of them can be pushed to a Sprint board, the rest - to a Kanban board. After the push, you can see the cross links in a parent and copied tasks. This helps you to track the status of the epic/story and their subtasks.

Usually you should have 3 sprints planned ahead so you can create 3 columns for each of them. I.e, the columns on your Backlog represent future iterations. Once you are ready to launch a new sprint, just Push All Tasks from a certain column to a board where your development is happening, with no need to manually add those tasks. These items will be automatically linked between each other.
​

​What is a Sprint in Scrum?
​Sprint is a time period that is fixed by the team to complete a set of user stories. Sprints usually last 2-3 weeks. Although the team can determine the length, it's recommended to start with 2 weeks. It's enough to get issues accomplished but not enough to get complete feedback.
​Fixed sprints predict the future velocity as they work through the backlog.

Once the tasks are on the sprint board, remember to estimate them and organize their order of priority before the sprint starts. Without that it will be difficult to determine the time that your team needs to finish the sprint. Besides, estimates will give you an idea of the amount of work you should take to the next sprint with the resources that you have.
After a few sprints, it will be easier for your team to evaluate how much work they can do each sprint.

What are estimations in Agile practices?
​A usual way of estimation intends a time format: by days, weeks and months. However many Agile teams use story points.
​Story points rate the effort of work according to the Fibonacci principle (every number after the first two is the sum of the two preceding ones). This method seems rather helpful as it motivates team members to tougher decisions and hard work.

In Hygger Software, you can gauge issues by opening a task and estimating it with Story Points/Hours or with both of them.

Hold the sprint planning meeting before it begins.

What is a Sprint Planning Meeting in Scrum?
​In Scrum Sprint planning motivates the team to success throughout the sprint.
​During the meeting that usually happens at the beginning of a sprint, a product owner discusses each item with a Scrum master and the development team and they estimate altogether the efforts involved.
​The developers make a sprint forecast. It outlines how much work the team can complete from the product backlog. The usual duration of Scrum planning meeting is an hour per week of iteration. For example, a two-week sprint starts with a two-hour planning meeting.

Start your sprint with a team of 5-9 people. It would be effective if the team is a mix of competencies and includes developers, testers, support, designers, business analysis. Name your sprint. Add a duration of the sprint end date.

It's always a good idea to check the Burndown Chart during a sprint. In Hygger software, the Burndown Chart helps you predict whether sprint will be completed in time. This lets you prevent risks and quickly react to difficult situations. To view this chart, click Burndown Chart near the sprint name. 

What is a Burndown Chart?
​A Burndown Chart is used to track the total work remaining for a sprint, and to project the likelihood of achieving the sprint goal. It demonstrates the actual and estimated amount of work that should be done in a sprint and includes the horizontal x-axis for time indicating and the vertical y-axis for issues indicating.
​As development is organized into time-boxed sprints in Scrum, at the beginning of the sprint, the team forecasts how much work during the sprint can be completed.
​The Burndown Chart tracks the completion of work throughout the sprint.
​Then the Chart helps to monitor how far off the team members are from completing the forecasted work by the end of the sprint.

Ideally at the end of the sprint all tasks should be completed. Release the sprint when you are ready.

In case your team didn’t manage to finish all of the items you have the options of releasing only tasks from a Done column or releasing all tasks from a board. 

Once you complete the sprint, you'll be able to review the Burndown Report.

What is a Sprint Report?
​Sprint Report demonstrates that the work is completed, not completed or any work added after the sprint started. The goal is to understand how the sprint forecast compared to the actual delivery.
​There are 3 basic questions here to ask:

After few sprints you can already see a value delivered in each sprint with Velocity Report. It will help you predict the amount of work the team can get done in future sprints. Velocity is calculated based on sprint data such as start and end, what you planned into it and what you managed to complete during the sprint. Velocity report is useful during your sprint planning meetings, to help you decide how much work you can commit to.

To view Velocity Report open Board menu in the right corner of a webpage > Click Velocity Report in a History Section.

Open list of Released Sprints to see their burndown reports, a statistics of completed and uncompleted tasks, of estimated Story Points/Hours and completed ones.

To have an access to this list, open board's menu (top right corner of a webpage) > Released Sprints.

What is a Daily Scrum Meeting?
​A daily Stand Up is the necessary part of Scrum. (In Kanban, the meeting is optional).
​During the short people-oriented meeting, team members share their results of the previous day and the current tasks’ statuses, giving the team a promise to do specific tasks this day. If there are any problems, they are also shared.
​Who needs to attend: A product owner + developers.
​How often and when: daily
​Duration: 10-15 minutes should be enough. Remember that it's not a conference or a long session. Standing up will keep the meeting short and give muscles relax.
​Goal: The main goal is tracking whether the team is able to execute all the iterations, or as early as possible identify the reasons why they cannot be executed.
​In general, every team member answers the following questions:

Have a daily team meeting for a quick status updates. The purpose of this is to see if anyone on your team is experiencing any bottleneck towards the completion of sprint tasks. 

What is a Sprint Retrospective Meeting?
​In simple words, retrospectives help teams understand what worked well and what did not. As Agile encourages getting rapid feedback that makes development culture and the product better, then such a meeting is required at the very end of an iteration.
​Retrospectives should be used not for complaints, it’s important to find solutions and create an action plan. That's why retrospectives provide the team with ongoing guidance to keep things going well.
​Who needs to attend: A Scrum Master, a product owner a development team. Usually, the meeting lasts 1 hour.
​Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can also benefit from occasional retrospectives. The questions during the meeting are:

The whole team attends the retrospective meeting, where you discuss how the sprint has been done.  You decide what and how you can improve your in the working process. The outcome of a retrospective is implemented in the next iteration. That is an effective way for a constant improvement. 

For more detailed guidance of using Sprint Board in Hygger, please visit our Help Center.