1.

SWAG:(SCIENTIFIC WILD ASS GUESS)

This is a rough ESTIMATE from an expert in the field, based on his/her
experience and intuition.
Swag provides a way to compare the size, time, and effort that it will take to
complete a set of features without going through detailed backlog estimating
activities
Baseline typical portfolio as 10. Then, a portfolio item that is twice as complex
might get a Swag of 20. A portfolio item that is very small might get a Swag of 1.

2. FORCED RANKING/STACKED RANKING SYSTEM:

Used to PRIORITIZE the item in the list based on RELATIVE COMPARISION.
The participants are asked to provide a ranking based on the requirements (either
feature or complexity) that way the team comes up with the set of prioritized items.
Used in Scrum in Backlog Grooming
Incorporated indirectly in the "minimum viable product" or MVP concept

Used to identify a company's best and worst performing employees, using person-
to-person comparisons.
will improve the quality of the workforce
Forced ranking is a business tool for managing limited resources.

3. PRIORITIZING PB ITEMS:
Used to create a top 10 list usually
Pick one random item, compare and prioritize. 
There will be many discussions about the design and dev of the item.

4. BLOCKERS AND IMPEDIMENTS:

Blockers are roadblock which stops the delivery of the product we may not move
ahead without resolving Blockers whereas impediments are like OBSTACLES
where which cause DELAYS in the delivery. It is important to solve blockers than
impediments.
 
Internal and External
Team owned
- KT or pair programming
Org. Owned 
- not ordering devices in time for testing (Jonas Fitness)
SM Owned
- Conflicts b.w team
- Getting external help
5. CONTINUOUS INTEGRATION:  
Isolated changes were immediately tested and reported that they added to the larger
code base
Rapid feedback
The defect is introduced, identified and corrected as soon as possible
Software tools can be used to Automate the testing and built a document trail.
a. Jenkins - Java
b. Bamboo
c. Codeship

6. FEATURE TEAMS: 
an ideal team with 7+-2 people with the cross-functional skill set to complete a
functionality or feature for the user.
The skilled team that can deliver a functionality
UI, Dev, Testing etc
ideally, co-located
composed of generalizing specialists
work on a complete customer-centric feature
Together since a long time
Cross-functional skill set
  
7. THEME --> FEATURES --> EPICS --> USER STORIES
Themes
- The theme may be thought of as a group of related user stories having same
objectives or common goals.
- Individual user story delivers Business Value
Example: Increase website traffic
Epics
- Epics are bigger user stories that may require more than one releases to
implement.
- Epics can be decomposed into various User stories.
- Business value isn’t realized until all the user stories are complete.
Example: As a user, I should be able to use banking application, so that I don’t
have to go to the bank.
Features
The feature is a distinct element of the functionality of a system which can provide
capabilities to the business. 
A feature may require multiple sprints to implement and are decomposed from
epics. Features can be further decomposed to user stories.
User Stories: what the user wants, 1 or 2 sentences
 
8. PBI VS. TASKS: 
PBI is a well thought and written user story, where are tasks is a granular work
item of a user story which makes a PBI done once accomplished. 
a. PBI: 
The requirement of “the WHAT”
Customer terminology
UAT
customer

b. Task: developer
HOW piece of work
Materializes PBI
Estimates are rolled up into PBI
Technical
Tested internally

9. TEST DRIVEN DEVELOPMENT (TDD) :  

consists of 3 set of activities coding, testing (in the form of unit test), designing
(refactoring)
the developer writes the test cases first and then write the code to make it right.
( refactor it)
a. Write test cases and Run
b. It will fail
c. Just enough code to pass the test
d. Refactor
e. Repeat the idea
Add test cases - Make test fail - write a code - run test - Refactor code

Adv:
Developer-centric
significant reduction in defect rates
Improve design qualities in the code
Higher level internal technical quality

Pitfalls
Forgetting to run tests frequently
Poor maintenance
Partial adoption
Too many test cases and too large

10.ADD- ACCEPTANCE TEST DRIVEN DEVELOPMENT

different perspectives (customer, development, testing)
Customer ( what), Developer ( how) and tester ( what if) perspective. – 3 amigos
The team collaborated to write acceptance tests in advance of implementing the
corresponding functionality.
Acceptance tests are created as test cases 
Same TDD approach 
Repeat until the CRITERIA is met
STORY TEST driven development
strongly associated with the use of specific tools such as Fit/FitNess, Cucumber or
others
Creates an interface specific to Functional Testing

11.BDD- BEHAVIOUR TEST DRIVEN DEVELOPMENT

Discuss the business behavior that our code is implementing.
The business person specifies behaviors they want to see in the system.
The developer asks questions based on their understanding of the system, while
also writing down additional behaviors needed from a development perspective.
Domain specific language converted into program/testable software. 
TDD + Behavior (Customers expectation)
Write failing test case --> Code to pass test --> Refactor --> Acceptance test
(customer verification) - keep on adding new more changes
Can add application behavior (new more cases)
Team-centric

12.VARIOUS APPROACHES FOR RELEASE PLANNING: 

Describes the what feature is implemented and when they are completed
High-level plan for multiple sprints (3-12)
Reflects expectation about which features will be implemented and when they are
implemented
To create a release plan, the following must be included
1.Prioritized and Estimated PBIs
2.Velocity of the team (estimated)
3.Conditions of satisfaction (goals for schedule, scope, and resources)
Feature ( Sum( all feature) /velocity) driven planning 
Date (Velocity X No.of Sprints) 
13.AGILE MANIFESTO:

14.FORMAT FOR USER STORY AND ACCEPTANCE CRITERIA

Conditions that a software product must satisfy to be accepted by a user, customer
or another stakeholder
represent “conditions of satisfaction.”

Acceptance criteria are the set of statements 

a. Functional - Min Marketable functionality
b. Non-Functional - Min quality
Acceptance Criteria may refer to project’s User Stories or design documents
Functional: “A user is able to access a list of available reports"
Non-Functional: “Edit buttons and Workflow buttons comply with the Site Button
Design.”
Performance: specific performance is critical to the acceptance of a user story.

15.ADVANTAGES AND DISADVANTAGES OF SCRUM

Adv:
Saves time and money
Business requirements documentation is hard
Fast moving, cutting edge documents can be quickly coded
Iterative in nature
Insists on the frequent update of progress in work through several meetings
Easier to cope with changes
Issues are well identified thru daily scrum meetings

Dis:
Causes scope creep
If the task is not well defined, estimating project costs and time will not be
accurate.
Proj will never complete or fail if team members are not committed
Good for small, fast-moving projects

16.WATERFALL VS. SCRUM

https://www.leanagiletraining.com/agile/waterfall-versus-scrum-how-do-they-
compare/

17.WATERFALL SCRUM HYBRID

18.AGILE PRINCIPLES
Individuals and Interactions over Processes and Tools
Working Software over comprehensive documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

19.APPROACHES FOR SPRINT PLANNING

a. Velocity Driven:
https://www.mountaingoatsoftware.com/blog/velocity-driven-sprint-planning

Is based on the premise that the amount of work done a team will do in the coming
sprint is roughly equal to what they have done in the prior sprints

Steps:
Determine team's historical average velocity
Select no. of product backlog items equal to the velocity
Identify the tasks involved in the selected user stories and seek if its the right
amount of work
Estimate the tasks and see if the sum of the work is in line with past sprints

b. Commitment Driven
https://www.mountaingoatsoftware.com/blog/commitment-driven-planning

Involves SM, PO and Dev Team, PO gets the top priority product backlog items
into a meeting and describes them to the team, usually starts with high priority

Best utilized when the team is new. New as in either component of the team is
new, either team is new to agile or the team is implementing completely new kind
of project unlike any of their previous projects.
1. We first calculate the total number of ideal work hours available in the team.
2. Then the top priority user story is taken and broken down into tasks
3. Each task is estimated into hours
4. If any capacity is left, the next high-priority user story is taken and the process
continues until there is no more capacity left

20.REQUIREMENT CHURN AND WHO IS RESPONSIBLE FOR IT

Requirements churn is the change to backlog items from the time they are entered
until the product goes into production.
PO is responsible for it when there is a churn of 10% - 15 %   is no issue but more
than 50% - 200% means PO is not very experienced or the organization if moving
to Scrum. 

21.VERTICAL AND HORIZONTAL SLICING

Horizontal: Breaking up user stories based on the kind of work that to be done.
Splited based on application layers that to be involved, like
UI - DB - front end - back end - testing --> waterfall
Cannot be prioritized
Increases bottlenecks, instead of reducing them
Do not deliver business value

Vertical: Splited based on functional layer and across application layer

https://blog.agilistic.nl/8-useful-strategies-for-splitting-large-user-stories-and-a-
cheatsheet/

Split by 
a. Workflow
b. Business value
c. Happy/unhappy flow
d. Input option
e. Data types
f. Operations
g. Test scenarios 
h. Roles

22.ROLES
a. PO, SM, Dev team

23.MEETINGS
a. Release Planning
b. Sprint Planning
c. Daily Scrum
d. Product Backlog refinement
e. Sprint Review
f. Sprint Retrospect
       
24.ARTIFACTS
a. PBI
b. SB
c. Product Increment
d. PB

25.PRIORITIZATION TECHNIQUES
a. MSCW
used by Management, Business Analysts to reach the common understanding with
the stakeholders on the importance that they place on the delivery
for each requirement
M - Must have - critical requirements, 1st priority
S - Should have - important but not necessary to deliver in the current sprint/
timebox
C - Could have - desirable but not necessary
W - won't have - agreed at least criticality
Ex: Irctc
ticket reservation
Tourism & Meal orders
Flight booking
IRCTC wallet

b. KANO 
The Kano model is useful in gaining a thorough understanding of a customer’s
needs
Ex: Evernote
Save the small amount of data like text as sticky note & to keep remainders
Save pictures and write descriptively.. a large amount of notes
Drag notebooks/pdf/weblinks
Adds at the left bottom
Too many notebooks and same taggings in different notebooks causes confusion

Helps to evaluate the features of the potential product, where there is a less time
We must understand the customers need more than the customers articulate them
Performance Requirements - can satisfy or dissatisfy the customers depending on
how well they are executed
12M/G - 24 - 65

Basic Requirements - Their presence doesn’t really add to satisfaction but their
absence will result in extreme dissatisfaction
Ex: Maintaining temp in the hotel room
Excitement Requirements:
WOW factor
DELIGHTED the customer when delivered
Not dissatisfy if missing
Ex: Cell that doesn't needs to be charged

Indifferent: don't care about whether they are present or absent

Example: small FB/twitter logo
Reverse: Decrease satisfaction when present, increase satisfaction when missing

There 
X-axis: Functionality
Y-axis: Satisfaction
Basic;
the requirements that the customers expect and are taken for granted.
Example: Job search portal with filter option.
Performance
Attractive
Indifferent
Reverse

26.ESTIMATION TECHNIQUES
a. Planning Poker
b. Tshirt 
c. Relative mass evaluation
d. Bucket estimation
e. DOT 
f. Affinity mapping

27.RETROSPECTIVE TECHNIQUES
a. Silent Writing --> Dot voting
b. Happiness histogram 
c. ORID ( objective, reflective, interpretive and decisional)
d. The wheel
e. Boat
f. Mad/sad/glad
g. Guess who
h. Futurespective
i. Perfection game
j. Speed dating
k. Safety check

28.DEFINITION OF DONE

CRITERIA of SATISFACTION at the product level to avoid TECHNICAL DEBT

Properly tested
Potentially shippable
Refactored

29.DEFINITION OF READY
Criteria that the team adapts WHEN a story can legitimately be moved from
BACKLOG to SPRINT
Either during Sprint planning or during the sprint
The story is Reviewed and Estimated by the team
The story is the in complete format
1. The story has been reviewed and estimated by the team
2. The story is complete in the format
3. Acceptance criteria are clear and agreed upon
4. Product owner has approved the story

30.ACCEPTANCE CRITERIA 
Agreement between PO and Scrum team about WHAT FUNCTIONALITY WILL
BE PRESENT in each user story in order for it to be done.
Developed by the Product Owner according to his or her expert understanding of
the customer’s requirements.

Potentially Shippable product:

A potentially shippable product is one that has been designed, developed and tested
and is therefore ready for DISTRIBUTION to anyone in the company for
REVIEW or even to any external stakeholder. 
Adhering to a list of “done” criteria ensures that the sprint product is truly
shippable.

31.SPRINT 0
Conducted to design minimum design upfront and defines what MVP should
contain
Usually claimed as necessary because there are things that needs be done before
the project start.
The team needs to assembled which involved hiring or moving people.
Procuring hardware and software and setting up the environment

32.VELOCITY AND TYPES

that the amount of work a team will do in a coming sprint will be roughly equal to
what they have done in the past

33.CAPACITY 
Best utilized when the team is new
New as in either composition of the team is new, 
either team is new to agile or 
the team is implementing completely new kind of project unlike any of their
previous projects.

34.FOCUS FACTOR
Forecasting the no.of deliverables possible in an iteration.
Forecast = FF x updated capacity
Capacity = no.of team members x no. of work hours
 
35.TYPES OF IMPEDIMENTS 
a. Scrum master owned
b. The team owned
c. Organization owned

36.SPIKES AND ITS TYPES

A time-boxed period used to research a concept or create a simple prototype
a. Technical and Functional
1. Functional Spike: is used when there is uncertainty about how a user might
interact with the system. They are evaluated through prototyping, by using
wireframes, mockups etc.
2. Technical Spike: are used to researching various technical approaches in the
solution domain. For e.g. to evaluate the potential performance or load impact of a
user story.

37.TECHNICAL DEBT
a. What was promised and what is delivered. A common reason is:
i. Clients forcing for a feature
ii. Developers not writing the code correctly
iii.No documentation. 
b. Slack time for this
c. Managing
i. Technical Backlog
ii. Cleanup releases
Technical debt includes the things that were chosen not to do in now but will
impede the future development
Technical debt is the difference between what was promised and what was
delivered.

• Naïve Technical Debt: Technical debt accrued due to a team member or business
immaturity, process deficiency.
• Strategic Technical Debt: Technical debt accrued as a result of organization’s
strategic decision to capitalize on time-sensitive market information
• Unavoidable Technical Debt: Technical debt accrued as a result of eventual
obsolescence of software components

38.MVP
a. Minimum Viable Product:
MVP  - A minimum viable product (MVP) is a development technique in which a
new product or website is developed with SUFFICIENT features to satisfy early
adopters. 
The final, complete set of features is only designed and developed after
considering feedback from the product's initial users.
i. Enough value
ii. The future benefit to retain early adapters
iii.The feedback loop to guide future development
 
39.EXPECTATION CHARTS
a. Are used to set expectations to the Users. In either method of Feature or Date-
driven release. 
b. Feature: What can be delivered is unknown, but the team should provide
boundaries on Low and high expectations to create a scope. 
c. Fixed date: When the project is delivered is unknown, but earliest and late date
must be provided. 

40.WHEN IS THE RELEASE PLANNING DONE

In the initial stages, to say we are going to release a dozen or 10 sprints. 
It is either Feature Driven ( sum of features/Velocity => no. of Sprints)  or Date
Driven ( Velocity x No. of Sprint => Total work completed)

Spike:
This is done for knowledge acquisition. 
This should be time-boxed and have specific acceptance criteria. 
A team member may ask for a spike in order to do some research, POC or
prototyping.
Aimed at answering a question or gathering information rather than implementing
product features, user stories/requirements.
Sometimes user stories are generated but they cannot be estimated until the
development team able does some work to resolve a technical question or a design
problem. The solution is creating a spike.
Included in the sprint backlog

The focus of the spike is to not provide the potentially shippable product.
Have a clear objective of outcomes of the spike.

Indications:
Trouble in estimation user stories
High point estimate but the PO sees it small
Technical debt
Difficulty in applying certain story types.
A lot of bugs
Specific areas of application are consistently late.

I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable

Value Stream Mapping:

Eliminate waste
Reduces Process time
Implement process improvement

Current State - As Is
Future State - To Be
Next Future State - Ideal State

Epics (> release) - Portfolio backlog

Features, Themes (> sprint) - program backlog
User stories - Team backlog 

30858363
A scrum of scrums: 
It is a meeting that happens to make sure all the teams are in coordination and
dependencies are presented. 
So that dependencies and impediments can be removed. Scrum masters, Product
owners from all teams attend this meeting.

He acts as servant leader by providing current needs of the development team and
foreseeing future needs of the team to work efficiently towards sprint goal. 

Sprint 0
Design Sprint
Hardening Sprint