Scrum Basics

Scrum is an iterative and incremental agile software development methodology for managing product development. —- Wikipedia

Scrum is adaptive, iterative, fast, flexible and effective which supports all kinds of projects. It ensures transparency in communication and creates collective accountability and progress.


Image from Udemy course "Basics of Scrum, Agile and Project Delivery"

A Scrum project involves a collaborative effort to create a new product, service, or other result as defined in the Project Vision Statement.

Sprints are short time spans in which a certain amount of work must be done. A Sprint generally lasts between one and six weeks. Short, highly focused Daily Standup Meetings are conducted in Sprints.

In the Sprint Review Meeting, the product owner and relevant stakeholders are provided a demonstration of the Deliverables. They only accept the Deliverables only if they meet the Predefined Acceptance Criteria.

Each Sprint ends with a Retrospect Sprint Meeting where the team member discuss the ways to improve processes and performance as they move forward to the subsequent Sprint.

Story and Defect

Check out the post “Should Defects Be Considered User Stories?” for more information.


A user story is a description of functionality at the lowest level of granularity that can be independently developed and demonstrated to generate feedback.

User stories and story points

We also need to assess the size of the software being developed based on story poitns. The size of the user story in terms of story points is decided mainly by:

  • Complexity (related to development)
  • Doubt (clarity on what is really needed)
  • Effort (work needing to be done)

User stories and business value

Every user story, when developed, must add to the business value as endorsed by the product owner. The business value of the user story decides its place in the prioritized product backlog.


A defect is an understanding of deviation from the expectation. The severity and effect of a defect will vary from “ignorable” to “show-stopper.”

Defect and story points

You may not consider defects as “business value work,” but you need to size them by story points for an accurate measure of velocity.

Keep in mind that, we should separate “delivery of business value“ from “velocity of the team“. While the former is driven by the product owner, the latter is driven by the team.

Find out more information in this stackoverflow post.