agile overview
TRANSCRIPT
Its all about the spirit of Agile & Scrum
Agile - OverviewAgile - Overview
By R Ragavendra Prasath
My identity
▪ R Ragavendra Prasath
▪ 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 changeChallenges 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 documentationCustomer collaboration 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 minimal marketable features
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 teamEstimating 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 @ AgileProduct 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 strategyUpholds scrum values and practices
Self organizing and self managing
Provides product expertiseRemoves 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 datesNot 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 name for the user story>▪ As a <user or persona>▪ I want to <take this action>▪ So that <I get this benefit>
▪ The story should also include validation (Acceptance Criteria)▪ When I <take this action>, this happens <description of action>
▪ 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 velocity, or work output
▪ 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 done — developed, integrated, tested, and documented — when you create estimates
Process @ the floorPhase 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 PrioritizationUnderstanding User Story in Details
by PU
Inital Estimate
PMG/PUBD,Engineering
Manager
Product Backlog with Priority and Iteration
Tagging
Initial Estimates
Process @ the floorPhase 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 Execution1. Approach Note/Design document2. Coding with Code review records3. Automated Unit Testing or test
coverage report or 4. Unit test review and execution
results5. Testable Build with CM tagged
6. Defect Logging & Closure7. SIT Test Review and Execution
Results8. Release Build with CM tagged
Scrum TeamShippable 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.
3. The product owner reads a high-priority user story to the players.
4. 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.
5. 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
▪ Effort is the ease or difficulty of creating a particular requirement.
▪ An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement.
▪ Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create.
▪ Ordering, or prioritizing, 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 Back Log Sprint Back Log
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.