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…
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
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'
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
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.
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.