1. Introduction

Because of their extreme uncertainties, it is not always possible to gather all the projects requirements upfront.
A project management method is needed flexible enough to deal with many change requests that appear during the project and keep the project team productive.
There are a number of systems designed to provide these two properties and one of them are called Agile Frameworks and include Scrum, Kanban, FDD and XP.

1.1. Agile

The Agile Frameworks include Scrum, Kanban, FDD and XP.
Most of those frameworks promote teamwork, collaboration and process adaptability throughout the life-cycle of the project.
Most of those frameworks are iterative, incremental and evolutionary.

1.2. Scrum

Scrum is the most famous project management method of the Agile Frameworks.
It is the most broadly used one with over 80% of organisations using agile methodologies.
Scrum is based on a certain process composed of 5 Scrum Events combined with certain roles and artifacts.

1.3. Agile Manifesto

In 2001, while on a skiing vacation, a group of software developers published a manifesto that has since been considered the heart of all Agile methods.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions Over processes and tools
Working software Over comprehensive documentation
Customer collaboration Over contract negotiation
Responding to change Over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

1.4. Scrum vs Waterfall

Both Scrum vs and waterfall methodologies have their strengths, so it all depends on the type of project and its environment. Both approaches have effective planning followed by execution, monitoring and controlling.

In a nutshell:

It is better to use Scrum if there are lots of unknowns, where the projects are more complex, difficult to define detailed requirements upfront and therefore to define estimates at the beginning of the project.
It is better to use the traditional approaches when there are few unknowns, project is less complex, easy to define exact requirements upfront and therefore easy to estimate and plan the project from the very beginning.

Scrum Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

Scope is not clearly defined and Product will gradually appear during the project
Requirements change frequently and customer learns more about what they want as the project goes on
Activities cannot be well defined upfront
Estimating and planning is difficult
Process is iterative with numerous cycles and each cycle depends on the previous one
Success is mostly measured by customer satisfaction
Incremental results have value and can be used by users

Waterfall Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

Scope is clearly defined upfront with clear product description available upfront and similar projects were done before
Requirements are well defined up front with few change requirements expected during the project
Activities can be well defined upfront
Estimating is possible and reliable
Process is more long term and Project might be split into phases
Success is mostly measured by achieving the project goals ( time, cost, scope…)
Users cannot start using the products until the project is complete

1.5. Facts and Fictions about Scrum

Some of the most popular myths about Scrum include :

Developers are free to do what they want. Fact: developers work in a productive and predefined framework and the Scrum Master makes sure they are following Scrum.
Scrum gets rid of all paper work and allows the team to start developing right away. There are certain planning steps involved in every Scrum project and development can only start when the Sprint Backlog has been defined.
All requirements in the form of stories must be agreed before the Development Team is allowed to start working on the product. The Development Team can start working as soon as the initial stories of the Product Backlog are ready.
Scrum is very easy to implement even without training. Fact: In order to run their projects well, everyone involved should have a good understanding of Scrum to be able to
Scrum is just a set of simple rules. Fact: Scrum is a set of rules and a framework, plus a compatible work culture and ethic
Scrum does not require you to have a Business Case. Fact: The Product Owner is responsible for ensuring that there is a feasible reason for performing the project and each of the stories should be aligned with that
Scrum allows the Development Team to decide what will be delivered. Fact: A Team only decides on how to deliver; it is up to the Product Owner to determine what will be delivered
Scrum Master is like a project manager. Fact: There is no one similar to a traditional project manager in a Scrum project as the Scrum Master makes sure the Scrum framework is followed
The Product Owner is the project manager. Fact: The Product Owner only creates and maintains the Product Backlog, but does not manage the day to day activities of the Team
The Product Owner is a representative from the customer. Fact: The Product Owner is one of the people from the performing organization and the contact point with the customer.
Scrum tells us everything about managing projects. Fact: Scrum mostly deals with the definition and delivery of the products. Many of the business oriented aspects of the project are done outside Scrum.

2. Scrum Timeline

The first sprint can start when the business representatives have agreed to build something for the organization, providing a Vision Statement (idea, goal, vision) and a Product Roadmap (top level deliverables) that defines and describes the idea and the goal of the project.

The Vision Statement and the Product Roadmap are not part of Scrum, but are essential parts of managing projects and are covered in other Agile frameworks.

2.1 Pre-Sprint

What happens prior to the Sprints (Pre-Sprint):

The Vision Statement provides a concise description of the goals of the project which help the team stay focused on what is important from the organization point of view.
The Product Roadmap is an initial visual timeline of major product features to be delivered and is normally created by the Product Owner.
Stories are user requirements which will be turned into deliverable features, normally written by the Product Owner based on requirements from the customer.
All these stories make up the Product Backlog and the first Sprint can start as soon as there is enough stories defined, without the need for the Backlog to have 100% of the details.

2.2 Sprint Activities

What happens during the Sprints:

Sprint Planning meetings are held to plan what will go into a Sprint (a fixed period of time used to deliver parts of the final product). The Product Owner prioritizes these requirements and therefore decides on the contents of the Sprint Backlog.
These stories (features, functionalities or deliverables) make up the Sprint Backlog, so the Sprint Backlog is a list of all stories that will be developed in the next Sprint.
The Team breaks down (expands) these stories into tasks.
The Team then takes 2 to 4 weeks to deliver an agreed amount of stories.
The Team holds a Daily Scrum meeting (standup) of 15 minutes each day to collaborate with each other.

2.3 Post Sprint Activities

What happens towards the end of the Sprint:

At the end of the Sprint, the Team demonstrates the completed stories (products) to the customer in a Sprint Demo (aka Sprint Review) meeting.
The last activity is the Scrum Retrospective meeting, where the team reviews the Sprint and looks for ways of improving it, integrating lessons learned (e.g. 3 items to change the following sprint). The Scrum Master ensures that the Scrum process is followed entirely and offers coaching to everyone involved.

3.0 Scrum Roles

A Scrum Team consists of three roles:

Product Owner: 1 person, Full-time or part-time, Business oriented
Scrum Master: 1 person, Full-time or part-time, Scrum coach and facilitator
Development Team: 3 to 9 people, Full-time (recommended), Specialist

NOTE: It is possible for a single person to be assigned to more than one roles, but it is not recommended.

3.1. Scrum Team

About the Scrum Team:

There are only three roles in a Scrum and it is not allowed to define any other roles as it might harm the unity of the team.
The Scrum Team is a part of the performing organization, the company which executes the project either for itself or as a contractor for an external customer.

The Scrum Team has two essential characteristics:

Self-organized: the Scrum Team manages its own efforts rather than being managed or directed by others, as opposed to the other traditional methods where management efforts and specialist efforts are separated and centralized.
Cross-functional: the Scrum Team has all the expertise and competencies needed to get the job done without any help from outside the team.

These two characteristics are designed to optimize flexibility, creativity and productivity, needed for the Agile environment of Scrum.

3.2. Product Owner

Product Owner descriptions:

The Product Owner is a business oriented person, whose aim is to maximize the product value and the work of the Development Team.
The Product Owners role belongs to one person from the performing organization rather than from the client.
If there is a committee to handle the responsibilities of this role, there should still be only one person, the Product Owner, representing the committee.
They do not need to have application area knowledge of the project but focused on the business aspect and understand how the business operates.
The entire organization must respect the Product Owner decisions for the project to be successful and not even the CEO, should allow themselves to try to override those decisions.
No one should tell the Development Team what item to deliver, except for the Product Owner who sets and orders the items.
A Product Owner’s decisions might be influenced by others, but he/she must have the final say.

Product Owner responsibilities:

The Product Owner is responsible for the Product Backlog. The Product Backlog is a prioritized list of items (aka stories or user stories) that the client expects from the project; this is the main planning tool in Scrum.
It is also the responsibility of the Product Owner to make sure that each item (user story) is easy to understand for the Scrum Team, and other stakeholders.
Product Owners understand the business, so they can rank each Product Backlog item based on its return on investment as well as any other factor they find suitable for the business point of view of the project. The items will be sorted based on their value, so the higher they are on the list, the sooner they will be developed by the Development Team.
Product Owners should communicate effectively with the customer (the inevitable success factor in every project management method), and use the information to keep the Product Backlog updated with all the changes.
They also measure the performance of the project, forecast the completion date, and make this information transparent to all stakeholders.
A Product Owner might delegate some of his/her responsibilities (such as preparing the list of items for the Product Backlog) to the Development Team, but stays accountable for them.

3.3. Scrum Master

Scrum Master description:

The Scrum Masters is a servant-leader for the Scrum Team, which manages the Scrum process rather than the Scrum Team.
It is possible for a single person to be both Scrum Master, and a member of the Development Team, although this is not recommended.
Being a Scrum Master of a project might not occupy 100% of the time of a person; in this case, the best solution is to assign that same person as the Scrum Master in more than one project, rather than making them a member of the Development Team.

Scrum Master responsibilities:

The Scrum Master helps coaching the Scrum Team and ensures that all Scrum processes are implemented correctly.
The Scrum Master is responsible for removing impediments to the Development Team, facilitating their events.
The Scrum Master helps the Product Owners too, by helping or consulting them on finding techniques, communicating information and facilitating related events.
The Scrum Master leads the organization in its effort to adopt Scrum helping those outside the Scrum Team understand the appropriate interactions with the Scrum Team to maximize the value created by the Scrum Team.

3.4. The Development Team

Development Team description:

Members of the Development Team are application area experts.
They should be cross-functional, being able to implement all tasks for each Product Backlog item.
They are self-organized, finding their own way instead of receiving orders.
They are aligned with the goal of the project and should always work in a product-based way
It is highly recommended for members of the Development Team to work full-time on a single project, to stay focused and agile. The composition of the Development Team should not change so often. If there is a need to change team members, then this change should not happen during a Sprint and there will be a short-term decrease in productivity when the composition of the team changes.
Scrum is mostly effective when there are 3 to 9 Development Team members but for large projects, we can use a scaled model with multiple Scrum Teams. 3.5. Other Roles
All members should have the same role, and the same title: Development Team member.
Scrum is completely depended on collaboration and Product Owner. Development Team members should be united and completely aligned with the goal of the project.

Development Team responsibilities:

Members of the Development Team are responsible for delivering backlog items and managing their own efforts.
A task might be assigned to a single member throughout the Sprint, but the whole Development Team will be responsible and accountable for that task; no individual owns any task.
The Development Team delivers the final product of the project in step by step Increments, as defined in the Product Backlog.
Each Development Team member is responsible for all the outputs created in the Development Team, even though each of them might be focused on a specific set of tasks.

3.5. Other Roles

Other persons can also be involved but they are not considered internal to the project and should behave in certain way (e.g. respect how a Scrum project works)
When the project is not internal, the customer should be considered as another stakeholder and should understand/adopt the Scrum framework.
You may or may not have a separate customer, but you always have some external stakeholders (management, users, analytics…) and should consider them in your development style.

3.5. Scrum and Project Management

There is no traditional project manager role in Scrum.
Scrum Master responsibilities are very different than a traditional project manager.
There is no centralized project management in Scrum and the project management responsibilities are distributed among the three roles of Scrum and

4. Scrum Events

4.1. The Nature of Scrum Events

There are just five events in a Scrum Project:

Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events, development effort, and the maintenance of the Product Backlog.
Sprint Planning: first event inside a Sprint where the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them.
Daily Scrum: During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.
Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo).
Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.

Events description

The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed.
The events are designed to enable critical transparency, inspection, regularity and adaptation. We prefer to use these predefined meetings with fixed objectives and maximum durations instead of ad-hoc meetings, which most likely waste our time.
There is an essential concept in Agile methods, called time-box: a predefined fixed maximum duration of time. In order to maximize productivity, all of the Scrum events must be time-boxed.

4.2. The Time-Box Concept

Time-Box description:

Time-box is an essential concept in Scrum.
A time-box is a fixed period of time in which we freeze the target and work with full focus on certain tasks or objectives.
Time-boxed events repeat many times, until the final goal of the project is achieved.
All the changes are applied only when one time-box is finished and we are ready to start the next one.
The duration of a time-box should be agreed upon and fixed.

NOTE: We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions. For example, we are not allowed to say that we have a lot to do this time, so let’s increase the duration for this particular case. What we are allowed to say is based on the previous ten time-boxes, we realized that the duration of our time-boxes is not suitable, and a 30% increase in duration might better fit our needs. So, let’s increase them from now.

Time-Box benefits:

Time-Box is our way of staying focused and getting things done in an ever-changing environment.

4.3. Event 1: The Sprint

Sprint description:

Each Scrum project delivers the final product after a number of cycles, which are called Sprints.
An Increment is the sum of all Product Backlog items completed so far in a project and this Increment keeps getting bigger after each Sprint.
An Increment is developed in each Sprint, which is a potentially releasable part of the final product.
An Increment is the updated version of the previous Increment with new features and functionalities, which may or may not be actually released (put into use), but should always be potentially releasable.
Customers usually request changes when they see the Increment (during the Sprint Review), and we note these new requests in the Product Backlog.
Sprint is a time-boxed event, with a fix duration (set at the beginning of the project and do not change it frequently or occasionally). Sprints are usually fixed for one month or less (usually 2 to 4 weeks) as any longer would increase risk and complexity,
The sprint goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item among several Sprints.
The Product Owner has the authority to cancel a Sprint, usually when the Sprit Goal becomes obsolete, due to changes in the Product Backlog, strategies or approaches. When a Sprint is cancelled, the items that are Done will be reviewed and accepted, and the rest of the items (not started or partly complete) will be put back into the Product Backlog to be done in the future.

Sprint rules:

Scrum have a set of constraints designed to make it possible to focus and get things done including:

The Sprint Backlog items should not be changed once the Sprint is started
The Sprint Goal should not be changed.
The composition of the Development Team should not change during a Sprint.
The Product Owner and the Development Team might try to clarify and re-negotiate the scope as more is learned about the items to be delivered, but will not change the Sprint Backlog.
Each item (story) in the Product Backlog should normally be completed in a single Sprint as this is much easier to manage.
The Product Owner and the Development Team select a number of items from the top of the Product Backlog, that have already been prioritized by the Product Owner, and aim to get them Done (100% complete).
The Sprint Backlog items should be completed matching the definition of Done when the Sprint is over, and create an Increment.
A definition of Done should be agreed at the beginning of the project, and no item should be identified as Done, unless it fits the definition (even if 99.999% completed) as it would not be part of the Increment and it would not be demonstrated to the customer at the Sprint Review.

4.4. Event 2: Sprint Planning

Sprint Planning overview:

The first thing to do in each Sprint is the Sprint Planning, which is a time-boxed meeting attended by all 3 scrum roles and usually fixed to 8 hours for a one month Sprint or shorter for Sprints of less than a month.
The Development Team should estimate the capacity of work it can deliver in a single Sprint from the already ranked and ordered Product Backlog with the highest value items on top.
As soon as the Product Backlog is mature enough, with necessary number of stories the Development Team can start the first Sprint without waiting until the Product Backlog is 100% planned with all requirements gathered and cleared.
The Sprint Backlog will be ready at the end of this meeting and the Development Team should be able to describe what items they will deliver through the Sprint, and how they will do it.

Product Backlog to Sprint Backlog

The Development Team selects an appropriate number of items from the top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current Sprint.
The Product Owner also ensures that the items (stories) are easy to understand.
The amount of work for each item is estimated by the Development Team and the total amount of work of the selected Product Backlog items is close to the estimated capacity of the Development Team.

Sprint Goal:

Following the selection of the items to the Sprint Backlog, the Scrum Team should draft a Sprint Goal, an objective that should be met within the Sprint through the implementation of the Product Backlog.
The Scrum Goal provides guidance to the Development Team on why it is building the Increment.
This is a sample Sprint Goal: We are going to enable all the essential parts of the website store to set up a complete purchase process. This makes other features of the website more meaningful to the customer.
The Product Backlog should be ordered in a way that facilitates setting Sprint Goals.
The scope of the Sprint, which is made up of the items selected from the Product Backlog, might need to have more details through the Sprint, which should be aligned with the Sprint Goal, and likely re-negotiations for them should be done in presence of the Product Owner.

Detailed plan:

When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how they will deliver the items into a Done product Increment and realize the Sprint Goal.
Having a detailed plan for the first few days is enough and the Development Team can prepare detailed plans for the rest of the work later on.
A detail plan, as shown in the next figure, is a breakdown of a Product Backlog item into detailed tasks needed to be done in order to create the item.
Each task might have estimates, dependencies, and similar information to make tracking possible.
These tasks are defined by the Development, explaining how they will deliver each item, and are created at the Sprint Planning meeting or throughout the Sprint.

The Sprint Backlog consists of the following:

The Sprint Goal
Selected items from the Product Backlog, to be delivered through the Sprint
A detailed plan (tasks) for turning the selected items (stories) into Done Increment of the product and to realize the Sprint Goal

Sprint board:

The three Sprint Backlog elements (Sprint Goal, Product Backlog items selected for the Sprint, and the detailed plan) should be shown on the board.
The board should also have an easy way for tracking the tasks and items in To Do, Doing and Done columns.
Extra tasks have been added to the lower ranked items (items #3 to #5), which is the ongoing detail planning done through the Sprint.
Items in the Sprint Backlog usually have the same order they had in the Product Backlog, therefore, the Development Team should work on the higher ordered items first.

4.5. Event 3: Daily Scrum

Daily Scrum overview

The Daily Scrum is normally a 15 minute meeting for the Development Team to inspect the work since the last meeting, and synchronize their work and plan for the next 24 hours.
It must be held on a daily basis, ideally at the same time and place.
The Daily Scrum meeting should be held at the same time and same place throughout the Sprint, to minimize the complexity.
It is just for the Development Team and it is not a status meeting for all the stakeholders.
They should assess progress towards the Sprint Goal and forecast the likelihood of completing the items before the Sprint is over.

During the Daily Scrum, each member of the Development Team should answer these three questions:

What has been accomplished since the last meeting?
What will be done before the next meeting?
What obstacles are in the way?

Sprint progress:

The Development Team should also monitor Sprint progress each day and therefore it is a good idea for the Sprint board (wall chart) to be visible during the Daily Scrum meeting.
They can use a burn-down chart to track their remaining work and check to see if they are going to complete all items before the end of the Sprint.

4.6. Event 4: Sprint Review

Sprint Review overview:

At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a four hour meeting to present and inspect the Done items (the Increment) from the current Sprint.
The Development Team demonstrates and explains each one of the items.
The Development Team does not present an item, unless it is 100% complete based on the agreed definition of Done, which should be reviewed by the Product Owner before the Scrum Review.
The duration of this meeting is normally four hours for a one month Sprint. If the Sprints are shorter then this meeting will be proportionally shorter.

Sprint Review objectives:

Update the Product Backlog by marking off Done items as complete and add new items or change the existing ones if necessary.
The presentation of the Increment in this meeting is intended to collect feedback and raise change requests at the earliest time possible.
We welcome changes in Scrum and encourage them to be demanded, because it increases the satisfaction of the customer and will create a final product that better matches the needs of the customer.
The Product Owner discusses the status of the Product Backlog and the likely completion dates based on the progress.
Finally, the whole Scrum Team collaborates on revising the Product Backlog based on the output of the Sprint and the feedback received from the customer.

4.7. Event 5: Sprint Retrospective

Sprint Retrospective overview:

This meeting is normally three hours for a one month Sprint or shorter for proportionally shorter sprint.
After the Sprint Review and just before the end of the Sprint, another meeting will be held, aimed at process improvement (learning lessons), which is called Sprint Retrospective.
We will review (inspect) the Sprint, with regards to people, relationships, processes, and tools, and identify ways of improving them in the next Sprint.

Sprint Retrospective objectives:

There is a rule: we should always look for ways to improve. It does not matter how little the improvement is, there should be an improvement.
This meeting is a formal opportunity for improvement, even though we do not limit our improvement to the results of this meeting.

4.8. Activity: Product Backlog Grooming

Product Backlog Grooming overview:

Besides the time boxed event discussed before, there is also an ongoing activity in Scrum projects called Product Backlog grooming. It is the act of reviewing and revising Product Backlog items, which typically involves adding detail, estimates, and order to them.
The Product Owner is responsible for ordering (prioritizing) the items and the Development Team is responsible for estimating those items.
The main difference between this activity and the five Scrum events is that Scrum events are all time-boxed, but grooming is an ongoing activity that happens throughout the Sprint.
This activity should not consume more than 10% of the time of the Development Team.

4.9. Slack

It does not matter how much we work; what we produce is important.
We should be product-oriented, rather than activity-oriented.
One way of being productive, is to limit the work time to a reasonable amount, and have frequent off times.
That is why it is recommended (but not necessary) to have a slack between each two Sprints.
Let’s have a day or two off to recharge your batteries, read some relevant articles, and check out what other teams are doing.
Slacks can also be used for reading articles, taking part in courses or workshops, spending time on creative projects, etc.
We will be back after the slack, and repeat the same cycle over and over again, each time with a little improvement, until the final product of the project is delivered, and the client is completely satisfied with it.

5. Scrum Artifacts

Scrum artifacts of management activities are created to increase transparency of information related to ]project delivery and provide opportunities for inspection and adaptation.

There are six artifacts in Scrum:

Product Backlog: an ordered list of everything , aka all of the stories, that might be needed in the final product
Sprint Backlog: selected items (stories) from the Product Backlog to be delivered through a Sprint, along with the Sprint Goal and plans for delivering the items, aka the tasks needed to complete the Sprint Goal
Increment: set of all the Product Backlog items completed so far in the project, up to the end of a certain Sprint
Definition of Done: shared understanding of what it means for a story to be considered complete
Monitoring Project Progress: performance measurement and forecast for the whole project
Monitoring Sprint Progress: performance measurement and forecasts for a single Sprint

5.1. Artifact 1: Product Backlog

Product Backlog: ordered list of stories.

Product Backlog description:

The Product Backlog is an ordered list of everything that might be needed in the final product of the project (a wishlist of the expected final product).
All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder.
Every requirement and every change in the project will be reflected in the Product Backlog.
The Product Backlog is dynamically changing and improving; it is never complete.
The first Sprint can be started as soon as the Product Backlog has a sufficient number of stories defined and we do not wait until the Product Backlog is complete to start delivering the items
The Product Owner sets a number of factors (ROI) to determine the value of each item for the business, summarized into one importance value shown with each item.
The Product Backlog items are ordered based on their value, with the higher items at the top so it will be sooner delivered by the Development Team.
Top backlog items should be clear and detailed.
Each Product Backlog item should have a work estimate completed by the Development Team, to determine the team’s capacity for a given Sprint (number of items that could be completed).

Information available for a single Product Backlog item in a typical Scrum tool like JIRA include:

Story Name: the user story itself e.g. “As a user I want to login to my account to get access to my data”
Story Description: all the relevant information about the story so that the whole Scrum Team can have access to it.
Story Complexity: defines the nature of the story and used for Sprint Planning (usually the more complex a story is, the more uncertain its estimate would be)
Story Estimate: estimated volume of the story determined by the Development Team.
Assignments: story can be assigned to any person in the team (even if whole Scrum Team would remain accountable for it)
Tasks: breakdown the story into tasks (detailed planning) and track them separately.
Comments: each member of the Scrum Team can leave comments and collaborate with others

Optional fields:

Categories: easy way to ease of access and maintenance when multiple stories in the backlog (act as a normal WBS)
Colours: You can set different colours to each story to differentiate them visually in the Scrum board. This is another way of grouping/categorizing items.
Tracker: You can record time spend on each story for further analysis, refining estimates, billing, etc.
Attachments: attach relevant documents and use the software as a document management tool.
Alerts: optional custom alerts can be set here
Due Date: optional custom due dates to track stories
custom fields

NOTE: Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible.

Product Backlog process guidelines:

The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming and it should not consume more than 10% of the time of the Development Team.
The Product Backlog is created more based on discussion rather than documentation.
The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders.
It is common to break the large stories into two or more stories later.
There should be only one Product Backlog, no matter how many Scrum Teams are working on the project, as the Backlog is a representation of the scope of the final product.

5.2. Artifact 2: Sprint Backlog

Sprint Backlog description:

The Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint.
The Sprint Backlog is frozen (means that items cannot be added or removed during the Sprint) after the Sprint Planning and the Development Team will focus on delivering an Increment of Done based on this plan.
It might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner.
The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues.

The Sprint Planning event consists of the following:

Backlog stories: a number of items selected from the top of the Product Backlog, based on their estimated work and the estimated capacity of the Development Team
Sprint Goal: help describe the real meaning of the items and direct the efforts of the Development Team
Detailed plan: for delivery of the items and realization of the Sprint Goal during the Sprint

5.3. Artifact 3: Increment

Increment description:

An Increment is a sum of all completed Product Backlog items at the end of a Sprint.
Each Increment must be Done and releasable.
The Product Owner may or may not release a certain Increment, but it should be releasable (shippable).
The number of stories in the Product Backlog decreases Sprint by Sprint, as the number of features in the Increments increases.
The Increment concept is cumulative meaning that each Increment also contains the features of the previous ones.

5.4. Artifact 4: Definition of Done

DOD description:

There should be a shared understanding of what it means for a piece of work to be Done.
This definition of Done must be discussed and agreed upon by the Scrum Team at the beginning of the project so that future Increments would be releasable.
When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of Done for all teams (might be working on items of different natures) so each Scrum Team will define its own definition of Done and delivers its items based on that definition.
The integration of those definitions of Done should be capable of creating a potentially releasable Increment in the project level.

5.5. Artifact 5: Monitoring Project Progress

Monitoring Project Progress description:

The Project burn-down chart helps visualize progress of the whole project
The Product Owner is responsible to monitor the progress of the whole project toward its goal.
This should be done at least once per Sprint Review.
The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints, and forecasts the completion date of the project.
All stakeholders should have access to this information.
The project burn-down chart shows the amount of remaining work, instead of the amount of completed work; therefore, the line for actual performance goes downward as we proceed and the faster it goes down, the happier we will be!
The vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed.
We usually add another line to acts as our planned progress which represent the uniform distribution of the volume of the work across the initially estimated number of sprints

5.6. Artifact 6: Monitoring Sprint Progress

Monitoring Sprint Progress description:

Besides the monitoring done for the whole project, we should also monitor the progress of each single Sprint throughout its life.
This is the responsibility of the Development Team.
It should be done at least once per Daily Scrum.
This information is used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog.
The Sprint progress information can be represented by a burn-down chart, and this chart can be a part of the Sprint board, where everyone can see.

Professional Scrum Master