Scrum 2.

00PM
epic -- t-shirt size ( s, m, l, xl ) ( PO, BA, PM )

User Stories --
PO-->
as a customer
i want to purchase online using credit card
so that i can pay later
team ->
dev, tester
5 (
acceptance
INVEST

1 1 day
3 1-3 days
5 5 days
8 2 weeks

1 3 hours
2 3-8 hours
3 1 day
5 1-3 days
8 5 days - 7 days

US1 - 100 hours

US2 - 150 hours
US3 - 50 hours
US4 - 60 hours

planned - 352
estimated - 360

Scrum : capacity planning

PO & Team : user stories estimation

Scrum: DOR - definition of Ready

DSM :

PBR -

DOD - definiton of done

Review
Retrospective
==========================================================================

JIRA :
Template - Software Development
board - scrum board
project type- team managed project
company managed project
to add reports in the project board:
project setting -> features -> report
 add your team member :

perspectivemoh@gmail.com
abisheik728@gmail.com
rahulselvam27@gmail.com

---------------------------------------------
Timeline --> Epic
Backlogs ---> sprint backlogs
start the sprint ( custom )

--------------------------------------------
Agile :

Product owner >project requirements > Agile > Project sucess

being in agile vs doing in agile

being :
an individual or an organization is "agile" when they're able to quickly
adopt or evlove in response to changing circumstances
200% success + benifits
leadership at all the levels
customer delight
continous learning

doing :
practicing all the processes and guidelines of agile methodology without
understanding
or absorbing the rationale and the spirit of these guidelines or processes
20% success + benifits
increased productivity
some ability to accept the feedback from the customers

===========================================

Metrics:
Agile + Scrum Metrics :
Lead time stake holder , agile metric, kanban
Cycle time stake holder, agile metric, scrum
BurnUp chart stake holder, agile , scrum
BurnDown chart scrum team, agile, scrum
Velocity scrum team, stake, agile, scrum
Cumulative flow diagram--
Code analysis / Coverage
Static code analysis
Escaped defects
Failed deployments
Value delivered
defect density
production issues
HappinessIndex
RTM - requirement tracebility matrix
RAG - Red Amber Green

Product backlogs
Sprint Backlogs
Product Increment
===================================
https://zohosm.atlassian.net/wiki/pages/viewpage.action?pageId=688131

5 user points -
4 complete - 1 not even started -- 8 day

Burn-up Chart:

Displays the total work (scope) and the cumulative work completed over time.
The chart has two lines: one for the total work (upper bound) and one for the
cumulative work completed.
The goal is to have the cumulative work line meet or exceed the total work line by
the end of the project.
It provides a clear picture of the project's progress and whether it is on track to
meet its goals.
It's easy to see if there have been scope changes as the total work line may move
upward

Burn-up charts are often preferred when there are frequent scope changes or when
stakeholders are more interested in understanding the growth of completed work in
relation to the total scope.

Burn-down Chart:

Displays the total work and the remaining work over time.
The chart has a single line that starts at the total work and trends downward as
work is completed.
The goal is for the burn-down line to meet the x-axis (zero remaining work) by the
end of the project.
It provides a clear indication of whether the team is on track to complete the work
within the given time frame.
It may be less evident if there are scope changes, as the focus is primarily on the
remaining work.

Burn-down charts are useful when the focus is on completing a fixed amount of work
within a specific time frame, and there is less concern about scope changes

Burn Down: - for the team

the amount of work remaining on a project ( remaining effort )

Burn up: business team ( client team )

how much work has been completed and the total scope of the project

Velocity :
a velocity chart focuses on the amount of work completed
planned user story points should be completed

we are showing this to the Business team in the review meetings

10 10 11 12 12 12 15 15 8/15- 7 pending - 10

holidays
unavailable resourses
lack of test data
layoff
over commit
work pressure to release early

---------------------------------------------------
Cumulative flow diagram :
allow us to measure the progress and efficiency of a project
is a visual summary of the information contained on the scrum wall, task board
---------------------------------------------------

Code Coverage :
sonar qube - tool for code coverage
80% and above - stable code
80% and less - not a stable code

static code analysis :

The visibility of a projetcs code without running the software

Design > Code > ANALYSIS > Build > unit test > check In

--> GIT - code management tool

---------------------------------------------
Failed Deployments:

It helps in assessing the number of overall deployments

quartely release
alternative release
1 year - 12 months - 52 weeks
12 deliverables - relase- deployment

52/2 =26-- 1 2D, 3 4D,5 6D

52/3 =17
this metric also determines whether a sprint is ready to enter production
----
Escaped defects:

tracks the number of defects for a deployment that were identified after the
release process

=====
Value delivered
customer satisfaction, loyalty, revenue, usage , feedbacks,

=====
Defect Density :

the number of defects detected per lines of code or per module

* one defect per 1000 lines considered as good
=====

A RAG (Red, Amber, Green) status report is a simple and visual way to communicate
the overall health or status of various elements within a project. Here's a basic
template and explanation of how to create a RAG status report:

RAG Status Report Template:

Project Name/Task:

Provide a clear and concise name or identifier for the project or task you are
reporting on.
Date:

Include the date of the report to indicate when the status was assessed.

Overall Project/Task Status:

Indicate the overall status using the RAG colors:
Red: Major issues, high risk, or off track.
Amber (Yellow): Some challenges or concerns requiring attention.
Green: On track with no major issues.

Detailed Status:
Break down the overall status into more specific categories or aspects of the
project or task. For example:
Scope
Schedule
Budget
Resources
Risks
Quality
Comments/Explanation:

Provide brief comments or explanations for each RAG status to help stakeholders
understand the reasons behind the status. Include information about any key issues,
challenges, or achievements.
Actions Taken/Planned:

Outline any actions that have been taken to address issues or challenges, as well
as any planned actions to maintain or improve the project's status.

===================================
RTM:
Requirement Tracebility Matrix

Happiness Index :
stake -
team

======================================================================
Product Backlog
A product backlog is a list of valuable things to accomplish
When PBI ( product backlog items ) is delivered, some value is created
 The requirments are lsit of all desired work in the project ideally expressed
such that each item has value to the users or customers of the product
product backlog is specific to the entire goal of the product

Sprint Backlog
is specific only to te sprint goal in a particular sprint
it is purely dependent on the product backlogs
every new sprint gets a new sprint backlog which ends as the sprint ends

Product Increment :
what gets produced at the end of a development period or timebox
the moment a product backlog item meets the DOD, an Increment is born

============================================================================
Safe agile
interview questions
metrics (usage)
tech specs used in the projects
BDD- behaviour driven development
road map
TDD - test Driven Development
============================================================================

Road Map ;
Sprint kickoff --
features, sprint duration, roles & responsibilities,
RAG, Capacity , DOR, DOD
Sprint 1
product backlogs --> sprint backlog

S1 S2 S3 S4 S5 milestone

SAVIO -
-------------------------------------------------
Requirement format
BDD - behaviour driven development( both client and team )
TDD - Test driven development ( team )

BDD-
As a ______ ( customer , user , user )
i want to ____________ ( login to the application )
so that , ____________________ ( i can purchase using my debit card )

TDD-
Test Driven Development

===========================================================

Burn Up , Burn down - for the team , auto generated from jira
RAG - by the PM - to check the scope , budget and business
RTM - by the testing team , to find the missed bugs
Code analysis, static code analysis, defect density --
 done by the team, Dev & test - to analysie the code quality
happiness index-
by scrum , to the team and Stake to get the feedback
cycle time - for the team , to analyse the work time , duration
lead time - for the stake , to identify the ROI - return of investment
=============================================
Technical Specification :

frontend:
html, css, php , react js
angular js

backend:
java, python , c#

data base:
oracle, salesforce, mongo db

testing
manual - no codes
automation - selenium

code storage -
git

pipeline- server-
jenkins , bamboo
===============================================================
Safe Agile :
Scaled Agile Framework
promotes alignment, collabration, and delivery across large numbers of agile
teams

ART- Agile Release Train - release train engineer

fuller weight approach

scaling it up by making the necessary changes at the enterprise level
SAFe 6.0

=================================================================
Refinement meeting :
Capacity plan, RAG, DOR, DOD

planning :
capcity

dsm:
burn down

review:
RTM, DOD, Burn down, velocity,code analysis, code review
Retrospective:
burn down, velocity, Confluence report, defect density, happiness index
===================================================================

SDLC :
requirement gathering
requirement analysis
sign off document
design ( ui/ux )
Development
Testing
production
Deployment
Maintanence

STLC
requirement analysis
test plan
test case development
test enviroinment setup
test execution
test cycle closure

Agile Manifesto:

individual and interaction over the process and tools

working software over comprehensive documentaion
customer collabration over contract negotation
responding to chage over following a plan

individual and interaction over the process and tools

interaction with individuals ( people ) is more important
connecting with the people
PO working togwther with the team
face to face meeting

working software over comprehensive documentaion

working software is the major tool
focusing on less documents

Customer collabration over contract negotation

connect with the customr
customer should involved in all the process

responding to chage over following a plan

responding to the changes from the customer
accept the changes and do the needful

Agile Principles :
satisfy the customer
* requirements are met
* early delivery
 Welcome changes
*changes in the requirements are accepted
Delivery frequently
*frequent delivery couple of months to couple of weeks
Work toghter
*business team and dev team must work together
Trust and support
*support - give them the data and enviroinment
*trust - them to get the job done
Face to face conversation
*effective way of communicating , conveying the information is face to
face
Working software
this is the primay measure of teh progress
Sustainable development
constant development , should shown in the process
Continous attentaion
keeping attentation in the regular basis
get them updated
keeping attentaion on the goals, scope
maintain simplicity
simplicity is the art of maximizing the amount of work not done
prioritize the work
self organizing team
completely responsible for assigning and tracking their own work and
progress
Reflect and adjust
at regular intervals, team reflects on how to become more effective ,
then tunes and adjust its behaviour accordingly

does agile fails ?

reason for agile failure

lack of agile knowledge

no support from the management
extended deliverables
lack of team involvement
miss communication
technology focused
lack of customer engagement
conflict btw the team
not following the timelines
not following agile

-------
Agility:
The state of being ( not just doing ) agile, which means going beyond its
"well-known" practices

** to create highest business value in the shortest time in a sustainable way **

being in agile vs doing in agile

Being in AGILE
an individual or an organization is "agile" when they are able to quickly
adopt or evolve in response
to changing circumstances
Doing in AGILE
doing agile means practicing all the processes and guidelines of agile
methodology without understanding or absorbing the rationale and the spirit of
these guidelines or processes

=================================================================
Agile Methodology

LightWeight Approach Fuller weight approach

Scrum scrum of scrums
Kanban scrum at scale
lean scaled agile framework ( SAFe)
Extreme programming agile project management
Continous delivery agile unified process
continous integration open unified process

Interview Questions:
----------
challenges of handle two team as scrum master
user stories planning as scrum master
multiple scrum team reports
client interaction as scrum master
recent user stories worked and the roadmap of the process
user story allocation to a team
DOD
how to handle commit not completed
crises between development team and the testing team
scrum team is not co-operate not with scrum ceremonies
facilate meeting between PO and team
key metrics in agile scrum
ensure the team is continous improvements
spike stories
technique for collabration between the team
conflicting priority with client team
different timezone in team how to prioritze the meeting
======================