Downloaded 43 times
Uploaded byRagavendra Prasath
Agile overview
This document provides an overview of Agile and Scrum. It defines Agile as a style of project management that focuses on early delivery of business value, continuous improvement, scope flexibility, and responding to change. Scrum is introduced as a popular Agile framework. Key aspects of Scrum like sprints, daily standups, planning meetings, and artifacts like product and sprint backlogs are described. User stories, estimation techniques, and the roles of product owner, scrum master, and team are also outlined.
More Related Content
Agile overview
- 1. Its all aboutthe spirit of Agile & Scrum Agile - OverviewAgile - Overview By R Ragavendra Prasath
- 2. My identity ▪ RRagavendra Prasath ▪ ragavendraprasath@gmail.com ▪ Husband, Son, Friend, Student, Employee, Volunteer and Chocolate Enthusiast…!
- 3. Disclaimer ▪ All theslides 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! ▪ Whatis 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! ▪ ReleasePlanning ▪ 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 FirstDelivery Happens Here First Delivery Happens Here
- 10. Traditional Vs. Agile WaterfallAgile 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…? ▪ Changein 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 torescue ▪ Validated product early ▪ Early ROI and lower costs ▪ Embracing change ▪ Customer and developer satisfaction ▪ Scope for innovation
- 14. Agile Manifesto ▪ Weare 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. Ourhighest 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. Workingsoftware 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 ProjectsWork ▪ 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'
- 20.
- 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 ▪ Releaseis 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 ▪ POdevises 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 TheReal 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 ▪ Highlevel 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
- 30.
- 31. Sprint backlog ▪ Containsinformation 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
- 32.
- 33. Burndown Chart Product Burndown Sprint Burn down Sprints Vs Story Points Efforts Vs Days
- 34. Roles @ Agile ProductOwner 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 ▪ Asimple 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
- 36.
- 37. Estimation ▪ Prioritize asHigh, 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 ▪ Smalland 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 upthe 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 ▪ Atask 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 ▪ Delivershippable 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 @ thefloor 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 @ thefloor 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. ofuser 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 ishard, 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
- 51.
- 52. Reference Slides ▪ PokerPlanning ▪ User stories and the INVEST approach ▪ Estimating and Ordering the Product's Features ▪ Some industry reports
- 53. Poker Planning 1. Provideeach 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. Ifthe 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 andthe 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 Orderingthe 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
- 58.
- 59. Back Logs Product BackLogSprint 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.