Agile scrum training
- 1. Agile & Scrum- An Introduction Prepared and Presented by Rajakrishnan S â MCA,MBA,PMP,CSM,ISTQB(Advanced),ITIL
- 2. Purpose of this Session â To go through the Agile practices â To go through the Scrum Method
- 3. Agenda â What is Agile and its principles (20 minutes) â When to use agile â When to not use agile â Agile pros and cons â Scrum (40 minutes) â Components of Scrum â Estimation in Scrum â Requirements Management in Scrum
- 4. What is Agile â Iterative and Incremental development Model â Time boxed iterative approach â Encourages rapid and flexible response to change â Self organizing and cross-functional teams â Aim to delivery right product, at right price in right time â Core values include â Adaptability â Transparency â Simplicity â unity
- 5. Agile Manifesto â Individuals and interactions over processes and tools â Working software over comprehensive documentation â Customer 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.
- 6. Agile Manifesto... â Individuals and Interactions â - in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. â Working software â â working software will be more useful and welcome than just presenting documents to clients in meetings. â Customer collaboration â â requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important. â Responding to change â â agile development is focused on quick responses to change and continuous development.
- 7. When to use Agile â Requirements are not complete â There are changes in requirements expected â Quick customer releases with high quality is the objective of the organization â Customer collaboration is possible â When feature development heavily relies on stakeholders feedback
- 8. When to not use Agile â Application users(Stakeholders) are NOT always accessible to you. â You need to follow traditional software management processes and procedures. â Deliverable must pass through a chain of approvals and tollgates â You have to formally document the requirements, design, code, and testing cases during each phase of the software life cycle. â Donât try agile it you already decided against it :)
- 9. Pros and Cons of Agile â Pros â Early and frequent delivery of business value hence satisfied stakeholders/customers â More flexible than traditional model â Involvement of QA throughout the process â More visibility to each team member, increases motivation and ownership â More accuracy in estimation, since working in chunks â Early feedback/acceptance of customer is possible â Responsive to changes
- 10. Pros and Cons of Agile â Decreases risks by having working software â Increased control â Less barriers in communication â Small releases, easy to manage â Cons â Over-hype about agile will lead to lot of unrealistic expectation â Approach of the people
- 11. Some Factors to succeed in Agile â Dedicated product manager â Experienced and self organized team â Automation testing and developer testing â Attitude towards scrum â Adaptive to changes â Readiness to do face-face communication â Management Support
- 12. Various Agile Methods â SCRUM â Kanban â Extreme Programming â Agile Unified Process â Feature Driven Development
- 13. Some of the major users of Agile Google Microsoft Oracle Dell FIFA (Accepted as the official training process) .. .. ..
- 14. SCRUM
- 15. What is Scrum â Scrum is an agile approach to Software Development â Scrum is an iterative and incremental development process â The project is split into a series of consecutive iterations (sprints) â Scrum is a framework rather than a full process or methodology â Scrum relies on self-organizing and cross-functional team â Scrum teams are supported by Scrum Master and Product Owner. There is no overall leader
- 16. History of Scrum â Scrum (in rugby) to restart the game in situation when ball has gone out of play â 1986- Hirotaka and Ikunjiro described a new approach to product development that would increase the speed and flexibility. They called it a rugby approach, where a cross functional team work together as a unit to reach the distance â In 1990s: Ken Schwaber and Jeff sutherland used similar approach and used the term scrum â 1995: Sutherland and Schwaber presented a paper on scrum methodology for the first time in Austin, Texas
- 17. Scrum Process â A graphical Representation
- 18. Team Organisation Engineering Team (Dev, QA, Architect, Designer) PO SM Architects, Developers, Testers form the engineering team(scrum team)
- 19. Basics components of Scrum Roles Ceremonies Artifacts Product Owner Scrum Master Engineering Team Release Planning Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Backlog Refinement Product Backlog Sprint Backlog Burn down Chart
- 20. Sprint (Iteration) â Scrum Projects make progress in a series of sprints â Each sprint(Iterations) no more than a month long â Team members commit to deliver some number of features from product backlog â Features are coded, tested and integrated to the product or system â Sprint Review Meeting is conducted at the end of the sprint and each team demonstrates the new functionality to product owners and other interested stakeholders
- 21. Product Owner â Product Owner represents the business, customers and users â Guides the team towards building the product. â He is often someone from Product Management or Marketing, a key stakeholder or a user
- 22. Scrum Master â Scrum Master can be thought of as a coach/facilitator for the team â The Scrum Master is responsible for making sure the team is as productive as possible â Helps team to use the scrum framework to perform at their highest level
- 23. Scrum Team(Engineering Team) â âWe are all in this togetherâ â Scrum doesnât include any of the traditional software engineering roles such as programmer, designer,tester, or architect â A typical scrum team is 6-10 in size
- 24. Product Backlog â Itâs a prioritized master list of all features(called stories) desired in the product â The Product Backlog is allowed to grow and change as more is learned about the product and its customers. â Product owner owns the product backlog
- 25. User Stories â Requirements are captured in scrum as user stories â A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement â User Stories are pointers, and the details of stories can be provided in any format(like requirement documents, wireframes etc..) â Format :As a <type of user>, I want <some goal> so that <some reason>. â Example: As a power user, I can specify files or folders to backup based on file size, date created and date modified. â
- 26. Sprint Backlog â Itâs the list of tasks that the Scrum team is committing for the current sprint â Items are selected from product backlog based on the priority set by product owners and the perception on the team â It can be maintained in an excel sheet or in tools like JIRAAgile, TFS, scrumworks, version1 etc. â Each product backlog items selected for the current sprint will be added by expanding those with tasks and estimating hours â The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burn down chart
- 28. Sample Burn down Chart
- 29. Sprint Planning Meeting â The meeting to plan the items to be delivered in the sprint â Attended by Product Owner, Scrum Master, the entire scrum team, Any other interested management or customer representatives â Product owner describes Objective of the sprint and the highest priority stories to the team â 4 hours time limit for a 2 week sprint
- 30. Daily Scrum Meeting â The team hold a daily stand up meeting. â Typically held in the same location and same time â Team members who has committed to tasks will only talk â Its not a problem-solving or issue resolution meeting â Issues raised are taken offline and usually dealt with by the relevant subgroup immediately after the daily scrum
- 31. Daily Scrum Meeting... â During the scrum each team members provides answer to the following questions â What did you do yesterday? â What will you do today? â Are there any impediments in your way? â 15 Minutes time limit for each team â This is not a status update meeting in which boss is collecting information about who is behind schedule â Itâs a meeting in which team members make commitments to each other
- 32. Daily Scrum Meeting- Role of a scrum master â Its scrum masterâs responsibility to resolve the impediments raised in the meeting â If scrum master cannot resolve it directly(technical issues), he should make sure that someone in the team does quickly resolve the issue, by taking the responsibility.
- 33. Daily Scrum Meeting- Sample Impediments â My ____ broke and I need a new one today. â I need help debugging a problem with ______. â I'm struggling to learn ______ and would like to pair with someone on it. â The department head has asked me to work on something else "for a day or two." â The environment is not ready to test â The delivery of the item is getting delayed from âXâ
- 34. Sprint Review Meeting(Exit Demo) â Sprint Review Meeting is held at the end of each sprint â Scrum teams shows what they have accomplished (Demo of new features) â Its very informal with rules avoiding the use of power point slides and allowing no more than 2 hours of preparation time for the meeting â Sprint review meeting should be a natural result of the sprint
- 35. Sprint Review Meeting⊠â Participants â Product Owner â The Scrum team â Scrum Master â Management â Customers â and Developers from other projects â Project is assessed against the sprint goal determined during the planning meeting â Its important that team achieve the goal of the sprint â 2 hours is the limit for a 2 weeks sprint
- 36. Sprint Retrospective â All team members reflect on the past sprint â Make continuous process improvements â Main questions asked in the sprint retrospective are: â What went right during the sprint â What went wrong during the sprint? â What could be improved in the next sprint? â 1 hour is the time limit
- 37. Daily Scrum Meetings â Best Practices â Stand up means stand up, no sitting, really â Keep it short. 15 minutes max. â Stand in front of the visual progress artifact â Everybody should be present. â No typing â Concentrate on the second and third question, not on the first one. â If team talks too much to Scrum Master, let him not too look at the team. .
- 38. Requirements in Agile-Scrum â Requirements are captured in the form of user stories â User story has the following format â As a <Actor>, I want to <Do this>, So I can <get this> â Example: As a User, I want to log in, So I can access subscriber content â These user stories will be elaborated by the team along with the product owner(customer representative)
- 39. Estimation in Agile-Scrum â There are different estimation techniques in Agile-Scrum â Planning Poker(Fibonacci Series-1,2,3,5,8,13,21) â Power of 2(2,4,8..) â T-shirt sizing (X-Small, Small, Medium, Large, X-Large)
- 40. Definition of Done â Self review of code should be completed with the help of automated tools â Code/Config should be reviewed â Unit testing with coverage of 80% and above â Developer Sanity testing(All Acceptance cases) should be completed in Dev env. â Story Level Functional Test cases should be reviewed â Test execution should be completed in QA environment â All defects are closed â Acceptance criteria should be met â Demo to the Product Owner â Signoff from Product Owner â All tasks related to the story should be closed in optimus â Deployment instructions are documented
- 41. Measuring Agility â Velocity of the team can be used to measure the agility â Velocity tells how much the team can delivery â Velocity is calculated as an average â Example of Velocity: 40 story points per sprint by the 5 member team
- 42. Some Best Practices â Early demo to PO â Design(specially UI) can be demoed to the PO to get an early feedback by the developer â Once feature is developed in developer environment, a demo can be done to the PO â Test Scenarios/Cases can be reviewed by PO and peer developer â Buddy Testing â Tester work with developer to validate the story in developer environment prior to deploy in QA env.
- 43. For Further Reference â http://www.agilealliance.org/ â Http://www.wikipedia.org â http://agilemanifesto.org/ â http://www.agilemanifesto.org/principles.html
- 44. Q&A
- 45. Thank You