Agile scrum induction

  • 1,755 views
Uploaded on

Agile & Scrum Basics for Inducting a new team

Agile & Scrum Basics for Inducting a new team

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,755
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
2
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Steps - Product Owner starts by explaining a user story to team Story can be further divided at granular level task (Action Items) Story can have multiple tasks These task would be estimated for efforts required to develop each Every team member can write his estimated Story Point on a Card Play card are collectively displayed to everyone For example 1,2,4,6,6,4,8,8,12 are the cards shown by a team Outliers can be picked up first for analysis Like 1 and 12 would be analyzed first in above example Developer/team will provide prospective and insight for tagging them 1 and 12 And this discussion can address more insight over what exactly is to be developed Estimate can be done on teams agreement on a number. As a practice team can pick an estimate for general understanding .
  • Held daily 15- Minutes (no longer, otherwise it’s not a daily stand up) Not for problem solving (if there are issues that need to be addressed hold a separate meeting) Is not a status for the scrum master or project owner. It’s commitments in front of peers Fix Place – Hold the daily scrum in the same place at the same time every work day. Time – Best time is early in the morning so that the first thing team members do on arriving at work is think of- What they did the day before? and, What they plan to do today? All team members are required to attend. Cannot attend in person, by phone or by having another team member report on the absent members status. Team members must be prompt. The scrum master starts the meeting at the appointed time, regardless of who is present. Each team member should respond to three questions only: 1. What have you done since the last daily scrum regarding this project? 2. What will you do between now and the next daily scrum meeting regarding this project? 3. What impedes you from performing your work as effectively as possible?
  • Focus on acceptance criteria . You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done. Start with the demo in mind . Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story. Prepare . Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Selenium if necessary to get your app into a state where you can start an interesting demo. Practice . Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Snagit and record yourself giving the practice demo. Painful, huh? That just means you need to work on it. Tell a story . Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable. Keep it short . If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.
  • Velocity can be calculated by Using historical data Running an iteration Making a forecast Example: In last iteration team completed 3 user stories (where Story 1 is having 5 story points, Story 2 had 4 and Story 3 had 2) then Velocity is 5+4+2 = 11 Story Points. Iteration can be planned using velocity. Release planning is based on Velocity

Transcript

  • 1. Agile Induction -Priyank [email_address]
  • 2.
    • Most of material in this presentation has been
    • inspired (please read as “reused”) from a number of sources,
    • I take it as
    • “ Don’t reinvent the wheel”
    • and
    • “ Spreading the good words around”
  • 3. Objective
    • Overview to Agile
      • Manifesto of Agile
      • Agile Values and Principles
    • Overview to Scrum
      • Scrum Basics
      • Scrum Roles & Responsibility
    • Scrum Practices
      • User Story, Backlog, Test, Develop
      • Planning, Estimation, Standup Demo, Retro
    • Metrics
    • Meetings and Reporting
  • 4. SDLC Process
  • 5. I Overview to Agile
  • 6. Manifesto for Agile © Agile Alliance http://agilemanifesto.org
  • 7. Agile Principles © Agile Alliance http://agilemanifesto.org
  • 8. Agile Principles cont.. © Agile Alliance http://agilemanifesto.org
  • 9. Agile Methodology © & Reference http://blog.klover.se/
  • 10. II Overview to Scrum
  • 11. Typical Scrum Lifecycle © Scot Amber http://www.ambysoft.com/essays/agileLifecycle.html
  • 12. Sprint activities & roles Release n User Stories Sprint 1, 2, ..n Update product Backlog Sprint Planning Meeting > Daily Scrum > Daily Work Product Backlog Product Backlog Burndown Sprint Backlog Sprint Burn down Impediments list Sprint Retrospective Sprint Review Product Increment Sprint Cycle > Daily Cycle > Product Owner Scrum Master Stakeholders Scrum Team End Users © Scot Amber http://www.ambysoft.com/essays/agileLifecycle.html
  • 13. Scrum Size: Scrum team is of 8-10 team members while few of the team cab be small in size and have only 3-4 team members
  • 14. Scrum Team
  • 15. Extended Release Team Note essential to have a separate Release team as Scrum can integrate
  • 16. Overall picture
    • Roles
    • Practices
    • Product Owner
    • Scrum Master
    • Stakeholders
      • Customer
      • End customer
      • Managers
    • Scrum Team
      • Developer
      • Tester
      • Business Analyst (occasionally)
      • System Integrator
      • User Interface Developer
    • Mentor or Coach
    • Engineering
      • TDD, Refactoring, Pair programming
      • Release
        • Done
      • Iterative Development
      • Automated testing
      • Continues Integration
    • Environment and Behavior
      • Thinking
      • Collaboration
      • Self organization
    • Project Management
      • Planning, Estimation by Poker
      • Stand-up, Burn down, Velocity, Retrospective, Demo
  • 17. Roles
    • Product Owner
    • Scrum Master
    • Owns Product Backlog
    • Defines Features
    • Prioritizes Requirement
    • Details requirement related questions
    • Accept or Reject work product
    • ROI
    • Release Planning
    • Communication with Stakeholders
    • Helps the team achieve success using Scrum
    • Serving the team
      • Facilitate the team’s group interactions to help the team achieve its full potential
      • Helps to remove blocks that are surfaced by team members
    • Protecting the team
      • Protects the team from outside interference or disruption
      • Raise uncomfortable issues within the team
    • Supporting the team’s use of Scrum
      • Organizes and facilitates Scrum-related practices
      • Scrum “conscience” of the team over standard Scrum practices
  • 18. Roles cont..
    • Scrum Team
    • Stakeholders
    • Self organized team
    • Cross Functional
    • Share Commitment
    • Possesses all the skills necessary to produce an increment of potentially shippable product
    • Requirements
    • Reviews
    • Feedback
    • Approvals
  • 19. III Scrum Practices
  • 20. Scrum Practices we will look at
    • User Story
    • Sprint Planning
    • Estimation/Planning Poker
    • Product/Sprint Backlog
    • Development /Code
    • Testing
    • Release
    • Demo/Review
    • Retrospective
    • Burn-down
    • Velocity
    • Scrum of Scrum
  • 21. User Story
    • User Story is the basic unit of scope in an Agile Project. It describes the who, what, why of a requirement.
    • Epics -Epics are large user stories , typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point
    • Themes- A theme is a collection of related user stories .  Themes are often used to organize stories into releases or to organize them so that various sub teams can work on them.
    • Feature - Initial User Stories (Formal) in our DevFactoy release is planned by feature.
    “ User stories are very slim and high-level requirements artifacts”
      • A good example for writing user story is -
            • As a <<User>>
            • I want to <<Goal>>
            • So that <<Value>>s
    User –a user of product Goal –feature user needs to increase value of Product Value –why feature is important
  • 22. Estimation
    • Product Estimation/ Roadmap
    • Release Estimation
    • Sprint Estimation
    Sprint 1 Sprint 5 Sprint 2 Sprint 3 Sprint 4 1 3 5 Planning Poker Release
  • 23. Sprint Planning
    • 4-6 hours (max) for team to select Product Backlog and set Sprint Goal with Product Owner
    • Attended by Product Owner, Scrum team, customers, management in order to define what to build in the next Sprint
    • Team selects as much Product Backlog as it believes it can develop during the next Sprint.
    • Product Owner and customer devise Sprint Goal (which is the business value that the product increment must deliver regardless of functionality implemented).
    • 4 hours (max) for team to define Sprint Backlog
    • Attended by Product Owner, Scrum team, development management in order to define how to build the product functionality into a product increment in the next Sprint.
    • Team defines Sprint Backlog, consisting of all tasks that need to be completed during Sprint.
    • Team members sign up for work and estimate their tasks.
    • Tasks are 1-16 hours long (XP suggests 1-3 days); if longer, break them down into more granularity.
  • 24. Planning Poker
    • Individual stories are presented for estimation. After a period of discussion, each participant chooses the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again .
    • By steps-
    • Product Owner starts by explaining a user story to team
    • Every team member thinks/writes about his estimated Story Point for that story.
    • Estimated are collectively displayed to everyone
      • For example 1,2,4,6,6,4,8,8,12 are the cards/estimates shown by a team
    • Outliers can be picked up first for analysis
      • Like 1 and 12 would be analyzed first in above example
      • Developer/team will provide prospective and insight for tagging them 1 and 12
      • And this discussion can address more insight over what exactly is to be developed
      • Estimate can be done on teams agreement on a number.
      • As a practice team can pick an estimate for general understanding.
      • Rules : Don’t go to details & Park the question for later sprints , Time Box,
  • 25. Planning Poker cont Clarity ? Tester Coder UI Dev Tester Coder Coder 4 8 3 2 4 1 User Story Planning Poker Outliers Discussion Estimates
  • 26. Daily Stand-Up
    • Held daily
    • 15- Minutes (no longer, otherwise it’s not a daily stand up)
    • Is not a status for the scrum master or project owner.
    • Each team member should respond to three questions only:
      • 1. What have you done since the last daily scrum regarding this project?
      • 2. What will you do between now and the next daily scrum meeting regarding this project?
      • 3. What impedes you from performing your work as effectively as possible?
  • 27. Development
    • Developer picks & owns the high priority stories from sprint backlog.
    • Elucidates/Clarifies the requirements if needed with PO/Stakeholders
    • Codes, Unit Test
      • TDD, Pair Programming for Coding
      • Automated testing, Manual Testing
    • Incremental build & Hourly build
    • Testing on various Environment.
    • Collaboration & Knowledge sharing on wiki
    • Coding Standard, Architecture
    • Zero Defect Policy
    Done : • All COS met for user story. • All the test cases executed.                • Defects closed. • Rally is updated. • Selenium testing • Demo prepared. • Peer review of code/Test cases
  • 28. Testing During an Iteration After an Iteration In Integration , System Test & UAT Bug Tracking Test @ Sprint Test @ Release Test Environment Skill Requirement Automation Manual
  • 29. Sprint Demo or Review
    • Show for stakeholder about what we did in the current sprint ?
    • Team prepare for demo using
      • Completed story
      • Acceptance criteria
      • Backlog
      • Open defects
    • Benefits
      • Its for frequent and early reviews
      • Get feedback on design and requirements
    • Hints
      • Focus on acceptance criteria.
      • Start with the demo in mind.
      • Prepare.
      • Practice.
      • Tell a story.
      • Keep it short
  • 30. Retrospective
    • During the sprint retro/review the project is assessed against the sprint goal determined during the Sprint planning meeting.
    • Ideally the team has completed each product backlog item brought into the sprint, but it is more important that they achieve the overall goal of the sprint.
    • Team discuss opportunity & experiences they feel gone wrong and right during the sprint and most importantly what is client feedback on last delivery/demo .
  • 31. Release
    • Schedule Go Live
    • Regression Test, Pre Integration Test, Code Freeze Test.
    • Monitor check-in deadlines, Commit, Monitor Sprints
    • Integration
    • Benchmark current production release for performance
    • Code Freeze
    • Go no Go meeting
    Running Tested Feature
    • Test
    • Integrate
    • Code Freeze
    • Done
  • 32. IV Metrics, Meetings and Reporting
  • 33. Burn-Down
    • Burn-down Chart shows the estimated number of hours required to complete the tasks of the Sprint.
    • It shows both the status and rate of progress (“velocity”) in a way that is both clear and easy to discuss.
    • Posted visibly.
    • Similar to earned-value chart if you count the delivered functionality (instead of development effort) over time.
    • Blue = Task to do and Green = Accepted Points
  • 34. Velocity
    • Velocity is a measure of how much Product Backlog (Sum of Story Points) the team can complete in a given amount of time.
    • Velocity is unit less measure of progress. It can be measure by Feature delivered in an iteration. Feature are usually initial stories.
    • Iteration can be planned using velocity.
    • Release planning is based on Velocity
  • 35. Scrum of Scrum
    • Scrum for managing multiple Scrums
    • 10 -20 Minute Meeting
    • Multiple Scrum meet & discuss progress, process and project.
    • Discuss dependency & interfacing info
    • Resource pooling
    • Issue discussion and resolution
    • Dependency
    • KT
    • Training Plan
    • Risk Management
  • 36. Weekly Sync
    • Sync is a weekly activity.
    • Each Team presents its progress to Stakeholders based on set indicators like
      • Features planned and delivered
      • Open defects
      • Defect reported in production
      • Preproduction defect
      • Utilization
      • Billability
      • You can think of creating simple excel charts
  • 37. Question ? Retrospective
  • 38.
    • Contact
    • Priyank
    • Phone: +91-8108894236
    • Email & Chat
      • [email_address]