Project Vs Process, Project Life Cycle

It is cycle is when you split up a project into different phases.

A simple project can have only one phase. It can be broken into several phases. When several
phases are available can be executed sequential or may also have overlapped relationships.
Process is a set procedure that involves a sequence of steps that need to be taken in order to
produce a result,
Project involves one-time events that typically have a defined start and end point.
Project management works to implement change that brings value to the company. The
technique is temporary and works toward meeting a defined goal or objective set by the
company within a clearly set budget and timeline.

Requirement gathering vs elicitation, Stakeholder, SME, Sponsor, Project

Manager, Customer/End User/Business User/Client.

Requirement gathering vs elicitation: ------ The process of collecting requirements from

stakeholders and other sources.
Elicitation is an art of extraction of information while gathering is simply gathering the
visible information.

Characteristics:

 Focused on collecting information.

 Typically involves documenting what stakeholders say they need.
 Often a one-way communication from stakeholders to the project team.
 Techniques: Interviews, surveys, document analysis.

Requirement Elicitation:

 Definition: The practice of actively engaging with stakeholders to uncover their

needs and expectations.
 Characteristics:
o Involves interaction and collaboration.
o Aims to discover hidden or unstated requirements.
o Uses techniques to prompt, guide, and uncover deeper insights.
o Techniques: Workshops, brainstorming sessions, focus groups, observation,
prototyping.

Stakeholder:

1
  Definition: Anyone who has an interest in or is affected by the project.
 Examples: Clients, end users, project team members, sponsors, regulatory bodies.
 Role: Provide requirements, feedback, and support; can influence the project’s
success.

Subject Matter Expert (SME):

 Definition: An individual with deep knowledge of a particular area relevant to the

project.
 Role: Provide expertise and insights; validate technical details; ensure requirements
are feasible and aligned with industry standards.

Sponsor:

 Definition: An individual or group who provides resources and support for the project
and is accountable for its success.
 Role: Approve project objectives; secure funding; provide high-level direction;
resolve conflicts and ensure project alignment with business goals.

Project Manager:

 Definition: The person responsible for planning, executing, and closing the project.
 Role: Develop and manage the project plan; coordinate resources; monitor progress;
manage risks; ensure project objectives are met.

Customer/End User/Business User/Client:

 Customer:
o Definition: The entity purchasing or receiving the project’s deliverables.
o Role: Define requirements; approve deliverables; provide feedback.
 End User:
o Definition: The individual who will use the product or service resulting from
the project.
o Role: Provide practical insights into usability and functionality; participate in
user testing.
 Business User:
o Definition: A user who represents the business side of the organization and
uses the project’s deliverables to perform their job.
o Role: Ensure the deliverables meet business needs; provide feedback from a
business perspective.
 Client:
o Definition: The individual or organization that commissions and pays for the
project.
o Role: Define project scope and requirements; provide funding; approve
deliverables.

What is Business analysis and who is a Business Analyst. Day to day

activities of a BA.

2
Business analysis is a discipline focused on identifying business needs and determining
solutions to business problems.
It involves understanding how organizations function, including their processes, structures,
and policies, to improve their operations.
Business analysts (BAs) play a key role in bridging the gap between IT and business
stakeholders, ensuring that technology solutions meet business goals.

A Business Analyst (BA) is a professional who acts as a bridge between business

stakeholders and IT teams, ensuring that technology solutions meet business needs and
requirements. They play a crucial role in identifying business problems, analyzing
requirements, and proposing solutions that improve business processes and systems.

Day-to-Day Activities of a Business Analyst

1. Stakeholder Meetings:
o Conducting meetings with stakeholders to gather requirements and understand
business needs.
o Facilitating workshops and discussions to define project scope and objectives.
2. Requirements Elicitation:
o Using techniques like interviews, surveys, and observations to gather detailed
requirements.
o Analyzing and documenting business processes, workflows, and systems.
3. Documentation:
o Creating and maintaining comprehensive documentation such as Business
Requirements Documents (BRDs), Functional Requirements Documents
(FRDs), and use cases.
o Preparing process flow diagrams, wireframes, and other visual aids.
4. Analysis and Modeling:
o Analyzing business processes and identifying areas for improvement.
o Developing process models, data models, and use case diagrams to represent
current and future states.
5. Solution Assessment:
o Evaluating potential solutions and technologies to address business needs.
o Conducting feasibility studies, cost-benefit analysis, and risk assessments.
6. Collaboration with IT Teams:
o Working closely with developers, testers, and project managers to ensure
requirements are understood and implemented correctly.
o Participating in design and development meetings to provide business
perspective.
7. Testing and Validation:
o Developing test plans and test cases to validate that solutions meet business
requirements.

3
 o Participating in user acceptance testing (UAT) and providing feedback on
system functionality.
8. Communication and Reporting:
o Communicating progress, issues, and changes to stakeholders and project
teams.
o Preparing status reports, presentations, and updates for management.
9. Change Management:
o Assisting in the development of change management strategies and plans.
o Supporting stakeholders through the transition and ensuring they are trained
on new systems and processes.
10. Continuous Improvement:
o Monitoring implemented solutions to ensure they continue to meet business
needs.
o Identifying opportunities for further improvement and optimization.
11. Professional Development:
o Staying updated with industry trends, best practices, and new technologies.
o Attending training sessions, conferences, and workshops to enhance skills and
knowledge.

A BA’s role can vary depending on the organization and project, but their primary focus
remains on ensuring that business needs are effectively translated into technology solutions.

Scope creep (also called requirement creep, or kitchen sink syndrome) in project
management is continuous or uncontrolled growth in a project's scope, generally experienced
after the project begins.[1] This can occur when the scope of a project is not properly defined,
documented, or controlled. It is generally considered harmful

scope is the total amount of work that needs to be done to complete a project. To define it,
project managers must break down the project into the tasks and deliverables that’ll be
executed to meet goals and stakeholder requirements and deliver the project successfully.

Gap analysis is a method used to compare the current state of a process, product, or
organization with its desired future state, identifying the gaps that need to be bridged to
achieve the desired outcome.

SDLC is a systematic process for planning, creating, testing, and deploying an information
system. It provides a structured approach to software development, ensuring that high-quality
software is delivered efficiently.

1. Planning:
o Define the scope and purpose of the project.
o Conduct feasibility studies and gather requirements.

4
 2. Analysis:
o Analyze end-user requirements.
o Create detailed system and software requirements.
3. Design:
o Develop architectural designs.
o Create detailed designs for components, user interfaces, and data models.
4. Implementation (Coding):
o Write the actual code based on the design documents.
o Integrate different modules.
5. Testing:
o Perform various tests (unit, integration, system, acceptance) to ensure the
software meets requirements.
o Identify and fix defects.
6. Deployment:
o Install the software in a production environment.
o Ensure it is fully operational.
7. Maintenance:
o Provide ongoing support and maintenance.
o Update and enhance the software as needed.

Agile vs. Waterfall

Waterfall Methodology:

Definition: Waterfall is a linear and sequential approach to software development, where

each phase must be completed before the next one begins.

Characteristics:

 Sequential Phases: Planning, analysis, design, implementation, testing, deployment,

and maintenance.
 Fixed Requirements: Requirements are defined at the beginning and remain
unchanged.
 Documentation: Extensive documentation at each phase.
 Review at Phase End: Each phase ends with a review to determine if the project can
proceed to the next phase.

Advantages:

 Simplicity: Easy to understand and manage.

 Clear Milestones: Well-defined stages and milestones.
 Structured Approach: Suitable for projects with clear, unchanging requirements.

Disadvantages:

 Inflexibility: Difficult to accommodate changes once the project is underway.

 Late Testing: Bugs and issues are found late in the process.
 Customer Involvement: Limited customer involvement after the initial phase.

Agile Methodology:

5
Definition: Agile is an iterative and incremental approach to software development that
emphasizes flexibility, customer collaboration, and rapid delivery of functional software.

Characteristics:

 Iterative Development: Software is developed in small, iterative cycles called

sprints.
 Flexible Requirements: Requirements can evolve and change throughout the project.
 Customer Collaboration: Continuous involvement and feedback from customers.
 Cross-Functional Teams: Collaborative teams with diverse skill sets.

Advantages:

 Flexibility: Easily accommodates changes and new requirements.

 Early and Continuous Delivery: Regular delivery of small, functional increments.
 Customer Satisfaction: High customer involvement and feedback.

Disadvantages:

 Less Predictability: Difficult to predict project timelines and costs.

 Scope Creep: Risk of uncontrolled changes to project scope.
 Requires Discipline: Teams need to be highly skilled and disciplined.

Scrum and Sprint

Scrum:

Definition: Scrum is a framework within Agile for developing, delivering, and sustaining
complex products. It focuses on iterative progress through sprints and emphasizes teamwork,
accountability, and continuous improvement.

Key Roles:

 Product Owner: Represents the stakeholders and is responsible for defining and
prioritizing the product backlog.
 Scrum Master: Facilitates the Scrum process, removes impediments, and ensures the
team adheres to Scrum practices.
 Development Team: A cross-functional group responsible for delivering the product
increment.

Artifacts: a man-made object taken as a whole

 Product Backlog: A prioritized list of features, enhancements, and bug fixes.

 Sprint Backlog: A list of tasks to be completed during a sprint, derived from the
product backlog.
 Increment: The working product at the end of a sprint, which must be potentially
shippable.

Events:

6
  Sprint Planning: Meeting to plan the upcoming sprint, defining the sprint goal and
selecting backlog items to work on.
 Daily Scrum: Short, daily meetings to discuss progress, plans for the day, and any
impediments.
 Sprint Review: Meeting at the end of the sprint to demonstrate the increment to
stakeholders and gather feedback.
 Sprint Retrospective: Meeting to reflect on the sprint and identify areas for
improvement.

Sprint: Sprint meaning in Hindi (हिन्दी मे मीनिंग) is बहुत तेज़ी से दौड़ना

Definition: A sprint is a time-boxed iteration, usually lasting 1-4 weeks, during which the
Scrum team works on completing specific tasks from the sprint backlog.

fixed-length iteration and an agile scrum event, during which a cross-functional scrum team
works to complete a set amount of work. Generally, a sprint is time-boxed to 2 to 4 weeks
duration

Characteristics:

 Fixed Duration: Each sprint has a consistent duration.

 Sprint Goal: A clear, achievable goal defined during sprint planning.
 Deliverable: A potentially shippable product increment at the end of the sprint.
 Review and Retrospective: Each sprint ends with a review of the product increment
and a retrospective on the process.

Benefits:

 Focus: The team focuses on a specific set of tasks within a defined time frame.
 Continuous Improvement: Regular retrospectives encourage ongoing process
improvement.
 Adaptability: Sprints allow for regular reassessment and adaptation of the product
and process

UML Diagram, Use Case and Business Process Model.

2. Use Case Diagram

Use Case diagrams represent the functional requirements of a system and the interactions
between users (actors) and the system.

Example: Use Case Diagram for an E-commerce System

 Actors: Customer, Admin

 Use Cases: Browse Products, Add to Cart, Checkout, Manage Orders, Process
Payment

UML Diagram (Unified Modeling Language)

7
UML diagrams are used to visualize, specify, construct, and document the artifacts of
software systems. There are several types of UML diagrams, including:

 Class Diagram: Describes the structure of a system by showing its classes, attributes,
operations, and the relationships among the objects.
 Sequence Diagram: Shows how objects interact in a particular scenario of a use case.
 Activity Diagram: Represents workflows of stepwise activities and actions with
support for choice, iteration, and concurrency.

3. Business Process Model

Business Process Models provide a visual representation of the sequence of activities or tasks
in a business process.

Example: Business Process Model for Order Processing

1. Order Placement: Customer places an order.

2. Order Confirmation: System confirms the order.
3. Payment Processing: System processes the payment.
4. Order Fulfillment: Warehouse prepares the order.
5. Shipping: Order is shipped to the customer.
6. Order Completion: Order is marked as complete.

A Business Requirements Document (BRD) is a formal document that outlines the business
requirements for a project or system. It serves as a guide for stakeholders to understand the
objectives, scope, and requirements of the project. A BRD typically includes the following
sections:

1. Introduction
2. Business Objectives
3. Project Scope
4. Stakeholders
5. Business Requirements
6. Functional Requirements
7. Non-functional Requirements
8. Assumptions
9. Constraints
10. Dependencies
11. Acceptance Criteria
12. Appendices

Here’s an outline for a BRD, using an e-commerce system as an example:

1. Introduction

Purpose: To document the business requirements for the development of an e-commerce

system that allows users to browse products, add them to a cart, and make purchases online.

Background: The e-commerce industry has seen significant growth, and the company aims
to tap into this market by developing an online shopping platform.

8
2. Business Objectives

 Increase sales by providing an online shopping platform.

 Enhance customer experience by offering a user-friendly interface.
 Streamline order processing and payment.

3. Project Scope

In Scope:

 User registration and login

 Product catalog browsing
 Shopping cart functionality
 Order placement and payment processing
 Order tracking

Out of Scope:

 Physical store inventory management

 In-store purchase functionalities

4. Stakeholders

 Project Sponsor: John Doe, VP of Sales

 Project Manager: Jane Smith
 Development Team
 Marketing Team
 Customer Support Team

5. Business Requirements

BR1: User Registration and Login Users must be able to register with an email and
password, and log in to access their account.

BR2: Product Catalog Browsing Users must be able to browse products by categories,
search for products, and view product details.

BR3: Shopping Cart Management Users must be able to add products to a shopping cart,
view the cart, and update quantities.

BR4: Order Placement Users must be able to place an order by providing shipping details
and selecting a payment method.

BR5: Payment Processing The system must support various payment methods including
credit cards, PayPal, and others.

BR6: Order Tracking Users must be able to track the status of their orders.

6. Functional Requirements

9
FR1: User Interface The system must provide an intuitive and user-friendly interface for all
functionalities.

FR2: Authentication The system must support secure user authentication and password
management.

FR3: Product Management The system must allow administrators to add, update, and
delete products from the catalog.

FR4: Cart Management The system must allow users to add products to the cart, remove
products, and update quantities.

FR5: Order Management The system must handle order placement, confirmation, and
tracking.

FR6: Payment Gateway Integration The system must integrate with payment gateways to
process payments securely.

7. Non-functional Requirements

NFR1: Performance The system must handle up to 10,000 concurrent users.

NFR2: Security The system must comply with PCI-DSS standards for payment processing.

NFR3: Usability The system must be accessible and easy to use for all users.

NFR4: Scalability The system must be scalable to accommodate future growth.

8. Assumptions

 Users will have access to the internet.

 Payment gateways will be available for integration.

9. Constraints

 The project must be completed within six months.

 The budget is limited to $500,000.

10. Dependencies

 Integration with third-party payment gateways.

 Availability of the development team.

11. Acceptance Criteria

 The system must pass all functional and non-functional tests.

 The system must be user-friendly and meet usability standards.
 The system must successfully process payments and track orders.

12. Appendices

10
  Glossary of Terms
 User Interface Mockups
 Detailed Use Case Descriptions

Functional requirements describe what the system should do. They define specific behaviors
or functions of the system. These requirements are usually captured in a requirements
specification document and include details about data input, data processing, and data output.

Examples of Functional Requirements:

1. User Authentication:
o The system shall allow users to register with an email and password.
o The system shall allow users to log in using their email and password.
2. Product Catalog Management:
o The system shall display a list of products.
o The system shall allow users to search for products by name, category, and
price.
3. Shopping Cart Functionality:
o The system shall allow users to add products to the shopping cart.
o The system shall display the total price of the items in the shopping cart.
4. Order Processing:
o The system shall allow users to enter shipping details.
o The system shall allow users to choose a payment method.
o The system shall process the payment and generate an order confirmation.

Non-functional Requirements

Non-functional requirements describe how the system performs a certain function. These
requirements define system attributes such as performance, usability, reliability, etc.

Examples of Non-functional Requirements:

1. Performance:
o The system shall handle up to 10,000 concurrent users.
2. Security:
o The system shall encrypt all sensitive user data.
o The system shall comply with PCI-DSS standards for payment processing.
3. Usability:
o The system shall provide a user-friendly interface that is easy to navigate.
o The system shall be accessible to users with disabilities.
4. Scalability:
o The system shall be able to scale up to support future growth.
5. Reliability:
o The system shall have an uptime of 99.9%.

Requirement vs Specification

11
  Requirement: A requirement is a high-level description of what the system should
do. Requirements are typically written in a language that is easily understandable by
stakeholders and serve as a communication tool between stakeholders and the
development team.

Example of a Requirement:

o The system should allow users to place an order online.

 Specification: A specification is a detailed, precise, and unambiguous description of

the system's behavior. Specifications provide detailed information that developers and
testers use to build and validate the system.

Example of a Specification:

o The system shall allow users to place an order by providing shipping

information, selecting a payment method, and confirming the order. The order
confirmation should include a unique order ID, the total amount, and an
estimated delivery date.

Detailed Comparison:

 Level of Detail:
o Requirements are typically high-level and broad.
o Specifications are detailed and precise.

 Audience:
o Requirements are meant for stakeholders, including business analysts, project
managers, and customers.
o Specifications are meant for developers, testers, and technical teams.

 Purpose:
o Requirements capture what the stakeholders need and expect from the system.
o Specifications provide a clear, detailed guide on how to implement the system.

 Nature:
o Requirements can be both functional and non-functional.
o Specifications are more technical and detailed, often expanding on functional
requirements.

Example Breakdown:

Requirement:

 The system should allow users to log in securely.

Specification:

 The login functionality shall require the user to enter their email and password.
 The system shall use HTTPS for secure communication.
12
  Passwords shall be hashed and stored securely in the database.
 The system shall lock the user account after five failed login attempts and send an
email notification to the user.

User Story, Product Backlog in Scrum, Velocity and Burn down chart,
Planning Poker, Story Point in Agile, Epic, Task, Acceptance Criteria.

User Story

A user story is a simple description of a feature or functionality from the perspective of the
end-user. It typically follows the format: "As a [type of user], I want [an action] so that [a
benefit]."

Example:

 User Story: As a shopper, I want to be able to add items to my shopping cart so that I
can purchase multiple items at once.

Product Backlog

The product backlog is a prioritized list of user stories, features, and improvements that the
development team will work on. It is managed by the Product Owner and is continuously
updated based on feedback and changes in requirements.

Example:

1. Add items to shopping cart

2. User registration and login
3. Search for products by category
4. Checkout and payment processing
5. Order history and tracking

Velocity

Velocity is a measure of the amount of work a team can complete in a single sprint. It is
typically calculated by summing up the story points of all completed stories in a sprint.

Example:

 If a team completes user stories worth 20 story points in one sprint, their velocity is
20.

Burn Down Chart

A burn down chart is a graphical representation of work left to do versus time. It shows the
progress of a sprint or a project by plotting the remaining work (in story points or tasks) on
the vertical axis against time on the horizontal axis.

13
Example:

 The chart starts with the total story points at the beginning of the sprint and decreases
as work is completed each day.

Planning Poker

Planning Poker is a consensus-based technique for estimating the effort or complexity of user
stories. Each team member selects a card with a number (representing story points) in a
private session, and then all reveal their cards simultaneously. Discussions follow until a
consensus is reached.

Example:

 Team members use cards with values like 1, 2, 3, 5, 8, 13, etc., to estimate a user
story's effort.

Story Point

Story points are units of measure for expressing the overall effort required to implement a
user story. They are relative and based on complexity, risk, and effort.

Example:

 A simple user story like "As a user, I want to log in using my email and password"
might be assigned 2 story points, while a more complex story like "As a user, I want
to view my order history" might be 5 story points.

Epic

An epic is a large user story that can be broken down into smaller user stories. It often
represents a significant piece of functionality that spans multiple sprints.

Example:

 Epic: Implement user account management

o User Story 1: As a user, I want to register an account.
o User Story 2: As a user, I want to reset my password.
o User Story 3: As a user, I want to update my profile information.

Task

A task is a smaller, actionable piece of work that is necessary to complete a user story. Tasks
are often broken down further during sprint planning.

Example:

 For the user story "As a shopper, I want to be able to add items to my shopping cart":
o Task 1: Design the shopping cart interface.

14
 o Task 2: Implement the add-to-cart functionality.
o Task 3: Write unit tests for the shopping cart.

Acceptance Criteria

Acceptance criteria are the conditions that a user story must satisfy to be considered
complete. They provide clear requirements and help ensure that the story meets the user's
needs.

Example:

 User Story: As a shopper, I want to be able to add items to my shopping cart.

o Acceptance Criteria:
 The shopping cart icon updates to show the number of items.
 Items added to the cart are listed in the cart view.
 The total price is correctly calculated and displayed.
 Users can remove items from the cart.
 Changes to the cart are saved when the user navigates away from the
page.

These concepts and practices help Agile teams to effectively manage and execute their
projects, ensuring that they deliver valuable, high-quality software to their users.

Test Case

A test case is a detailed procedure or set of conditions under which a tester will determine
whether a system under test satisfies requirements or works correctly. It includes specific
steps, inputs, expected outputs, and execution conditions.

Example:

 Test Case: Verify user login functionality.

o Steps:
1. Navigate to the login page.
2. Enter valid username and password.
3. Click on the login button.

 Expected Result: User should be logged in successfully and directed

to the dashboard.

Unit Testing

Unit testing is a type of testing that focuses on testing individual units or components of a
software application in isolation from the rest of the system. It is typically conducted by
developers to ensure that each unit of code behaves as expected.

Example:

 Component: Login Service

15
  Unit Test: Verify that the login service correctly authenticates a user with valid
credentials and rejects invalid ones.

Functional Testing

Functional testing is a type of testing that verifies that each function of the software
application operates in conformance with the requirement specification. It tests the functional
aspects of the software system.

Example:

 Function: Add to Cart

 Functional Test: Ensure that users can add items to their shopping cart, view the cart
contents, and proceed to checkout.

Regression Testing

Regression testing is a type of testing that ensures that previously developed and tested
software still performs correctly after a change or addition has been made to it. It helps
identify unintended side effects of changes.

Example:

 Change: Update user profile interface

 Regression Test: Run tests to ensure that the update did not break existing
functionalities such as login, account settings, or order history.

User Acceptance Testing (UAT)

User Acceptance Testing (UAT) is a type of testing performed by end-users or stakeholders

to verify that a software application meets their expectations and is ready for deployment. It
validates whether the system meets the business requirements and is usable in real-world
scenarios.

Example:

 Scenario: As a customer, I want to test the shopping and checkout process on the e-
commerce website.
 UAT Test: Perform end-to-end tests to ensure that the shopping cart works correctly,
payments are processed accurately, and order confirmation emails are received.

Summary:

 Test Case: Detailed procedure to determine if a system satisfies requirements.

 Unit Testing: Testing individual units or components of the software.
 Functional Testing: Verifying that software functions as expected.
 Regression Testing: Testing to ensure existing functionalities are not affected by
changes.
 User Acceptance Testing (UAT): Testing by end-users to validate that the software
meets business requirements.

16
These testing practices are essential in ensuring the quality and reliability of software systems
before they are deployed to users or customers.

3.5

MOSCOW Prioritization

MOSCOW is a prioritization technique used to categorize requirements or features into four

priority groups: Must have, Should have, Could have, and Won't have (this time). It helps
stakeholders and teams clarify the importance and urgency of requirements.

 Must have (M): Critical requirements that are essential for the system or project to be
considered successful.
 Should have (S): Important requirements that are not critical but add significant value
to the system.
 Could have (C): Desirable requirements that are nice to have but can be deferred if
necessary.
 Won't have (this time) (W): Requirements that are explicitly excluded from the
current scope but may be considered in the future.

Example:

 Must have: The system must support user registration and login functionality.
 Should have: The system should provide an option for users to reset their passwords.
 Could have: The system could include social media integration for user
authentication.
 Won't have (this time): The system won't include a mobile app version in the initial
release.

5W1H Analysis

5W1H is a technique used to gather information by asking six key questions: Who, What,
When, Where, Why, and How. It helps in understanding the complete context and scope of a
requirement, issue, or project.

 Who: Identifies the stakeholders, users, or individuals involved.

 What: Specifies the objectives, requirements, or actions.
 When: Determines the timeline, deadlines, or schedule.
 Where: Defines the location, environment, or context.
 Why: Provides the reasons, justifications, or motivations.
 How: Describes the process, methods, or steps involved.

Example:

 Who: Who are the primary users of the new e-commerce platform?
 What: What features should be included in the initial release of the platform?
 When: When is the deadline for completing the development of the platform?
 Where: Where will the platform be hosted and accessed by users?
 Why: Why is it important to integrate a secure payment gateway into the platform?

17
  How: How will user feedback be collected and incorporated into future updates of the
platform?

Application in Requirements Gathering:

 MOSCOW helps prioritize requirements based on their importance and impact on

project success.
 5W1H ensures that all aspects and details of requirements or projects are thoroughly
understood and documented.

These techniques are valuable in ensuring that projects are well-defined, requirements are
clear and prioritized, and stakeholders have a comprehensive understanding of what needs to
be delivered.

Product Backlog Item (PBI), Prioritizing the Product Backlog, ‘DONE’ in

SCRUM, Story Grooming, INVEST, SCRUM Ceremonies, SPRINT
Planning, Review/Retrospective, Team and Roles in SCRUM, Product
Owner, SCRUM Master, SCRUM Team

Product Backlog Item (PBI)

A Product Backlog Item (PBI) is a single item in the product backlog that represents a
feature, enhancement, or fix that needs to be developed. PBIs are often user stories but can
also include technical tasks, bugs, or other work items.

Prioritizing the Product Backlog

Prioritizing the Product Backlog involves ordering PBIs based on their value to the product
and stakeholders. The Product Owner is responsible for prioritizing items, considering factors
such as business value, customer needs, dependencies, and risks.

'DONE' in Scrum

'DONE' in Scrum refers to the criteria that a PBI must meet to be considered complete. This
typically includes meeting the acceptance criteria, passing testing, and being potentially
shippable. It ensures that work items are finished and ready for review.

Story Grooming (or Backlog Refinement)

Story Grooming, also known as Backlog Refinement, is the process where the Scrum Team
collaboratively reviews and refines PBIs in the product backlog. It involves breaking down
large items, adding details, estimating effort (story points), and preparing items for upcoming
sprints.

INVEST Criteria for User Stories

18
INVEST is an acronym that defines a set of criteria for writing good user stories:

 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

These criteria help ensure that user stories are clear, manageable, and contribute value to the
product.

Scrum Ceremonies

Scrum ceremonies are formal events that facilitate the various activities of the Scrum
framework:

 Sprint Planning: Plan the work to be done in the upcoming sprint.

 Daily Standup: Daily meeting to synchronize activities and identify any
impediments.
 Sprint Review: Demonstrate the work completed during the sprint and gather
feedback.
 Sprint Retrospective: Reflect on the sprint and identify improvements for the next
sprint.

Sprint Planning

Sprint Planning is a meeting at the beginning of each sprint where the Scrum Team plans the
work to be completed during the sprint. It involves selecting PBIs from the product backlog,
breaking them down into tasks, and estimating effort.

Review/Retrospective

 Sprint Review: A meeting at the end of the sprint where the Scrum Team
demonstrates the completed work to stakeholders and gathers feedback.
 Sprint Retrospective: A meeting held after the Sprint Review where the Scrum
Team reflects on the sprint process, identifies what went well and what could be
improved, and plans adjustments for future sprints.

Team and Roles in Scrum

 Product Owner: Represents the stakeholders and is responsible for maximizing the
value of the product. They prioritize the backlog and ensure the team delivers features
with the highest business value.
 Scrum Master: Facilitates the Scrum process, removes impediments, and ensures the
team adheres to Scrum principles and practices. They help the team achieve self-
organization and continuous improvement.
 Scrum Team: A cross-functional team that includes developers, testers, designers,
etc., responsible for delivering potentially shippable increments of product at the end
of each sprint.

19
Sprint

A Sprint is a time-boxed iteration, usually lasting 1-4 weeks, where the Scrum Team works to
create a potentially releasable product increment. Sprints help provide a regular cadence for
development, feedback, and adaptation.

Summary

Scrum is a framework for Agile project management that emphasizes iterative development,
self-organization, and continuous improvement. Understanding these terms and concepts
helps teams effectively implement Scrum principles and deliver value to stakeholders in a
structured and collaborative manner.

20