1 Footer Agile Training – Scrum Teams

2 Footer Michael S. Rosenberg Certifications: Certified Scrum Professional Certified Scrum Product Owner Certified Scrum Master About Me Trained full Scrum teams and Product Owners in: United States | China | Poland | India | Spain Publications: Creating High-Functioning Development Teams Tending to the needs of individual members on an Agile team

3 Footer Agenda Slides Exercises Multitasking Know your team 1 Know your team 2 Iterative towns Know your team 3 Agile Overview Scrum Overview The Scrum Roles The Meetings The Backlog Estimation Story Points The Sprint Tracking Progress Done?

4 Footer Multitasking Exercise Every employer loves to hear that you are GREAT at multitasking. The truth is, Multitasking is not efficient and here is why. Volunteer? 1 A I

5 Footer Agile Overview Iterative development Building and releasing small chunks of code rather than one large chunk The ability to inspect and adapt the product during the building process Quicker time to market Older development practices say “Plan the work and work the plan” any deviation from the plan means scope change! Agile development allows for changes at times during the development process because is it more nimble.

6 Footer What are the focuses in Agile? Agile development focuses on:

7 Footer The difference between Waterfall and Agile The main difference between starting a new project in agile vs. Waterfall… Waterfall: Plan the project, delivery dates, cost etc. and obtain the resources to make it work. Agile: Build teams and plan project estimates around development capacities Waterfall process Agile (iterative development)

8 Footer Agile Manifesto Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage Working software is the primary measure of progress Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

9 Footer Core Agile Principles CharacteristicDimension Eliminate WasteSpend time only on what adds real customer value Amplified LearningWhen you have tough problems, increase feedback and collaboration Leave Options Open as Long as Possible Maintain multiple options and decide on options as late as practical, but no later Deliver as Fast as Possible Deliver value to customers as soon as they ask for it Empower the TeamLet the people who add value use their full potential Build Integrity inDon’t try to tack on integrity after the fact – build it in See the WholeBeware of the temptation to optimize parts at the expense of the whole

10 Footer Agile Umbrella Agile Umbrella

11 Footer Principles of Scrum Team based projects means that as a scrum team member you are never alone. You are now in a fully collaborative environment Self organized teams give you more power during the time boxed development cycle The requirement for Frequent Deliveries of small chunks of code mean value based organization and fast paced development. Scrum projects are fully visible so and can be seen through the organization – Scrum Boards, Demos etc

12 Footer Empirical Process Transparency Artifacts Project Vision Statement Prioritized Product Backlog Release Planning Schedule Meetings Sprint Review Meetings Daily Standup Meetings Information Radiators Burndown Chart Scrumboard Three pillars that Scrum functions upon are: Inspection Inspection in Scrum is depicted through: Use of a common Scrumboard and other information radiators Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning processes. Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process. Adaption Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Adaptation in Scrum is depicted through: Daily Standup Meetings Constant Risk Identification Change Requests Retrospectives

13 FooterSprints Factors to consider... How long the business can go without requesting a significant change Need to validate progress (rapidly changing requirements or short projects) Ability to reliably predict effort on tasks four weeks out Most commonly last 2 weeks, 3 weeks, 4 weeks

14 Footer Scrum Process

15 Footer Tuckman’s Stages of group development

16 Footer No team starts out high functioning It takes time, practice and a lot of fun to become high functioning Individuals must be comfortable with each other willing to take and give feedback Ready to learn and do extensive team build exercises Retrospectives are a great time to work on team improvements as well as process improvements.

17 Footer Scrum Team

18 Footer Product Owner / BA On a large project many BAs are distributed to teams to help the overall Product Owner Define the features of the product Decide on release date and content Achieve maximum profitability of the product Prioritize features according to market value Adjust features and priority as needed Accept or reject work results Interface with business stakeholders Prepare the most important items on the Product Backlog for consideration at the Sprint Planning meeting

19 Footer Scrum Master A team guide and coach who works closely with the Product Owner and Development Team. Help the Team to be fully functional and productive Enable and enhance collaboration between all team members Manage impediments to Team work flow Protect the Team from external interference Help the Team define and excel at their chosen process for getting work done Facilitate meetings

20 Footer Development Team Responsible for building the product with high quality. Cross-functional, with seven (plus/minus two) members Selects the Sprint goal in collaboration with the Product Owner Is empowered to make decisions on how work is done, who does it and how the process will evolve Organizes itself and its work Demonstrates work results to the Product Owner and Stakeholders

21 Footer Working on a development team Development teams may propose stories for the product backlog Teams take time to mature The development team is self-organizing There is no more “I” on it team it is “We” Development teams help each other

22 Footer What is a Backlog? A list of features that will be produced during sprints.

23 Footer What’s in a Backlog User Stories – any item that has value towards the customer is considered a user story Chores – Items that need to be done but have no actual customer value - Such as mockups, prototypes, Spikes (type of chore ) pre-work research – learning a new technology - Before implementing something.

24 Footer Epic Backlog Hierarchy User Story Tasks Business Goals Planning Implementation Product Backlog Sprint Backlog

25 Footer As a frequent flyer, I want to see/check my account. As a frequent flyer, I want to... Frequent flyer As a frequent flyer I want to book a trip using miles. As a frequent flyer, I want to rebook a trip I have taken before As a frequent flyer, I want to request an upgrade. As a frequent flyer, I want to see if my upgrade cleared. As a frequent flyer, I want to book a trip. How a story breaks down

26 Footer Daily Standup Mandatory meeting for Scrum team A time for the team to update each other on their work Anyone is allowed to sit in, but only team members may speak. Each member explains: o What they worked on since the last daily standup o What they will work on until the next daily standup o Any impediments they have preventing them from continuing their work Held at the same time and place every day Lasts no more than 15 minutes

27 Footer Backlog Grooming Run by the Product Owner, or BA In this meeting, the scrum team and BA will review the upcoming Backlog stories. They will use this time to ask questions about the stories and help to refine them Give story point estimates & estimated hours for stories Mandatory meeting for Scrum team & BA Should occur once - twice a week for 1 hour Does the development team have enough information to do their job? Yes – its enough No – give more detail Dev team – if you feel you don’t have enough info… ask for more Its ok to ask questions Scrum encourages this.

28 Footer Sprint Planning Mandatory meeting for Scrum team & Product Owner / BA Team members and Product Owner agree on which product backlog items to build Team members define the tasks for each product backlog item and organize them into a sprint backlog Team members make a commitment to themselves and the business about what is going to be completed in the sprint

29 Footer Sprint Review At the end of the iteration the team presents their work to stakeholders for final review This is a time for developers to show off their work to the business and receive feedback Often times teams will forgo the Sprint Review and show features to the BA for approval during the sprint in a UAT (User Acceptance Test)

30 FooterRetrospective At the end of each sprint, or release the team meets to discuss their process. The common questions that come up are typically o “What Worked”, “What Didn’t Work” “What Can We Do Differently” (What can we do to improve) Also a good time to discuss o Team Dynamics o Team Building Exercise

31 FooterEstimation Done during grooming sessions Estimations can be given in: o Point Size o Hours o or Both Allows the BA to organize the Backlog before planning Knowing the size / hours required for a story allows for best practice planning by comparing the quantity of work to team capacity Estimates are not targets or commitments

32 Footer How Long Will It Take... to read the latest Harry Potter book?Estimation Story Points = Size comparison

33 Footer Fibonacci Sequence Creates relative size between stories By estimating stories before working on them, we know how much we can handle. o If you continuously complete 34 points over multiple sprints, we know that 50 points is to much to commit to at once.

34 Footer Size Comparison

35 Footer Putting it all together….

36 Footer Sprint Termination Abnormal Terminations If change cannot be kept out of a Sprint... The Sprint may be abnormally terminated An extreme circumstance, not done very often Raises visibility of priority changes

37 Footer Lego City Exercise

38 Footer Task board

39 Footer Primary method of tracking progress A burndown chart shows how much work is left as of various dates Burndown Chart

40 Footer Predicting the End Date Burndown Chart Results Ideal TeamGreat Team Nice Team Working too hard Not working hard enough Work added after start of sprint Over estimated Under estimated

41 Footer How do you know you are done? What one person thinks “Done” is may be different than what you think. As a team you need to define what it means to be done.

42 Footer What’s Next? Get to know your team Define Definition of Done Create Working Agreements 42

43 Footer Agile Training – Scrum Teams