0% found this document useful (0 votes)
161 views55 pages

Agile Foundation Knowledge

The document provides an overview of Agile project methodology and Scrum framework. It discusses that in Agile, projects are broken into short iterations called sprints where cross-functional teams work to deliver working software. Each sprint should result in a production-ready software increment. Sprints are time-boxed, usually 2-4 weeks, and every sprint must meet "Done" criteria of being fully tested and releasable. The sprint outcomes are demonstrated to stakeholders for feedback to guide future sprints.

Uploaded by

Thirupati
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
161 views55 pages

Agile Foundation Knowledge

The document provides an overview of Agile project methodology and Scrum framework. It discusses that in Agile, projects are broken into short iterations called sprints where cross-functional teams work to deliver working software. Each sprint should result in a production-ready software increment. Sprints are time-boxed, usually 2-4 weeks, and every sprint must meet "Done" criteria of being fully tested and releasable. The sprint outcomes are demonstrated to stakeholders for feedback to guide future sprints.

Uploaded by

Thirupati
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 55

Agile Foundation Knowledge

To work as a Team member in Agile Projects


Why Companies are delivering projects in Agile?
What is Agile?
It is a process
Why process is imp?
Quality, Consistency

SDLC: A practice or process which helpful to


deliver quality outcome to customer in different
phases.

SDLC Activates or Phases


1. Planning: Staffing, Scheduling, Budgeting,
Approach
PM, DM, Solution Architect, Technical Architect,
Test Manager, Release Manager
Traditional: Project Charter, SOW Statement of
work , Solution Plan
2. Analysis: Business Analyst , Functional
Consultant, Data Analysts
Requirement gathering, Understanding,
Analysis, Mock UI creation
Deliverable: Business Requirement
document-BRD
What customer is expecting from the
Software

3. Design: Technical Architect, Solution


Architect
Customer expectation Soution Digarm
Proposed Solution
Exp development
4. Build:
5. Test
6. Deploy
Sequential Approach:
Entire scope of work must be completed for phase
1Then outcome of phase 1 will be passed to
phase 1
SDLC Models which comes under Sequential
Approach
1. Waterfall
2. V Model(Verification and Validation Model)
Advantegeous:
Entire BRD is ready so easy to design
Entire HLD is ready easy to design
Build/Understand Build
What Kind of Projects:
If you are dealing with a project
1. Known Domain
2. Stable requirements
3. Experienced Resources
4. Small contracts/Medium
What Kind of Projects waterfall model is not
suitable?

What is Iterative Approach?


3 years Project
Every 3 months 1 Iteration
Every Iteration we do Planning, Analysis,
Design, Build, Test, Deploy working end to
end tested software for prioritized features
Every new Iteration is Incremental verion to
previous Iteration
Iteration 1: Simple login, Simple search, Simple
Add to kart, At one Bill payment
methodMVPHappy Path flow, basic flow 3
months
Iteration 2: Enhance Basic flow with registration,
comple serach, multiple products,
Iteration 3:
SDLC models come under Iterative Approach:
1. Agile Model
2. RUP –Rational Unified processIBM
3. RADRapid Application development
Model
Why Itertaive Approach? Agile

1. On-time , Quick delivery software


2. Flexible to changes throughout the project
3. Early Customer Feedback
20yrs
1. Y2K2000Initial Agile
2. Global credit crisis2008Agile 50%
3. COVID-1990%
1. Agile Foundation classes10hrsAgile
Project Team members
2. Agile Project Management course-Scrum,
KanbanMonday
2.1 Scrum masters
2.2 Agile Project Leads
2.3 Agile Innovation Leads
2.4 Agile Project Managers
3. Enterprise Agile project Management
course
Scaled Agile

[email protected]
7PM IST to 9PM IST
7am IST to 11AM IST
Topics Covered in Session 1:
1. What is SDLC? What are the Phases of
SDLC?
2. What are the different SDLC Approaches?
2.1 Sequential Approach
2.2 Iterative Approach
3. What are the Suitablity, Adv,Dis Adv of
Waterfall Model/Sequential Approach?
4. Top 3 reasons why Agile?

Topics to be covered-Session 2

1. Diff between Incremental Approach and


Iterative Approach?
2. Agile Introduction and Agile Principles?
Agile Mind-set?
3. Frame works/Practices which follow Agile?
3.1 Scrum
3.2 Kanban
3.3 XP
3.4 Scaled Agile
4. Scrum Introduction

Principle 1:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
1. Early
2. Continuous Delivery
3. Valuable
Application:
UI Dev-Presentation Layer
Application Dev-Application Layer
DB Dev-Data layer
Iteration 1: MVP
Devops cannot
Y2kMainframe code Automatiom Tool Y2K
and deployed
Shell scripts
Principle 2:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Waterfall Model/Traditional Projects
Jan1st 2006 Insurance Project3 Yrs contract
we have to deliver in Waterfall model
March 30 2006 Requirement Freeze Date
Even after Requirement Freeze date, BA is
changing requirements continuously.
1. Lot of Rework
2. Confusion
3. Business competition
1. RCN Requirement Change Notice/CR
Impact Analysis On BRD, FRS, HLD,
TechnicalRework
Agile:
Initial Product Backlog: 30% of Project
requirements
Iteration 1:
Changes to “Agile Requirements Folder” allowed
contiously/dynamically
Principle 3:
Business people and developers+ Testers+
Deployment must work
together daily throughout the project.

First Floor : UI Development


Second floor: DB Team
BA
Testing
Environment

16 testersTest LeadOnsite team-Client


Report a defect Dev lead

10 Agile teams
Each 5-7 people
4-5 dev
1 tester+ Scrum master
1 Devops
BA, Client representative(Product Owner)
Business team + Technical team(Dev, Test,
Deploy)

Iteration 1 released to production Something is


broken

Self –Organizing: Build projects around motivated


individuals.
Give them the environment and support they
need,
and trust them to get the job done

In waterfall model work will be assigned by


Project Managers, Team lead…
Who will assign work in Agile Projects?
1. Scrum master
2. Leads
3. Product Owner

Team members who is responsible for


“Increment”
Plan, Analyze, Dev, Test, deploy
Plan, Estimate, dev, close 
Command Control leadership
Servant-Leadership

The most efficient and effective method of


conveying information to and within a
development
team is face-to-face conversation.

Ex: Requirements are not clearBA


Email
15 days once we used have a meeting with BA

Product Owner->Client
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Agile Capability team


Assessment of project “Are they really
following Agile”
Assessment of project “ Maturity of Agile
Implementation Assessment”

1.Agile-Scrum
2.JIRA as ALM
3.Devops pipeline-Automated code
deployment
4.Daily Stand up meeting
How frequently you deploy a new version to
Production?
Every month we deploy new version to till
preproduction.. end of every month we are
ready to deploy –Production but client is not
allowing so we are deploying upto pre prod…
Every 6 months once we deploy to production
Agile score=0

Continous delivery must happen in short time


frame
Iteration duration is 6 months=waterfall
model
Short time frame=Couple of weeks rather
than months
Working software is the primary measure of
progress.
In Waterfall model after 6 months Code
develooment inprogress
Iteratio 6 outcome is working

Agile processes promote sustainable


development.
The sponsors, developers, and users should be
able
to maintain a constant pace indefinitely.

Cross Functional:
Continuous attention to technical excellence
and good design enhances agility

1.Full Stack Developers


2.Automation Testinmg(Manual,
Automatiom)
3.Devops engineer to manage devops

Simplicity--the art of maximizing the amount


of work not done--is essential.
Less documentation more face to face
conversation
Agile team must contains upto 9 members who
are cross functional, Self organizing
Client also part of Agile team …collaboration. Less
approval stages….Time

The best architectures, requirements, and designs


emerge from self-organizing teams.

Defect life cycle: TODO, Inprogress, Done


At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

End of every iteration team discuss what went


well, what went wrong, what could be improved
Frequent Inspection and Adoption
Fail quickly and improve from it

Frequent Inspection and


1 Adaption
Self Organizing and Cross
2 functional
Collaboration and Team
3 work
Early, continuous, useful
4 delivery
Simple in documentation
5 and More conversation
1.Scrum master + Tester
2. Scrum master + Dev
3. Scrum master + Devops

[email protected]

1.Carrer guidance
2.Feedback
3.Sharing of u r profile

7 to 10:30
How Agile knowledge helpful for devops/cloud
engineers
Agile Team:
1. 4-5 dev
2. 1-2 Testers
3. 1 devops engineer
Agile strongly promotes continuous delivery
-----------------------------------------------
Scrum Framework:
Scrum Roles
1. Product Owner
2. Scrum Master
3. Scrum development team

Sprint:
In Scrum progress happens in series of sprints

A time boxed event ex: 1-4 weeks where Scrum


master, Product Owner, Scrum Development
team colloborately build a new version based on
priorities given by Business(Product Owner)
--------------------------------------------------------
Every sprint outcome is working software
Final Sprint of the release goes to production

The heart of Scrum is a Sprint, a time-box of one


month or less during which a “Done”, useable,
and potentially releasable product Increment is
created.
Every Sprint outcome must meet Done criteria
1.100% Tested
2.Ready to go live
3. No open defects
Sprint 1V1Demo to businessFeedback
Sprint 2V2Demo to busiessFeedback
Sprint 3V3Demo to businessFeedbackGo
live
Every release : 1 sprint
Release=Sprint

Release = 2 months
Sprint 0: Planning of the sprint
Sprint 1: Application Sprint: Productive sprint
Sprint 2:
Sprint 3: Deploy sprint
Sprints have consistent durations throughout a
development effort.
Sprint 1: 2weeks
Sprint 2: 3weeks
Sprint 3: 4 weeks
Sprint length must be consistent
A new Sprint starts immediately after the
conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning,


Daily Scrums, the development work, the Sprint
Review, and the Sprint Retrospective.
During the Sprint:
• No changes are made that would endanger the
Sprint Goal;

100 hours capacity


80 hours capacity 20 hours changes
Scrum is not suitable for Maintence or support
Can we implement Agile methodology for support
project?
Yes

1. Kanban
2.SCRUMBAN
• Quality goals do not decrease; and,
10 Requirements in sprint
2 weeks 8 requirements
• Scope may be clarified and re-negotiated
between the Product Owner and Development
Team as more is learned.
10Requirements
1.Spill over to next sprint
2.Move to Product Backlog
Each Sprint may be considered a project with no
more than a one-month horizon.

Like projects, Sprints are used to accomplish


something.
Each Sprint has a goal of what is to be built, a
design and flexible plan that will guide building it,
the work, and the resultant product
increment. Sprints are limited to one calendar
month. When a Sprint’s horizon is too long the
definition of what is being built may change,
complexity may rise, and risk may increase.
Sprints enable predictability by ensuring
inspection and adaptation of progress toward a
Sprint Goal at least every calendar month. Sprints
also limit risk to one calendar month of cost

Q1: Who will be involved in Sprint?


1.Product Owner
2.Scrum master
3.Scrum development team
Q2: What happens during sprint?
1.Every new sprint starts with Sprint planning
2. Development of work as per sprint plan
3. Participate in different events
3.1 Sprint planning
3.2 Daily Scrum meeting
3.3 Sprint review meeting
3.4 Sprint retrospective meeting
4.Demo of working software or PI to business
and get the feedback

Q3: If any work is pending in Sprint? what


happens
Team has two options with product owner
Approval
3.1 Spill over pending items to next sprint
3.2 Move to Product Backlog
Q4: Can we change Sprint length?
4.1 Every Sprint length must be constant, It
must not be greater than 4 weeks
Q5: What is outcome of the sprint?
1.100% tested done, useful working
software.
1.Product owner responsibilities
2.Scrum master responsibilities
3.Scrum development team responsibilities

1. Client representative
2.Define vision of the product and based on
vision “Product backlog Management”
3.Ordering of Product Backlog Items as per
“Business Value”
4. Enhancing Backlog based on business
feedback
5.Collaborate with development team to clarify
their queries/concerns
6. Involve in Informal review once each story is
built during middle of sprint
7. End of Sprint involve in Sprint review
meetings to review demo of working software
and give feedback
8. BA can define Backlog items but PO is
accountable for managing backlog.
9.PO is sole person must not be a committee
Agile:
1.Scrum In Scrum project priority/ordering of
work sets by Business/Product Owner
2. XP In XP Project priority/ordering of work
sets by Developers
3.KanbanIn Kanban priority or ordering of
work sets by WIP limit of the team

What is Product Backlog


What are the items in the product Backlog?
How to manage Product Backlog Items?
How to identify Sprint Backlog from Product
Backlog?
What is difference between Product backlog and
Sprint Backlog?
Scrum master responsibilities:
Day to day Scrum Master Operations:

1. Schedule and facilitate scrum ceremonies like: Sprint planning, daily stand up, product
backlog refinement session, sprint review & sprint retrospective.
2. Do capacity planning for team
3. If client is new to Scrum framework, guide and educate client reg. how to deliver work in
Agile way i.e. encouraging Agile mind set in client
4. If development team is new to Scrum framework, guide and educate developers reg. Scrum
values and principles, how to work in Agile way, team accountability rather than individual
accountability etc.
5. Monitor whether team works as self-organized and cross functional from delivery
perspective e.g. in absence of tester, BA takes over role of tester, in case of some developer
is absent for e.g. 3 to 4 days, if other developer has spare capacity, this other developer can
take over work of absent developer to complete committed work.
6. Identify and remove impediments which comes in way of development team e.g. network
issues(VPN issues), docker installation and configuration issues, connectivity issues while
working remotely, indirect impediments like lack of team co-ordination etc. so that
development team would focus on their deliverables
7. Keep team motivated i.e. maintain team morale e.g. by keeping fun activities on alternate
Fridays like: celebrating birthdays, keeping some competitions e.g. dress competition,
different games competition on occasion of some festivals like Diwali, Christmas etc.
8. To monitor and fill skills gap for development team e.g. current skills of development team
and required skills of development team by conducting some trainings to upskill
development team
9. Monitor product backlog w.r.t. sufficient work available(sufficient story points of work) for at
least minimum 2 sprints ahead w.r.t. user stories with DoR(definition of ready) status as
“Ready”, blocker or critical bugs, spikes etc.
10. Monitor whether every Scrum ceremony is time boxed with effective communication and
meaningful outcome
11. Ensure team adapts itself w.r.t. improvements discussed in sprint retrospective
12. Protect development team from outside distraction
13. Monitor whether development team is NOT following Anti Agile patterns
14. Monitor and resolve conflicts within development team OR conflict between client &
development team etc.
15. Monitor whether openness and transparency is maintained in all Scrum ceremonies
16. Monitor whether development team raises concerns and risks w.r.t. development & testing
during sprint on right time OR to co-ordinate same with development team during sprint
17. Conduct one-to-one meeting with all developers to understand their challenges, problems
and to resolve same
Scrum Team responsibilities:
1.5-9 people group of cross funcrional, self
organizing responcible produce PI end of
every sprint
2.Design, Developent, Testing, Deployment
3. Every day participate in Daily Stand up
meeting to discuss what they have achieved in
last 24hrs, what is their plan for next 24hrs
and how to resolve any blocking points
• Ideal team size is around 7 members
• Support the Product Owner with refining the
Product Backlog user stories before
implementation.
• Estimates work efforts
• Perform the detailed design of
application and technical
architecture components.

• Configure, build, and test the


application or technical architecture
components.
• Inform the technical architect and
project manager of any issues that
may affect any other areas of the
project.
• Fix any defects and performance
problems discovered in testing.
• Document the application to
facilitate maintenance.
• Testers in the Scrum team are
responsible for Product / Functional
Test Design and Execution and
Regression Test.
A client is demanding new story during middle of
sprint which affects sprint goal, Product owner is
unable to handle that client…
Scrum master guides product owner how to
handle a new client demanding a new
requirement during middle of the sprint
Leader-
Scrum master participates in resolving issues
And delivering work

09:10 to 10:00 continue class


1.Sprint planning
2.Daily scrum meeting
3.Sprint review meeting
4.Sprint retrospective meeting
What is Sprint planning meeting?
How requirements evolve throughout the project
in Agile?
1. IdeaR&D Spike
2. High Level Requirements in Agile project are
called EPIC/Feature
EPIC  A big requirement
EPIC 1: Search
EPC 2: Add to Kart
EPIC 3: Payment

3.EPIC further breakdown to user stories/Story


card…
User story is a simple requirement which
express customer expectation
User story 1: As a User of ecommerce site I want
Search with price range so that I can see required
products in Search list
User Story 2: As a User of ecommerce site I want
Search with product Title so that I can see
required products in Search list
User Story 3: As a User of ecommerce site I want
Search with blank search so that all products must
be displayed
User Story 4: As a User of ecommerce site I want
Search with Date so that required products must
be displayed
EPIC vs User story
Product Backlog: Collection of EPICS and User
stories called as product Backlog

1.Excl
2.JIRA kind of ALM-Application life cycle
management
User story format:

Step 1: Once Initial product Backlog is ready


before planning of the sprint team participates
Backlog refinement or Backlog grooming
discussion
Development Team adds more details to backlog
1.Adding Technical acceptance criteria
2. Identify Tasks
3. Preliminary estimate to express complexity of
the story: Story Points

Story Points:
• A unit of measure for expressing the overall
size of a user story or feature
• It tells us how big a story is, relative to others,
either in terms of size or complexity.
• Will likely include a degree of complexity that
is understood only by the team, and are not
absolute.
• They are relative values, not fixed. No direct
correlation between hours and points
1,2,3,5,8,13,20

1. What is Product Backlog?


2. How to define a User story? Key sections of
user story? User Story format
3. Rank vs Story points
4.Backlog Grooming /Refinement
Step 1: we have 250 user stories in Product
Backlog
Step 2: Sprint length is 2 weeks-10 working days,
excluding management/extra -8hrs per, we are
considering productivity 6.5hrs
Step 3: 9 members Development team+1 SM
10(members)*6.5*10(days) =650hrs of
time available
Planned vacation =50hrs
Total available hrs-planned vacation=650-
50=600hrs
Capacity of the team=600hrs

In Sprint 1 tell me how many user stories can be


estimated/selected by Scrum team as part of
Sprint 1 backlog out of 250

How many of 250 can be considered as Sprint 1


backlog?
Sprint backlog: list of stories committed by scrum
development team to convert as working
software by the end of sprint

Before starting of each new sprint..sprint planning


meeting will be conducted…
Objective of sprint planning meeting
Identify sprint backlog from product backlog

For that team follow’s sprint estimation


techniques
1.Playing poker game

Who decides Sprint Backlog items?


Ans: Scrum team
Playing poker game
Previous velocity

7 to 8 Events
8 to 9Doubts/guidance
7 to 8Scrum master/Agile project Manager
session 1

CSMScrum alliance-24,000
PSMScrum.org-11,000
Scaled Agile certification 50,000+ GST
1. Understanding practical approach-Role Based
2.Certification cost
1.Testing+ Scrum master/APM/AC
2. Devops+ Scrum master
3. Support + Scrum master
4. PMO
5. BA, FC

Role 1: Agile Project Manager


Role 2: Scrum master
Role 3: Agile coach

Course : Agile Project Management


1.Scrum and Kanban-30hours
2.Enterprise Agile-25hrs
How we decide Sprint Backlog before starting of
each new sprint by playing poker game

Velocity:
Playing poker game:
Rank 1 story card: 11 SP –Agreed by team
members in Poker game
Rank 2 Story card: 5 - Agreed by team members in
Poker game
Rank 3 story card: 3- Agreed by team members in
Poker game
Velocity:
Velocity: Velocity is the number of story points (for completed
user-stories) the project team can deliver within a sprint,
based on past sprints’ experience .

For example, a team plans to execute ten user stories in a


sprint, and the estimate for those ten user stories is 100 story
points.
At the end of the sprint, the team was able to complete only
nine out of the ten user stories. If the planned value for the
completed user stories was 90 story points, the velocity for
that sprint can be calculated as 90/100.
Sprint 4:
Planned velocity =100 SP work-X no. of story cards
Actual velocity=90SP
While planning next Sprint 5
Planned velocity: 90SP
How many story cards we can plan in a particular sprint?
Previous Sprint Actual Velocity
Playing poker in Sprint planning meeting continue till sum of
SP’s selected for this sprint equals 90

Velocity: Velocity is the number of story points (for


completed user-stories) the project team can deliver within a
sprint, based on past sprints’ experience
How much work u can deliver in a sprintVelocity
Capacity: Number of hours available for the scrum team to
produce increment
Story points: Relative measuring which explains how complex
this story is when compared to others
Poker game: Agreement of Estimate value : SP
Daily Scrum meeting:
Team meets each day to discuss the accomplishments and
Impediments
1. Inspect Achievement and track impediments
2. To avoid other unnecessary meetings
3. Taking commitment in front of peers

MYTHS:
1. Scrum meeting is for scrum master
2. It is daily status meeting
3. It is for doubts clarification

Who conducts Daily scrum meeting?


A. Scrum master
B. Product Owner
C. Scrum development team
D. Project Manager

The Scrum Master ensures that the Development Team


has the meeting, but the Development Team is
responsible for conducting the Daily Scrum.
Today Scrum master is on leave, then who is
responsible to conduct daily scrum meeting

1. Back up scrum master


2. Product Owner
3. One deveopr act as a scrum master
4. Scrum development team

5-9
Scrum Development team:
In Sprint planning meeting user story breakdown
to tasks
Story 1:
Task 1: Dev
Task 2: Testing
Task 3: Deployment

 5 dev
 2 testers
 2 devops
Story Board
Todo: Testing1
Inprogress: Testing 1
Done

Technical Architect must involve every new release


sprint0

Technical Architect&Dev
Sprint 0Technical architect
Sprint 1,2,3Develoeprs

Sprint 0Test lead


Sprint 1,2,3Automation tester
Sprint review meeting:
At the end of the Sprint
1. Feedback from the PO and Stakeholders to
enhance Product backlog before planning next
sprint
2. Discuss with stakeholder what kind of new
changes in their mind.
3. Continuous feedback
Sprint Retrospective meeting:
What went well in the sprint with regard to people,
process, tools Continue Doing
Automation test scripts for regression testing
What went wrong in the sprint with regard to people,
process, tools Stop doing
Manual code integration, no Jenkins setup
What has to be improved Start doing
Jenkins integration-Devops pipeline
Sprint retrospective document

You might also like