SlideShare une entreprise Scribd logo
1  sur  59
Télécharger pour lire hors ligne
Its all about the spirit of Agile & Scrum
Agile - OverviewAgile - Overview
By R Ragavendra Prasath
My identity
▪ R Ragavendra Prasath
▪ ragavendraprasath@gmail.com
▪ Husband, Son, Friend, Student, Employee, Volunteer and
Chocolate Enthusiast…!
Disclaimer
▪ All the slides given here are for information purposes only. Not
for commercial.
▪ Created for the benefit of the Agile / Users as a contribution to
the society.
What’s inside!
▪ What is Agile….?
▪ Evolution of Agile
▪ Traditional Vs. Agile
▪ Why Agile…?
▪ Wastage of features
▪ Agile comes to rescue
▪ Agile Manifesto
▪ Agile Principles
▪ How Agile Projects Work
▪ Scrum – Overview
▪ Scrum contains…
What’s inside!
▪ Release Planning
▪ Daily Scrum
▪ Sprint Planning
▪ Sprint Review
▪ Sprint Retrospective
▪ Some retrospective techniques
▪ Product Backlog
▪ Sprint Backlog
▪ Burn down Chart
▪ Roles @ Agile
▪ User Stories
What’s inside!
▪ Estimation
▪ Story Points
▪ Velocity
▪ Task Board
▪ Shippable Functionality
▪ Definition of 'Done' (DOD)
▪ Process @ the floor
▪ Metrics
▪ Misconceptions about Agile
▪ Conclusion
▪ Bibliography
What is Agile….?
▪ Reflecting customer needs…
▪ a style of project management that focuses on
▪ Early delivery of business value
▪ Continuous improvement
▪ Scope flexibility
▪ Team input
▪ Delivering well tested products
Evolution of Agile
▪ Believes that ‘software solutions evolve’ across iterations
▪ ‘Agile’ was christened in 2001
▪ All activities based on the ‘Agile Manifesto’
▪ Works on small packets of requirements called ‘sprints’
▪ Entire SDLC gets executed in each sprint
▪ Agile emphasizes ‘working software’ as primary measure of progress
▪ Agile is ‘adaptive’ against waterfall ‘predictive’ method
▪ Scrum project management is a popular, simple and loosely defined
framework to execute agile projects
Traditional Vs. Agile
First Delivery
Happens Here
First Delivery
Happens Here
Traditional Vs. Agile
Waterfall Agile
Plan driven Learning driven
Infrequent client communication Continuous client communication
Deliver once in “Big Bang” fashion, Typically 6-9-12
months
Deliver is short, business focuses releases, typically
in 2-3 weeks to 3 months
Requirements defined up front Just-in-time requirements
Develop in distinct phases with interim deliverables
Develop and deliver working code in 2-week long
iterations
Testing as separate phase at end of project, typically
emphasizing functional level
Fully-automated, continuous testing at both
functional and unit level
High cost of change Low cost of change
Why Agile…?
▪ Change in requirements
▪ Lack of stakeholder involvement
▪ Early product realization issues
▪ Unrealistic schedule and inadequate testing
▪ Process as an overhead
▪ Wastage of features
▪ Cost of change
Challenges in IT industry
Wastage of features
▪ So, in Agile ‘Must-have’ features get built first, leaving nice to have
features for later iterations.
Agile comes to rescue
▪ Validated product early
▪ Early ROI and lower costs
▪ Embracing change
▪ Customer and developer satisfaction
▪ Scope for innovation
Agile Manifesto
▪ We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customercollaboration over contract negotiation
Responding to change over following a plan
▪ That is, while there is value in the items on the right, we value
the items on the left more.
For People, Communication, Product & Flexibility
Agile Principles (shortened)
▪ First and foremost: Satisfy the customer - Deliver working, valuable software early and
frequently
▪ Measure progress primarily by working software
▪ Have business people and developers work together daily
▪ Welcome changing requirements
▪ Create a self-organizing team of motivated individuals
▪ Communicate using face-to-face conversation
▪ Avoid nonessential work
▪ Maintain a sustainable pace of development
▪ Attend continuously to good design
▪ Retrospect and adjust regularly
For Customer Satisfaction, Quality,
Teamwork & Project Management
Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
For Customer Satisfaction, Quality,
Teamwork & Project Management
Agile Principles
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10.Simplicity — the art of maximizing the amount of work not done — is essential.
11.The best architectures, requirements, and designs emerge from self-organizing
teams.
12.At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
For Customer Satisfaction, Quality,
Teamwork & Project Management
How Agile Projects Work
▪ Transparency
▪ Everyone involved on an agile project knows what is going on and how the
project is progressing.
▪ Frequent inspection
▪ The people who are invested in the product and process the most should
regularly evaluate the product and process.
▪ Adaptation
▪ Make adjustments quickly to minimize problems; if inspection shows that you
should change, then change immediately.
Transparent, Inspect, Adapt
Scrum - Overview
▪ Development in iterative, incremental manner - SPRINTS
▪ Time boxed
▪ Cross – Functional Teams (CFT)
▪ Self organizing team
▪ During sprint, no new items added
▪ Embraces change for next sprint
▪ Deliver the tangible / Potentially Shippable Product at the end of each sprint
▪ And say 'Done'
Scrum - Overview
Scrum contains…
▪ Meeting
– Daily scrum
– Sprint Planning (Part 1 & Part 2)
– Sprint Review
– Retrospective
– Release Planning
▪ Roles
– Product owner
– Scrum Master
– Team members (Developers & Testers)
▪ Artifacts
– Product Backlog
– Sprint Backlog
– Burn down chart
▪ User stories
– Estimation
– Velocity
– Story points
– Priority
– Potentially Shippable Product
– Task board
– Definition of 'Done'
Release Planning
▪ Release is a group of usable product features that you release to production
▪ Establish the release goal
▪ Releases now go from a tentative plan to a more concrete goal
▪ Scrum team discusses risks to the release and how to mitigate those risks
▪ Need not include all the functionality outlined in the roadmap
▪ should include at least the m inim alm arke table fe ature s
Daily Scrum
▪ Summary
– Update and coordination among team
members
▪ Participants
– Development team, Scrum Master, Product
Owner (optional)
▪ Duration, Do's & Don'ts
– 15 mins max.
– Around the story board ()
– Not a status meeting ()
To inspect the
progress towards
sprint goal
▪ Goal
– What has been accomplished
since last meeting?
– What will be done before next
meeting?
– What obstacles are in the way?
Sprint Planning
▪ Summary
– A meeting to prepare for the sprint, typically
divided into 2 parts
– (1. "What" 2. "How")
▪ Participants
– Part 1:Development team, Scrum Master,
Product Owner (PO)
– Part 2: Development team, Scrum Master,
Product Owner(optional)
▪ Duration, Do's & Don'ts
– 1 hour / week of sprint
– Separate Part 1 and Part 2 meeting ()
– Each meeting not more than 2 hours max
()
What’s and How’s
▪ Goal
– Devise the ‘Sprint Goal’
– Prioritize, Analyze and Evaluate the
product backlog
– Part 1 – understand 'What' PO wants
and 'Why' are they needed
– Part 2 – focuses on 'How' to
implement the items that the team
decided to take on
Sprint Planning
▪ PO devises the Sprint Goal
▪ Velocity rate from previous sprints to guide how much to aim for
▪ Sprint back log created collaboratively
▪ Team can focus on 4 – 6 hours per day
▪ Rest of the time goes to email, meeting, lunch breaks, social and coffee
breaks
▪ Team select items from the product back log they can commit to completing
▪ High level design is considered and discussed within the team
Estimating the
speed
Sprint Review
▪ Summary
– Inspection and adaptation related to the
product increment of functionality
▪ Participants
– Team members, Scrum Master, Product
Owner + Customers, Users, Experts,
Executives, Stakeholders and anyone else
who is interested
▪ Duration, Do's & Don'ts
– 2 hours for 2 weeks sprint
– Anyone present is free to ask question and
give input ()
– Not Demo ()
– No power point slides ()
Inspect and Adapt
regarding the product
▪ Goal
– See and learn what is going on
and then evolve based on
feedback
i.e. PO to learn to what is going
on with the product and Team
and vice versa
– Review is an indepth
conversation between Team and
PO
– Hands-on inspection of the real
software running live
Sprint Retrospective
▪ Summary
– Discuss about the Results (Planned Vs Actual),
People, Team Composition and alignment,
Communication, Collaboration, Processes of getting
support, Tools, Productivity and etc
▪ Participants
– Team members, Scrum Master, Product Owner
▪ Duration, Do's & Don'ts
– 1.5 hours for 2 weeks sprint
– Use different techniques to gather information()
– Only focussing on problems ()
– Retrospectives are always conducted the same
way()
Inspect and Adapt
regarding the product
▪ Goal
– What’s working?
– What's not working?
– What can we change?
– How to implement the change?
Some retrospective techniques
The Real
Launch
DAKI – Drop,
Add, Keep,
Improve
Start, Stop, Continue, More of,
Less of Wheel Complexity retrospective matrix
Thumbs Up, Thumbs Down,
News Ideas and
Acknowledgement
Product backlog
▪ High level document for entire project
▪ Prioritized list of customer centric features as user stories
▪ Contains broad descriptions of all required features
▪ Contains rough development estimate and business value of the
feature
▪ Includes new customer features, bugs, fixes, functions, engineering
improvement goals, research work, and possibly known defects
▪ Product Owner owns product backlog who sets business value
▪ Development estimate is set by the team
Product backlog
Sprint backlog
▪ Contains information on how the team is going to implement
features in upcoming sprint
▪ Features are broken down into tasks
▪ Tasks are never assigned, but picked up by team members
▪ Sprint backlog is the property of team
▪ Estimations are done by team
▪ A task board is used to update the status of tasks
Sprint backlog
Burndown Chart
Product Burn down
Sprint Burn down
 Sprints Vs Story
Points
 Efforts Vs Days
Roles @ Agile
Product Owner Scrum Master Team
A customer representative /
Understand customer and
stakeholder needs
Servant Leader – to make the team
fully functional and productive
Enjoys creating a product
Supplies project strategy Upholds scrum values and practices Self organizing and self managing
Provides product expertise
Removes roadblocks and prevents
disruption
Cross functional
Manages and prioritizes product
requirements
Fosters lose cooperation between
external stakeholders and scrum
team
Dedicated and collocated
Responsible for budget and
profitability
Facilitates consensus building
Decides on release dates Not a manager / project manager
Accepts or rejects work
Decides what the product does and
does not include
Responsibilities of the key players
User Stories
▪ A simple description of a product requirement in terms of what that requirement must
accomplish for whom.
▪ It contains
▪ Title: < a nam e fo r the use r sto ry>
▪ As a < use r o r pe rso na>
▪ I want to < take this actio n>
▪ So that < Ig e t this be ne fit>
▪ The story should also include validation (Acceptance Criteria)
▪ When I < take this actio n> , this happe ns < de scriptio n o f actio n>
▪ Also include
▪ An ID
▪ The value and effort estimate
▪ The person who created the user story
▪ Must follow INVEST approach
▪ Independent, Negotiable, Valuble, Estimable, Small, Testable
User Stories
Estimation
▪ Prioritize as High, Medium, Low or either 1 to 9.
▪ Features in the backlog.
▪ User stories are given Story Points.
▪ Use Poker Planning
▪ No of working hours available = no of team members x 7 hrs x 9
days
▪ Why 9 days: half of day is taken up with planning, half of day ten is taken up with
sprint review and retrospective
▪ Why 7 hours : 7 productive hours
Don’t estimate too far into the
future, if the future is unclear
Story Points
▪ Small and simple tasks are one point tasks, slightly larger/more
complex tasks are two point tasks, and so on
▪ Points are calculated based on Fibonacci numbers
▪ Points are kind of like t‐shirt sizes
▪ Extra-small - 1 pt
▪ Small – 2 pts
▪ Medium – 3 pts
▪ Large – 5 pts
▪ Extra-large – 8 pts
▪ Epic user story that is too large to come into the sprint
Velocity
▪ Adds up the number of story points associated with the
requirements for each sprint
▪ After the first few iterations, you’ll start to see a trend and will be
able to calculate the average velocity
▪ The total number of completed story points is the team’s
ve lo city, o r wo rk o utput
▪ Iteration 1 = 15 points
▪ Iteration 2 = 19 points
▪ Iteration 3 = 21 points
▪ Iteration 4 = 25 points
▪ Average = 80 / 4 = 20
Task Board
▪ A task board provides a quick, easy view of the items within the sprint that
the development team is working on and has completed
▪ Allow PO to move user stories to the Done to prevent misunderstandings
about user story status
Kanban which means Visual Signal
Shippable Functionality
▪ Deliver shippable functionality of the product to customer / user
▪ 3 major activities involved to shippable functionality
▪ Elaborating
▪ Developing
▪ Verifying
▪ Elaborating:
▪ the process of determining the details of a product feature
▪ Ensure unanswered questions about a user story are answered
– so that the process of development can proceed.
▪ Developing
▪ PO continues to work with the development team
▪ Scrum Master protects from outside distractions and removes impediements
▪ Verify
▪ Automated Testing, Peer Reviews and Product Owner review
Shippable Functionality
▪ Verify
▪ Automated Testing,
– Unit testing
– System testing
▪ Peer Reviews
– Code review with other team member
▪ Product Owner review
– After development and testing, team member moves the stories 'Done'
– Product owner then reviews the functionality and verifies that it meets the goals of
the user story acceptance criteria
Definition of 'Done' (DOD)
▪ PO and Team need to agree on the definition of 'Done' for the sprint
▪ A subset of activities needed for creating Potentially Shippable
▪ Based on the existing capabilities
▪ DOD to be as close as possible to the Potentially Shippable
 Consider each part of the definition of do ne — developed,
integrated, tested, and documented — when you create
estimates
Process @ the floor
Phase Inputs Tasks Responsibility Outputs
Pre-Sprint
 
Scope Document or
Requirements from
Customer/PMG/
Finalize the scope of the Delivery/project Customer or
Business Analyst or
Product
Management or Sales
SoW document for
Customization
Marketing/Sales
 
Decide on the solution design or solution
architecture
 
PRD for Roadmap
SoW document for
Customization/PRD for
Roadmap
 
• Study the end to end document and
any other inputs received from the
customer/end user and develop user
stories
•Write acceptance criteria for the user
stories Product Backlog review
BA/PMG
Approved Product Backlog
in terms of User stories
along with acceptance
criteria
Iteration/
Sprint 0
Product Backlog in terms of
User stories along with
acceptance criteria
Backlog Prioritization
Understanding User Story in Details by
PU
Inital Estimate
PMG/PUBD,
Engineering Manager
Product Backlog with
Priority and Iteration
Tagging
Initial Estimates
Process @ the floor
Phase Inputs Tasks Responsibility Outputs
Iteration1
 
Product Backlog with Priority
and Iteration Tagging
Sprint Planning Meeting is done.
User Story tagged to Iteration discussed.
Size and Effort Estimation done
Scrum Team
Sprint Backlog
Updated Product Backlog
Sprint Backlog
Sprint Execution
1. Approach Note/Design document
2. Coding with Code review records
3. Automated Unit Testing or test coverage
report or
4. Unit test review and execution results
5. Testable Build with CM tagged
6. Defect Logging & Closure
7. SIT Test Review and Execution Results
8. Release Build with CM tagged
Scrum Team
Shippable Tested Release
Release Note
Testing release
Metrics
▪ No. of user stories taken up for that Iteration / No. of initial user
stories planned for the iteration
▪ Estimated velocity of user stories taken up for that iteration /
Estimated Velocity of initial planned user stories
▪ No.of user stories Accepted by Product Owner / No.of User
stories taken up for that Iteration.
▪ Actual velocity of accepted user stories/Total effort spent by
team for that Iteration.
▪ Actual efforts-Planned efforts)/(Planned efforts)
Misconceptions about Agile
▪ Agile is all about coding and no documentation
▪ Agile will solve all engineering problems
▪ Agile delivers better quality
▪ Agile is for small projects
▪ Agile gives freedom to change anything anytime
▪ Lets experiment agile on a non-critical project
▪ Let’s start agile slowly
▪ We have daily stand-up meetings, so we are agile
Myths about Agile
▪ Agile Means “We Don’t Plan”
▪ It may seem that no planning occurs, since reliance in on collaboration
▪ In reality, planning is incremental and evolutionary, instead of planning all
activities in one go
▪ Agile Means “No Documentation”
▪ Agile Team’s documentation is light weight as much as possible
▪ They DO document their solutions as they go
▪ They document continuously, writing executable specifications
Conclusion
▪ Scrum is hard, But it is sure a whole lot better than what we
were doing before!
Bibliography
▪ www.goodagile.com
▪ www.scrumalliance.com
▪ Article titled 'The Scrum Primer v2.0' by Pete Deemer
▪ Article titled 'The Scrum Guide' by Ken Schwaber and Jeff Sutherland
▪ Articled titled 'Scrum – a description' from Scrum Alliance, Inc
▪ Articled titled 'Agile in the IT world' published by KPMG, India
▪ Book titled 'Agile Project Management for Dummies' by Mark C. Layton, 2012
▪ Book titled 'Agile for Dummies – 2nd
IBM limited edition' by Amy and Berniew.
▪ Book titled 'Fun Retrospectives' by Paulo Caroli and Taina Caetano
Courtesy to the Authors
Thank you!
Reference Slides
▪ Poker Planning
▪ User stories and the INVEST approach
▪ Estimating and Ordering the Product's Features
▪ Some industry reports
Poker Planning
1. Provide each member of the development team with a deck of estimation
poker cards
2. Starting with a simple user story, the players decide on an estimate — as a
story point — that they can all agree on for that user story.
▪ This user story becomes the baseline story.
1. The product owner reads a high-priority user story to the players.
2. Each player selects a card representing his or her estimate of the effort
involved in the user story and lays the card face-down on the table.
▪ The players should compare the user story to other user stories they have estimated. (The first time through, the players
compare the user story only to the baseline story.) Make sure no other players can see your card.
1. Once each development team member selects a card, all players turn over
their cards simultaneously.
To play estimation poker, follow these steps
Poker Planning
6. If the players have different story points:
▪ It's time for discussion. The players with the highest and lowest scores talk about
their assumptions and why they think the estimate for the user story should be
higher or lower, respectively. The players compare the effort for the user story
against the baseline story. The product owner provides more information about
the story, as necessary.
▪ Once everyone agrees on assumptions and has any necessary clarifications, the
players reevaluate their estimates and place their new selected cards on the
table.
▪ If the story points are different, the players repeat the process, usually up to
three times.
▪ If the players can't agree on the estimated effort, the scrum master helps the
development team determine a score that all the players can support or
determine that the user story requires more detail or needs to be further broken
down.
7. The players repeat Steps 3 through 6 for each user story.
To play estimation poker, follow these steps
User stories and the INVEST approach
▪ Independent: To the extent possible, a story should need no other stories to implement the feature
that the story describes.
▪ Negotiable: Not overly detailed. There is room for discussion and expansion of details.
▪ Valuable: The story demonstrates product value to the customer. The story describes features, not a
single-thread start-to-finish user task. The story is in the user's language and is easy to explain. The
people using the product or system can understand the story.
▪ Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate
the work necessary to create the functionality in the user story.
▪ Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a
user story should not take one person on the development team longer than half of a sprint to
complete.
▪ Testable: You can easily validate the user story, and the results are definitive.
Estimating and Ordering the Product's Features
▪ Effo rt is the ease or difficulty of creating a particular requirement.
▪ An e stim ate , as a noun, can be the number or description you use to express
the estimated effort of a requirement.
▪ Estim ating a requirement, as a verb, means to come up with an approximate
idea of how easy or hard that requirement will be to create.
▪ O rde ring , or prio ritiz ing , a requirement means to determine that
requirement's value in relation to other requirements.
▪ Value means just how beneficial a particular product requirement might be to
the organization creating that product.
Some industry reports
▪ On Agile adoption
The Agile Process
Back Logs
Product BackLog Sprint BackLog
Prioritized list of customer centric features as user stories
maintained by the product owner
Subset of product back log and list of work to be done in
the sprint
Never complete. Evolving list of requirements with larger
and exhaustive details.
User stories picked up by the team during sprint planning
meeting
Single, definitive view of ‘everything that could be done by
the team ever, in order of priority’
Team develops the new product increment defined by the
sprint backlog.
Includes new customer features, bugs, fixes, functions,
engineering improvement goals, research work, and
possibly known defects
Highly visible, real-time picture of the work the team plans
to accomplish.
Many teams use ‘Scrum Boards’ with ‘Post-it’ notes
labeling To-Do, In-Progress and Done.

Contenu connexe

Tendances

Agile2013 sustainable change
Agile2013 sustainable changeAgile2013 sustainable change
Agile2013 sustainable changeDennis Stevens
 
Collaboration Through Conflict - SFAA 2013
Collaboration Through Conflict - SFAA 2013Collaboration Through Conflict - SFAA 2013
Collaboration Through Conflict - SFAA 2013Mark Kilby
 
Agile Methodology Vs. Others by Sara Berrada
Agile Methodology Vs. Others by Sara BerradaAgile Methodology Vs. Others by Sara Berrada
Agile Methodology Vs. Others by Sara BerradaAgile ME
 
Agile Methodology and Tools
Agile Methodology and ToolsAgile Methodology and Tools
Agile Methodology and ToolsNaresh Gajuveni
 
Agile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesAgile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesCelerity
 
Intro agile development methodology abhilash chandran
Intro agile development methodology   abhilash chandranIntro agile development methodology   abhilash chandran
Intro agile development methodology abhilash chandranAbhilash Chandran
 
Agile Methodology in Software Development
Agile Methodology in Software DevelopmentAgile Methodology in Software Development
Agile Methodology in Software DevelopmentRaghav Seth
 
Scrum and agile principles
Scrum and agile principles Scrum and agile principles
Scrum and agile principles Ruben Canlas
 
Agile Process models
Agile Process modelsAgile Process models
Agile Process modelsStudent
 
Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To AgileKnoldus Inc.
 
Why Agile Software Development
Why Agile Software DevelopmentWhy Agile Software Development
Why Agile Software DevelopmentVibhor Mahajan
 
Agile Methodology (scrum)
Agile Methodology (scrum)Agile Methodology (scrum)
Agile Methodology (scrum)Manoj Ellappan
 
Agile - Scrum Presentation
Agile - Scrum PresentationAgile - Scrum Presentation
Agile - Scrum Presentationgihanlsw
 

Tendances (20)

Agile2013 sustainable change
Agile2013 sustainable changeAgile2013 sustainable change
Agile2013 sustainable change
 
Agile manifesto
Agile manifestoAgile manifesto
Agile manifesto
 
Scrum
ScrumScrum
Scrum
 
Collaboration Through Conflict - SFAA 2013
Collaboration Through Conflict - SFAA 2013Collaboration Through Conflict - SFAA 2013
Collaboration Through Conflict - SFAA 2013
 
Agile 101
Agile 101Agile 101
Agile 101
 
Agile Methodology Vs. Others by Sara Berrada
Agile Methodology Vs. Others by Sara BerradaAgile Methodology Vs. Others by Sara Berrada
Agile Methodology Vs. Others by Sara Berrada
 
Agile Methodology and Tools
Agile Methodology and ToolsAgile Methodology and Tools
Agile Methodology and Tools
 
Agile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use CasesAgile Development Methodology: Best Practices and Use Cases
Agile Development Methodology: Best Practices and Use Cases
 
Agile
Agile Agile
Agile
 
Intro agile development methodology abhilash chandran
Intro agile development methodology   abhilash chandranIntro agile development methodology   abhilash chandran
Intro agile development methodology abhilash chandran
 
Scrum in an hour
Scrum in an hourScrum in an hour
Scrum in an hour
 
Agile Methodology in Software Development
Agile Methodology in Software DevelopmentAgile Methodology in Software Development
Agile Methodology in Software Development
 
Scrum and agile principles
Scrum and agile principles Scrum and agile principles
Scrum and agile principles
 
Agile Process models
Agile Process modelsAgile Process models
Agile Process models
 
Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To Agile
 
Why Agile Software Development
Why Agile Software DevelopmentWhy Agile Software Development
Why Agile Software Development
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
Agile Project Management training by manohar prasad
Agile Project Management training by manohar prasadAgile Project Management training by manohar prasad
Agile Project Management training by manohar prasad
 
Agile Methodology (scrum)
Agile Methodology (scrum)Agile Methodology (scrum)
Agile Methodology (scrum)
 
Agile - Scrum Presentation
Agile - Scrum PresentationAgile - Scrum Presentation
Agile - Scrum Presentation
 

En vedette

Blue ocean strategy - Demystified!
Blue ocean strategy - Demystified!Blue ocean strategy - Demystified!
Blue ocean strategy - Demystified!Ragavendra Prasath
 
10 Secrets for Building a Happy Workforce
10 Secrets for Building a Happy Workforce10 Secrets for Building a Happy Workforce
10 Secrets for Building a Happy WorkforcePGi
 
Adobe Digital Insights 2016 U.S. Best Of The Best
Adobe Digital Insights 2016 U.S. Best Of The BestAdobe Digital Insights 2016 U.S. Best Of The Best
Adobe Digital Insights 2016 U.S. Best Of The BestAdobe
 
Event Report - Google Next 2017 - Good progress by Google - but is it enough?
Event Report - Google Next 2017 - Good progress by Google - but is it enough?Event Report - Google Next 2017 - Good progress by Google - but is it enough?
Event Report - Google Next 2017 - Good progress by Google - but is it enough?Holger Mueller
 
Explaining Cumulative Flow Diagrams - CFD
Explaining Cumulative Flow Diagrams - CFDExplaining Cumulative Flow Diagrams - CFD
Explaining Cumulative Flow Diagrams - CFDYuval Yeret
 

En vedette (7)

Agile kanban overview
Agile kanban overviewAgile kanban overview
Agile kanban overview
 
No more push of sales
No more push of salesNo more push of sales
No more push of sales
 
Blue ocean strategy - Demystified!
Blue ocean strategy - Demystified!Blue ocean strategy - Demystified!
Blue ocean strategy - Demystified!
 
10 Secrets for Building a Happy Workforce
10 Secrets for Building a Happy Workforce10 Secrets for Building a Happy Workforce
10 Secrets for Building a Happy Workforce
 
Adobe Digital Insights 2016 U.S. Best Of The Best
Adobe Digital Insights 2016 U.S. Best Of The BestAdobe Digital Insights 2016 U.S. Best Of The Best
Adobe Digital Insights 2016 U.S. Best Of The Best
 
Event Report - Google Next 2017 - Good progress by Google - but is it enough?
Event Report - Google Next 2017 - Good progress by Google - but is it enough?Event Report - Google Next 2017 - Good progress by Google - but is it enough?
Event Report - Google Next 2017 - Good progress by Google - but is it enough?
 
Explaining Cumulative Flow Diagrams - CFD
Explaining Cumulative Flow Diagrams - CFDExplaining Cumulative Flow Diagrams - CFD
Explaining Cumulative Flow Diagrams - CFD
 

Similaire à Agile overview (20)

Scrum Intro for E-works
Scrum Intro for E-worksScrum Intro for E-works
Scrum Intro for E-works
 
Agile methods training
Agile methods trainingAgile methods training
Agile methods training
 
Agile Scrum Quick Reference Card
Agile Scrum Quick Reference CardAgile Scrum Quick Reference Card
Agile Scrum Quick Reference Card
 
Agile Software Development - Agile and Scrum Intro
Agile Software Development - Agile and Scrum IntroAgile Software Development - Agile and Scrum Intro
Agile Software Development - Agile and Scrum Intro
 
Practicing Agile through Scrum
Practicing Agile through ScrumPracticing Agile through Scrum
Practicing Agile through Scrum
 
Introduction to Agile & scrum
Introduction to Agile & scrumIntroduction to Agile & scrum
Introduction to Agile & scrum
 
aa.pdf
aa.pdfaa.pdf
aa.pdf
 
Introduction to Agile and Scrum
Introduction to Agile and ScrumIntroduction to Agile and Scrum
Introduction to Agile and Scrum
 
Agile Course
Agile CourseAgile Course
Agile Course
 
Agile course Part 1
Agile course Part 1Agile course Part 1
Agile course Part 1
 
Agile vision in IT and Software devlopment
Agile vision  in IT and Software devlopmentAgile vision  in IT and Software devlopment
Agile vision in IT and Software devlopment
 
Agile and Scrum - GB
Agile and Scrum - GBAgile and Scrum - GB
Agile and Scrum - GB
 
IntroSCRUM
IntroSCRUMIntroSCRUM
IntroSCRUM
 
scrum-talk
scrum-talkscrum-talk
scrum-talk
 
Agile scrum training
Agile scrum trainingAgile scrum training
Agile scrum training
 
Scrum 101
Scrum 101 Scrum 101
Scrum 101
 
SCRUM methodology
SCRUM methodologySCRUM methodology
SCRUM methodology
 
Agile with scrum methodology
Agile with scrum methodologyAgile with scrum methodology
Agile with scrum methodology
 
Agile philosophy
Agile philosophyAgile philosophy
Agile philosophy
 
Agile methodology
Agile methodologyAgile methodology
Agile methodology
 

Plus de Ragavendra Prasath

Doing Agile Right - Transformation without Chaos - A summary
Doing Agile Right - Transformation without Chaos - A summaryDoing Agile Right - Transformation without Chaos - A summary
Doing Agile Right - Transformation without Chaos - A summaryRagavendra Prasath
 
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)Ragavendra Prasath
 
Dual Transformation - How to Reposition Today’s Business while Creating the F...
Dual Transformation - How to Reposition Today’s Business while Creating the F...Dual Transformation - How to Reposition Today’s Business while Creating the F...
Dual Transformation - How to Reposition Today’s Business while Creating the F...Ragavendra Prasath
 
Growth Canvas - Framework to grow your unit / enterprise
Growth Canvas - Framework to grow your unit / enterpriseGrowth Canvas - Framework to grow your unit / enterprise
Growth Canvas - Framework to grow your unit / enterpriseRagavendra Prasath
 
High Performance Collaboration (HPC) Framework #TogetherStronger
High Performance Collaboration (HPC) Framework #TogetherStrongerHigh Performance Collaboration (HPC) Framework #TogetherStronger
High Performance Collaboration (HPC) Framework #TogetherStrongerRagavendra Prasath
 
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORA
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORASummary of Accelerate - 2019 State of Devops report by Google Cloud's DORA
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORARagavendra Prasath
 
Testathon - 2 days testing challenge
Testathon - 2 days testing challengeTestathon - 2 days testing challenge
Testathon - 2 days testing challengeRagavendra Prasath
 
Craft Conference 2016 Collection - e-book
Craft Conference 2016 Collection - e-bookCraft Conference 2016 Collection - e-book
Craft Conference 2016 Collection - e-bookRagavendra Prasath
 
2016 07-28 immersive-learning_in_the_target_dojo
2016 07-28 immersive-learning_in_the_target_dojo2016 07-28 immersive-learning_in_the_target_dojo
2016 07-28 immersive-learning_in_the_target_dojoRagavendra Prasath
 

Plus de Ragavendra Prasath (16)

Doing Agile Right - Transformation without Chaos - A summary
Doing Agile Right - Transformation without Chaos - A summaryDoing Agile Right - Transformation without Chaos - A summary
Doing Agile Right - Transformation without Chaos - A summary
 
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)
Upstream Value Mapping - Reducing the End-to-End Time to Value (IT Delivery)
 
Dual Transformation - How to Reposition Today’s Business while Creating the F...
Dual Transformation - How to Reposition Today’s Business while Creating the F...Dual Transformation - How to Reposition Today’s Business while Creating the F...
Dual Transformation - How to Reposition Today’s Business while Creating the F...
 
Growth Canvas - Framework to grow your unit / enterprise
Growth Canvas - Framework to grow your unit / enterpriseGrowth Canvas - Framework to grow your unit / enterprise
Growth Canvas - Framework to grow your unit / enterprise
 
High Performance Collaboration (HPC) Framework #TogetherStronger
High Performance Collaboration (HPC) Framework #TogetherStrongerHigh Performance Collaboration (HPC) Framework #TogetherStronger
High Performance Collaboration (HPC) Framework #TogetherStronger
 
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORA
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORASummary of Accelerate - 2019 State of Devops report by Google Cloud's DORA
Summary of Accelerate - 2019 State of Devops report by Google Cloud's DORA
 
Agile and DevOps revealed
Agile and DevOps revealed Agile and DevOps revealed
Agile and DevOps revealed
 
Testathon - 2 days testing challenge
Testathon - 2 days testing challengeTestathon - 2 days testing challenge
Testathon - 2 days testing challenge
 
Starting Agile Transformation
Starting Agile TransformationStarting Agile Transformation
Starting Agile Transformation
 
Fast Agility
Fast AgilityFast Agility
Fast Agility
 
Agile Kanban
Agile KanbanAgile Kanban
Agile Kanban
 
Craft Conference 2016 Collection - e-book
Craft Conference 2016 Collection - e-bookCraft Conference 2016 Collection - e-book
Craft Conference 2016 Collection - e-book
 
Business Agility
Business AgilityBusiness Agility
Business Agility
 
Devops and 3 ways
Devops and 3 waysDevops and 3 ways
Devops and 3 ways
 
Agile in 2 mins
Agile in 2 minsAgile in 2 mins
Agile in 2 mins
 
2016 07-28 immersive-learning_in_the_target_dojo
2016 07-28 immersive-learning_in_the_target_dojo2016 07-28 immersive-learning_in_the_target_dojo
2016 07-28 immersive-learning_in_the_target_dojo
 

Dernier

ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfTobias Schneck
 
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsYour Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsJaydeep Chhasatia
 
React 19: Revolutionizing Web Development
React 19: Revolutionizing Web DevelopmentReact 19: Revolutionizing Web Development
React 19: Revolutionizing Web DevelopmentBOSC Tech Labs
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorShane Coughlan
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesShyamsundar Das
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLAlluxio, Inc.
 
Cybersecurity Challenges with Generative AI - for Good and Bad
Cybersecurity Challenges with Generative AI - for Good and BadCybersecurity Challenges with Generative AI - for Good and Bad
Cybersecurity Challenges with Generative AI - for Good and BadIvo Andreev
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyRaymond Okyere-Forson
 
Streamlining Your Application Builds with Cloud Native Buildpacks
Streamlining Your Application Builds  with Cloud Native BuildpacksStreamlining Your Application Builds  with Cloud Native Buildpacks
Streamlining Your Application Builds with Cloud Native BuildpacksVish Abrams
 
Understanding Native Mobile App Development
Understanding Native Mobile App DevelopmentUnderstanding Native Mobile App Development
Understanding Native Mobile App DevelopmentMobulous Technologies
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxAutus Cyber Tech
 
Webinar_050417_LeClair12345666777889.ppt
Webinar_050417_LeClair12345666777889.pptWebinar_050417_LeClair12345666777889.ppt
Webinar_050417_LeClair12345666777889.pptkinjal48
 
How to Improve the Employee Experience? - HRMS Software
How to Improve the Employee Experience? - HRMS SoftwareHow to Improve the Employee Experience? - HRMS Software
How to Improve the Employee Experience? - HRMS SoftwareNYGGS Automation Suite
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionsNirav Modi
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilVICTOR MAESTRE RAMIREZ
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampVICTOR MAESTRE RAMIREZ
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeNeo4j
 
Vectors are the new JSON in PostgreSQL (SCaLE 21x)
Vectors are the new JSON in PostgreSQL (SCaLE 21x)Vectors are the new JSON in PostgreSQL (SCaLE 21x)
Vectors are the new JSON in PostgreSQL (SCaLE 21x)Jonathan Katz
 

Dernier (20)

Salesforce AI Associate Certification.pptx
Salesforce AI Associate Certification.pptxSalesforce AI Associate Certification.pptx
Salesforce AI Associate Certification.pptx
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
 
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsYour Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
 
React 19: Revolutionizing Web Development
React 19: Revolutionizing Web DevelopmentReact 19: Revolutionizing Web Development
React 19: Revolutionizing Web Development
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security Challenges
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
 
Cybersecurity Challenges with Generative AI - for Good and Bad
Cybersecurity Challenges with Generative AI - for Good and BadCybersecurity Challenges with Generative AI - for Good and Bad
Cybersecurity Challenges with Generative AI - for Good and Bad
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human Beauty
 
Streamlining Your Application Builds with Cloud Native Buildpacks
Streamlining Your Application Builds  with Cloud Native BuildpacksStreamlining Your Application Builds  with Cloud Native Buildpacks
Streamlining Your Application Builds with Cloud Native Buildpacks
 
Understanding Native Mobile App Development
Understanding Native Mobile App DevelopmentUnderstanding Native Mobile App Development
Understanding Native Mobile App Development
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptx
 
Webinar_050417_LeClair12345666777889.ppt
Webinar_050417_LeClair12345666777889.pptWebinar_050417_LeClair12345666777889.ppt
Webinar_050417_LeClair12345666777889.ppt
 
How to Improve the Employee Experience? - HRMS Software
How to Improve the Employee Experience? - HRMS SoftwareHow to Improve the Employee Experience? - HRMS Software
How to Improve the Employee Experience? - HRMS Software
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspections
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-Council
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in Trivandrum
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - Datacamp
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG time
 
Vectors are the new JSON in PostgreSQL (SCaLE 21x)
Vectors are the new JSON in PostgreSQL (SCaLE 21x)Vectors are the new JSON in PostgreSQL (SCaLE 21x)
Vectors are the new JSON in PostgreSQL (SCaLE 21x)
 

Agile overview

  • 1. Its all about the spirit of Agile & Scrum Agile - OverviewAgile - Overview By R Ragavendra Prasath
  • 2. My identity ▪ R Ragavendra Prasath ▪ ragavendraprasath@gmail.com ▪ Husband, Son, Friend, Student, Employee, Volunteer and Chocolate Enthusiast…!
  • 3. Disclaimer ▪ All the slides given here are for information purposes only. Not for commercial. ▪ Created for the benefit of the Agile / Users as a contribution to the society.
  • 4. What’s inside! ▪ What is Agile….? ▪ Evolution of Agile ▪ Traditional Vs. Agile ▪ Why Agile…? ▪ Wastage of features ▪ Agile comes to rescue ▪ Agile Manifesto ▪ Agile Principles ▪ How Agile Projects Work ▪ Scrum – Overview ▪ Scrum contains…
  • 5. What’s inside! ▪ Release Planning ▪ Daily Scrum ▪ Sprint Planning ▪ Sprint Review ▪ Sprint Retrospective ▪ Some retrospective techniques ▪ Product Backlog ▪ Sprint Backlog ▪ Burn down Chart ▪ Roles @ Agile ▪ User Stories
  • 6. What’s inside! ▪ Estimation ▪ Story Points ▪ Velocity ▪ Task Board ▪ Shippable Functionality ▪ Definition of 'Done' (DOD) ▪ Process @ the floor ▪ Metrics ▪ Misconceptions about Agile ▪ Conclusion ▪ Bibliography
  • 7. What is Agile….? ▪ Reflecting customer needs… ▪ a style of project management that focuses on ▪ Early delivery of business value ▪ Continuous improvement ▪ Scope flexibility ▪ Team input ▪ Delivering well tested products
  • 8. Evolution of Agile ▪ Believes that ‘software solutions evolve’ across iterations ▪ ‘Agile’ was christened in 2001 ▪ All activities based on the ‘Agile Manifesto’ ▪ Works on small packets of requirements called ‘sprints’ ▪ Entire SDLC gets executed in each sprint ▪ Agile emphasizes ‘working software’ as primary measure of progress ▪ Agile is ‘adaptive’ against waterfall ‘predictive’ method ▪ Scrum project management is a popular, simple and loosely defined framework to execute agile projects
  • 9. Traditional Vs. Agile First Delivery Happens Here First Delivery Happens Here
  • 10. Traditional Vs. Agile Waterfall Agile Plan driven Learning driven Infrequent client communication Continuous client communication Deliver once in “Big Bang” fashion, Typically 6-9-12 months Deliver is short, business focuses releases, typically in 2-3 weeks to 3 months Requirements defined up front Just-in-time requirements Develop in distinct phases with interim deliverables Develop and deliver working code in 2-week long iterations Testing as separate phase at end of project, typically emphasizing functional level Fully-automated, continuous testing at both functional and unit level High cost of change Low cost of change
  • 11. Why Agile…? ▪ Change in requirements ▪ Lack of stakeholder involvement ▪ Early product realization issues ▪ Unrealistic schedule and inadequate testing ▪ Process as an overhead ▪ Wastage of features ▪ Cost of change Challenges in IT industry
  • 12. Wastage of features ▪ So, in Agile ‘Must-have’ features get built first, leaving nice to have features for later iterations.
  • 13. Agile comes to rescue ▪ Validated product early ▪ Early ROI and lower costs ▪ Embracing change ▪ Customer and developer satisfaction ▪ Scope for innovation
  • 14. Agile Manifesto ▪ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customercollaboration over contract negotiation Responding to change over following a plan ▪ That is, while there is value in the items on the right, we value the items on the left more. For People, Communication, Product & Flexibility
  • 15. Agile Principles (shortened) ▪ First and foremost: Satisfy the customer - Deliver working, valuable software early and frequently ▪ Measure progress primarily by working software ▪ Have business people and developers work together daily ▪ Welcome changing requirements ▪ Create a self-organizing team of motivated individuals ▪ Communicate using face-to-face conversation ▪ Avoid nonessential work ▪ Maintain a sustainable pace of development ▪ Attend continuously to good design ▪ Retrospect and adjust regularly For Customer Satisfaction, Quality, Teamwork & Project Management
  • 16. Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For Customer Satisfaction, Quality, Teamwork & Project Management
  • 17. Agile Principles 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity — the art of maximizing the amount of work not done — is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. For Customer Satisfaction, Quality, Teamwork & Project Management
  • 18. How Agile Projects Work ▪ Transparency ▪ Everyone involved on an agile project knows what is going on and how the project is progressing. ▪ Frequent inspection ▪ The people who are invested in the product and process the most should regularly evaluate the product and process. ▪ Adaptation ▪ Make adjustments quickly to minimize problems; if inspection shows that you should change, then change immediately. Transparent, Inspect, Adapt
  • 19. Scrum - Overview ▪ Development in iterative, incremental manner - SPRINTS ▪ Time boxed ▪ Cross – Functional Teams (CFT) ▪ Self organizing team ▪ During sprint, no new items added ▪ Embraces change for next sprint ▪ Deliver the tangible / Potentially Shippable Product at the end of each sprint ▪ And say 'Done'
  • 21. Scrum contains… ▪ Meeting – Daily scrum – Sprint Planning (Part 1 & Part 2) – Sprint Review – Retrospective – Release Planning ▪ Roles – Product owner – Scrum Master – Team members (Developers & Testers) ▪ Artifacts – Product Backlog – Sprint Backlog – Burn down chart ▪ User stories – Estimation – Velocity – Story points – Priority – Potentially Shippable Product – Task board – Definition of 'Done'
  • 22. Release Planning ▪ Release is a group of usable product features that you release to production ▪ Establish the release goal ▪ Releases now go from a tentative plan to a more concrete goal ▪ Scrum team discusses risks to the release and how to mitigate those risks ▪ Need not include all the functionality outlined in the roadmap ▪ should include at least the m inim alm arke table fe ature s
  • 23. Daily Scrum ▪ Summary – Update and coordination among team members ▪ Participants – Development team, Scrum Master, Product Owner (optional) ▪ Duration, Do's & Don'ts – 15 mins max. – Around the story board () – Not a status meeting () To inspect the progress towards sprint goal ▪ Goal – What has been accomplished since last meeting? – What will be done before next meeting? – What obstacles are in the way?
  • 24. Sprint Planning ▪ Summary – A meeting to prepare for the sprint, typically divided into 2 parts – (1. "What" 2. "How") ▪ Participants – Part 1:Development team, Scrum Master, Product Owner (PO) – Part 2: Development team, Scrum Master, Product Owner(optional) ▪ Duration, Do's & Don'ts – 1 hour / week of sprint – Separate Part 1 and Part 2 meeting () – Each meeting not more than 2 hours max () What’s and How’s ▪ Goal – Devise the ‘Sprint Goal’ – Prioritize, Analyze and Evaluate the product backlog – Part 1 – understand 'What' PO wants and 'Why' are they needed – Part 2 – focuses on 'How' to implement the items that the team decided to take on
  • 25. Sprint Planning ▪ PO devises the Sprint Goal ▪ Velocity rate from previous sprints to guide how much to aim for ▪ Sprint back log created collaboratively ▪ Team can focus on 4 – 6 hours per day ▪ Rest of the time goes to email, meeting, lunch breaks, social and coffee breaks ▪ Team select items from the product back log they can commit to completing ▪ High level design is considered and discussed within the team Estimating the speed
  • 26. Sprint Review ▪ Summary – Inspection and adaptation related to the product increment of functionality ▪ Participants – Team members, Scrum Master, Product Owner + Customers, Users, Experts, Executives, Stakeholders and anyone else who is interested ▪ Duration, Do's & Don'ts – 2 hours for 2 weeks sprint – Anyone present is free to ask question and give input () – Not Demo () – No power point slides () Inspect and Adapt regarding the product ▪ Goal – See and learn what is going on and then evolve based on feedback i.e. PO to learn to what is going on with the product and Team and vice versa – Review is an indepth conversation between Team and PO – Hands-on inspection of the real software running live
  • 27. Sprint Retrospective ▪ Summary – Discuss about the Results (Planned Vs Actual), People, Team Composition and alignment, Communication, Collaboration, Processes of getting support, Tools, Productivity and etc ▪ Participants – Team members, Scrum Master, Product Owner ▪ Duration, Do's & Don'ts – 1.5 hours for 2 weeks sprint – Use different techniques to gather information() – Only focussing on problems () – Retrospectives are always conducted the same way() Inspect and Adapt regarding the product ▪ Goal – What’s working? – What's not working? – What can we change? – How to implement the change?
  • 28. Some retrospective techniques The Real Launch DAKI – Drop, Add, Keep, Improve Start, Stop, Continue, More of, Less of Wheel Complexity retrospective matrix Thumbs Up, Thumbs Down, News Ideas and Acknowledgement
  • 29. Product backlog ▪ High level document for entire project ▪ Prioritized list of customer centric features as user stories ▪ Contains broad descriptions of all required features ▪ Contains rough development estimate and business value of the feature ▪ Includes new customer features, bugs, fixes, functions, engineering improvement goals, research work, and possibly known defects ▪ Product Owner owns product backlog who sets business value ▪ Development estimate is set by the team
  • 31. Sprint backlog ▪ Contains information on how the team is going to implement features in upcoming sprint ▪ Features are broken down into tasks ▪ Tasks are never assigned, but picked up by team members ▪ Sprint backlog is the property of team ▪ Estimations are done by team ▪ A task board is used to update the status of tasks
  • 33. Burndown Chart Product Burn down Sprint Burn down  Sprints Vs Story Points  Efforts Vs Days
  • 34. Roles @ Agile Product Owner Scrum Master Team A customer representative / Understand customer and stakeholder needs Servant Leader – to make the team fully functional and productive Enjoys creating a product Supplies project strategy Upholds scrum values and practices Self organizing and self managing Provides product expertise Removes roadblocks and prevents disruption Cross functional Manages and prioritizes product requirements Fosters lose cooperation between external stakeholders and scrum team Dedicated and collocated Responsible for budget and profitability Facilitates consensus building Decides on release dates Not a manager / project manager Accepts or rejects work Decides what the product does and does not include Responsibilities of the key players
  • 35. User Stories ▪ A simple description of a product requirement in terms of what that requirement must accomplish for whom. ▪ It contains ▪ Title: < a nam e fo r the use r sto ry> ▪ As a < use r o r pe rso na> ▪ I want to < take this actio n> ▪ So that < Ig e t this be ne fit> ▪ The story should also include validation (Acceptance Criteria) ▪ When I < take this actio n> , this happe ns < de scriptio n o f actio n> ▪ Also include ▪ An ID ▪ The value and effort estimate ▪ The person who created the user story ▪ Must follow INVEST approach ▪ Independent, Negotiable, Valuble, Estimable, Small, Testable
  • 37. Estimation ▪ Prioritize as High, Medium, Low or either 1 to 9. ▪ Features in the backlog. ▪ User stories are given Story Points. ▪ Use Poker Planning ▪ No of working hours available = no of team members x 7 hrs x 9 days ▪ Why 9 days: half of day is taken up with planning, half of day ten is taken up with sprint review and retrospective ▪ Why 7 hours : 7 productive hours Don’t estimate too far into the future, if the future is unclear
  • 38. Story Points ▪ Small and simple tasks are one point tasks, slightly larger/more complex tasks are two point tasks, and so on ▪ Points are calculated based on Fibonacci numbers ▪ Points are kind of like t‐shirt sizes ▪ Extra-small - 1 pt ▪ Small – 2 pts ▪ Medium – 3 pts ▪ Large – 5 pts ▪ Extra-large – 8 pts ▪ Epic user story that is too large to come into the sprint
  • 39. Velocity ▪ Adds up the number of story points associated with the requirements for each sprint ▪ After the first few iterations, you’ll start to see a trend and will be able to calculate the average velocity ▪ The total number of completed story points is the team’s ve lo city, o r wo rk o utput ▪ Iteration 1 = 15 points ▪ Iteration 2 = 19 points ▪ Iteration 3 = 21 points ▪ Iteration 4 = 25 points ▪ Average = 80 / 4 = 20
  • 40. Task Board ▪ A task board provides a quick, easy view of the items within the sprint that the development team is working on and has completed ▪ Allow PO to move user stories to the Done to prevent misunderstandings about user story status Kanban which means Visual Signal
  • 41. Shippable Functionality ▪ Deliver shippable functionality of the product to customer / user ▪ 3 major activities involved to shippable functionality ▪ Elaborating ▪ Developing ▪ Verifying ▪ Elaborating: ▪ the process of determining the details of a product feature ▪ Ensure unanswered questions about a user story are answered – so that the process of development can proceed. ▪ Developing ▪ PO continues to work with the development team ▪ Scrum Master protects from outside distractions and removes impediements ▪ Verify ▪ Automated Testing, Peer Reviews and Product Owner review
  • 42. Shippable Functionality ▪ Verify ▪ Automated Testing, – Unit testing – System testing ▪ Peer Reviews – Code review with other team member ▪ Product Owner review – After development and testing, team member moves the stories 'Done' – Product owner then reviews the functionality and verifies that it meets the goals of the user story acceptance criteria
  • 43. Definition of 'Done' (DOD) ▪ PO and Team need to agree on the definition of 'Done' for the sprint ▪ A subset of activities needed for creating Potentially Shippable ▪ Based on the existing capabilities ▪ DOD to be as close as possible to the Potentially Shippable  Consider each part of the definition of do ne — developed, integrated, tested, and documented — when you create estimates
  • 44. Process @ the floor Phase Inputs Tasks Responsibility Outputs Pre-Sprint   Scope Document or Requirements from Customer/PMG/ Finalize the scope of the Delivery/project Customer or Business Analyst or Product Management or Sales SoW document for Customization Marketing/Sales   Decide on the solution design or solution architecture   PRD for Roadmap SoW document for Customization/PRD for Roadmap   • Study the end to end document and any other inputs received from the customer/end user and develop user stories •Write acceptance criteria for the user stories Product Backlog review BA/PMG Approved Product Backlog in terms of User stories along with acceptance criteria Iteration/ Sprint 0 Product Backlog in terms of User stories along with acceptance criteria Backlog Prioritization Understanding User Story in Details by PU Inital Estimate PMG/PUBD, Engineering Manager Product Backlog with Priority and Iteration Tagging Initial Estimates
  • 45. Process @ the floor Phase Inputs Tasks Responsibility Outputs Iteration1   Product Backlog with Priority and Iteration Tagging Sprint Planning Meeting is done. User Story tagged to Iteration discussed. Size and Effort Estimation done Scrum Team Sprint Backlog Updated Product Backlog Sprint Backlog Sprint Execution 1. Approach Note/Design document 2. Coding with Code review records 3. Automated Unit Testing or test coverage report or 4. Unit test review and execution results 5. Testable Build with CM tagged 6. Defect Logging & Closure 7. SIT Test Review and Execution Results 8. Release Build with CM tagged Scrum Team Shippable Tested Release Release Note Testing release
  • 46. Metrics ▪ No. of user stories taken up for that Iteration / No. of initial user stories planned for the iteration ▪ Estimated velocity of user stories taken up for that iteration / Estimated Velocity of initial planned user stories ▪ No.of user stories Accepted by Product Owner / No.of User stories taken up for that Iteration. ▪ Actual velocity of accepted user stories/Total effort spent by team for that Iteration. ▪ Actual efforts-Planned efforts)/(Planned efforts)
  • 47. Misconceptions about Agile ▪ Agile is all about coding and no documentation ▪ Agile will solve all engineering problems ▪ Agile delivers better quality ▪ Agile is for small projects ▪ Agile gives freedom to change anything anytime ▪ Lets experiment agile on a non-critical project ▪ Let’s start agile slowly ▪ We have daily stand-up meetings, so we are agile
  • 48. Myths about Agile ▪ Agile Means “We Don’t Plan” ▪ It may seem that no planning occurs, since reliance in on collaboration ▪ In reality, planning is incremental and evolutionary, instead of planning all activities in one go ▪ Agile Means “No Documentation” ▪ Agile Team’s documentation is light weight as much as possible ▪ They DO document their solutions as they go ▪ They document continuously, writing executable specifications
  • 49. Conclusion ▪ Scrum is hard, But it is sure a whole lot better than what we were doing before!
  • 50. Bibliography ▪ www.goodagile.com ▪ www.scrumalliance.com ▪ Article titled 'The Scrum Primer v2.0' by Pete Deemer ▪ Article titled 'The Scrum Guide' by Ken Schwaber and Jeff Sutherland ▪ Articled titled 'Scrum – a description' from Scrum Alliance, Inc ▪ Articled titled 'Agile in the IT world' published by KPMG, India ▪ Book titled 'Agile Project Management for Dummies' by Mark C. Layton, 2012 ▪ Book titled 'Agile for Dummies – 2nd IBM limited edition' by Amy and Berniew. ▪ Book titled 'Fun Retrospectives' by Paulo Caroli and Taina Caetano Courtesy to the Authors
  • 52. Reference Slides ▪ Poker Planning ▪ User stories and the INVEST approach ▪ Estimating and Ordering the Product's Features ▪ Some industry reports
  • 53. Poker Planning 1. Provide each member of the development team with a deck of estimation poker cards 2. Starting with a simple user story, the players decide on an estimate — as a story point — that they can all agree on for that user story. ▪ This user story becomes the baseline story. 1. The product owner reads a high-priority user story to the players. 2. Each player selects a card representing his or her estimate of the effort involved in the user story and lays the card face-down on the table. ▪ The players should compare the user story to other user stories they have estimated. (The first time through, the players compare the user story only to the baseline story.) Make sure no other players can see your card. 1. Once each development team member selects a card, all players turn over their cards simultaneously. To play estimation poker, follow these steps
  • 54. Poker Planning 6. If the players have different story points: ▪ It's time for discussion. The players with the highest and lowest scores talk about their assumptions and why they think the estimate for the user story should be higher or lower, respectively. The players compare the effort for the user story against the baseline story. The product owner provides more information about the story, as necessary. ▪ Once everyone agrees on assumptions and has any necessary clarifications, the players reevaluate their estimates and place their new selected cards on the table. ▪ If the story points are different, the players repeat the process, usually up to three times. ▪ If the players can't agree on the estimated effort, the scrum master helps the development team determine a score that all the players can support or determine that the user story requires more detail or needs to be further broken down. 7. The players repeat Steps 3 through 6 for each user story. To play estimation poker, follow these steps
  • 55. User stories and the INVEST approach ▪ Independent: To the extent possible, a story should need no other stories to implement the feature that the story describes. ▪ Negotiable: Not overly detailed. There is room for discussion and expansion of details. ▪ Valuable: The story demonstrates product value to the customer. The story describes features, not a single-thread start-to-finish user task. The story is in the user's language and is easy to explain. The people using the product or system can understand the story. ▪ Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary to create the functionality in the user story. ▪ Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not take one person on the development team longer than half of a sprint to complete. ▪ Testable: You can easily validate the user story, and the results are definitive.
  • 56. Estimating and Ordering the Product's Features ▪ Effo rt is the ease or difficulty of creating a particular requirement. ▪ An e stim ate , as a noun, can be the number or description you use to express the estimated effort of a requirement. ▪ Estim ating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create. ▪ O rde ring , or prio ritiz ing , a requirement means to determine that requirement's value in relation to other requirements. ▪ Value means just how beneficial a particular product requirement might be to the organization creating that product.
  • 57. Some industry reports ▪ On Agile adoption
  • 59. Back Logs Product BackLog Sprint BackLog Prioritized list of customer centric features as user stories maintained by the product owner Subset of product back log and list of work to be done in the sprint Never complete. Evolving list of requirements with larger and exhaustive details. User stories picked up by the team during sprint planning meeting Single, definitive view of ‘everything that could be done by the team ever, in order of priority’ Team develops the new product increment defined by the sprint backlog. Includes new customer features, bugs, fixes, functions, engineering improvement goals, research work, and possibly known defects Highly visible, real-time picture of the work the team plans to accomplish. Many teams use ‘Scrum Boards’ with ‘Post-it’ notes labeling To-Do, In-Progress and Done.