Agile Project Delivery Using Scrum

1. Agile Project Delivery Using Scrum

2. Training Goals • Understand Scrum at a high level • Understand the basic principles and practices of Scrum • Appreciate how scrum processes can help teams practice self-directed leadership • Understand that our learning will be iterative

3. Think “out-of-the-box” • Scrum is founded on sound industry accepted project management practices • Open our mind to new concepts.

4. Agile & Scrum Overview

5. All Agile frameworks share a common philosophy • The Agile Manifesto • www.agilemanifesto.org Individuals and Interactions Working Software/Product Customer Collaboration Responding to Change

6. What is Scrum? Scrum is an iterative framework for developing any product or managing any work. • Iterative and incremental • Project progresses in series of short iterations • Product increment delivered at end of each iteration • Self organizing & cross-functional team • Direction provided primarily at beginning and end of each iteration • Team works collectively to plan and organize their work • Very collaborative • Makes everything highly visible through constant communication and collaboration.

7. Scrum Flow

8. Scrum Components • Major components of Scrum • Release • Completion of a major component of work. • Consists of multiple iterations • Release Preparation occurs at the beginning of a release • Iteration • Time box (10-20 days) • Completion of a small increment of work • Multiple iterations in a release

9. Project Team Iteration Master End Users Scrum Team Dr. Quicksall & “Sampling Team” Product Advisor (Faculty/TA Coach)

10. Roles – Product Advisor (aka Product Owner) • Coaching Responsibilities • Trains and Mentors the Scrum team • Guides the Iteration Master to follow and maintain the process • Defines the features of the product • What Stakeholders want • What goes into the product • Decides on the release dates and content • Responsibilities • Prioritizes the user stories in the Product Backlog • Ultimate decision maker on requirements issues • Negotiates Acceptance Criteria for work results (Faculty/TA Coach)

11. Roles – Iteration Master (aka Scrum Master) • Member of the Scrum team • Facilitator, not manager • Keeps the process moving • “Enforces” the Scrum framework(w/help of coaches) • Ensures full-team involvement in all meetings • Keeps everything visible • Advocate for improved practices • Communicate impediments and successes • Tracks and communicates progress of team

12. Roles – Scrum Team • Cross functional, self organizing and self managing • Self motivated to help the team succeed • Works to solve problems & produce product increments • Follows Scrum practices and organizational policies • Innovative • Looks for ways to design, build, document with less effort • Looks for ways to create a better product • Adds new ideas or issues discovered to the Product Backlog • Stays focused on the iteration goals and commitments

13. Self-Directed Teams • Responsible for planning, managing and executing work • Team plans work together • Team determines approach for completing work • Each person volunteers for tasks. Tasks are not assigned. • Works together to meet goals • Step up to help team members succeed • No “not my job” • Provide solutions and feedback • Abide by team decisions • Responsible for team success or failure

14. Scrum Release Preparation

15. Release Preparation • Visioning – Team collaborates to establish the detailed project vision and understand the expected outcomes of the project. • Roadmapping- Map out the long term plan for how the product will evolve over time and establish optimal release windows • User Story Workshop – Create, estimate, and prioritize user stories for the project • Release Planning – Review the Product Backlog to plan the release timeline and iteration planning activities

16. Visioning • Overview • Initial meeting with the Scrum team to review from a business perspective, collaborate, and agree on the… • … goals, value, vision for completing the project • … scope, stakeholders, architecture impacts, and tool requirements. • Opportunity to agree on the team working agreement • Outcomes • Team alignment on project scope and expectations • Team Working agreement • Initial Issues and Risks

17. Vision Statement Team collaborates to establish the project vision and understand the expected outcomes of the project. Some team choose to create a vision statement: For research scientists who would like to remotely access a well, sample the water, and test it on site, the Quicksall.org initiative will provide researchers a robot that can self-navigate a variety of terrains, sample from various well types, and perform on-site testing and remediation

18. Roadmapping • Overview • Opportunity to create a Product Roadmap • Shows how the product and architecture may evolve to deliver desired features and benefits to specific user or customer groups. • Determine high level milestones that could affect the project. • Can include product release dates, infrastructure upgrades, important customer milestones or any other significant date that could impact the project. • Determine any dependencies between milestones, architecture, and features to be developed for customers • Outcomes • A long term view of the Product Roadmap with any dependencies associated with customers, features, events, rhythms, and the architecture.

19. Roadmapping – Simple template • Recommendation of 5 rows labeled as indicated. Add other rows as needed • Low tech (sticky notes) good way to collaborate HQ TM and Selected Field Rel 2.2 Enabled SSO Web-based Reporting Licensing ETL to SCW Xcelsius / Weblogic / Oracle Master Geography Freeze Aug 7 and Sept 7 Freeze May 6th Release 2 Release 2.2 Release 3 Release 1

20. Scrum Release Preparation User Story Workshop

21. User Story Workshop • The User Story Workshop consists of 3 sections • User Story Creation • Project team creates user stories • User Story Estimation • Project team estimates the story points for each user story • User Story Prioritization • Product Advisor with input from the Scrum team places the user stories in priority based on customer need and business value

22. User Story Creation • Overview • Initial opportunity for the team to review, discuss, and document requirements for the project as user stories. • In Scrum a requirement is documented as a user storywhich is placed in the product backlog. It is the responsibility of the Product Advisor to review, prioritize and approve all user stories placed in the product backlog. • Outcomes • An initial set of user stories for the project

23. User Stories – Backlog • Product Backlog • List of all requirements in the form of user stories • Prioritized by the Product Advisor • Items can only be added or removed by the Product Advisor • Iteration Backlog • User stories chosen to be worked in this iteration • Created by the team from the product backlog • Highest priority product backlog items Iteration Backlog Product Backlog

24. User Stories - Key Features • Key Features • High-level features of the product being developed • Defined in Visioning • Used as a starting point to create user stories

25. User Stories – Quicksall.org Examples

26. User Stories – What are they? • Easy to use and manage approach to writing requirements • A short, plain-language description in terms of customer value • Created during story-writing workshops at the beginning of the project, and then augmented during the project • Augmented by screen mock-ups, design diagrams or any other artifact that enhances understanding of the story. • Anyone can write a user story

27. User Stories – Why User Stories? • Stories are easy to understand • Developers and customers understand them • People are better able to remember events if they are organized into stories • Stories are the right size for planning • Support and encourage iterative development • Can easily start with very large stories and epics then break down close to development time • Stories support flexible and efficient development

28. User Stories – Should follow INVEST Avoid dependencies on other stories Leave or imply some flexibility Identify value to the customers, not developers Enough detail to estimate. Must get done in a single iteration Acceptance criteria should be identified Independent Negotiable Valuable Estimable Small Testable INVEST coined by Bill Wake

29. User Stories - Personas • Personas • A role identified that will use or interact with the developed product • Can be the product itself or components of the product • Can be real people or roles in an organization

30. User Stories - Format • User Stories are comprised of 3 parts • As a/an <persona> • I want/I need <function> • So that <reason> • As an Unregistered User I want to be able to enter my name and contact information so that I can create an account to become a registered user. • As an Administrator I need a report so that I can see who is a registered user for my application. • As a Registered User I need to change my password so that my personal information is secure. • As an Purchaser I want to create a wish list of books so that I can return to purchase them at a later time.

31. User Stories – Quicksall.org Examples • As Uganda Research Scientist I want a robot that can autonomously maneuver from one location to another on a level playing field so that I have the ability to get well samples from Uganda. • As Professor Quicksall I want a robot that can differentiate the playing field boundary from the obstacle so that I can identify the location of the wells. • As Professor Quicksall I want a robot that can identify the obstacle by reading a series of tape lines so that I can determine which well has been encountered.

32. User Stories – Card Layout

33. User Stories - Confirmation • Confirmation methods are written on the back of the card • Include conditions of satisfaction or acceptance criteria • Essentially test cases that address various scenarios and questions

34. User Stories – Spur Conversation • The card only covers the most basic information • The next level of detail comes in conversations between the Product Advisor and the Scrum team • The conversations take place • At Project inception, during story writing sessions • During the Iteration Planning Meeting • During the iteration

35. Quicksall.orgUser Story Creation • Take 30 minutesto create user stories For research scientists who would like to remotely access a well, sample the water, and test it on site, the Quicksall.org initiative will provide researchers a robot that can self-navigate a variety of terrains, sample from various well types, and perform on-site testing and remediation Value Statement • Personas • Quicksall.org reps • Research Scientists • Create others if needed

36. Scrum Release PreparationUser Story Estimation

37. User Story Estimation • Overview • User Story Estimation is the initial opportunity for the Product Advisor and Scrum team to review and estimate the relative user story points for each user story. • Outcomes • An initial set of estimated user stories

38. User Stories – Using Story Points • User stories are estimated in user story points not time. • Advantages to story points versus time estimates • Estimating is very quick because it is an intuitive estimate • The estimate indicates an item’s size relative to another, and does not give the illusion of being precise. • Estimating time can be hard, but we are all good at comparison.

39. User Stories – What is estimation? • Notes on Story Points • Scrum team does the estimation, not the Product Advisor • An estimate of size, risk, and complexity – NOT TIME • Relative sizing of items is the key • Points cannot be transferred between teams • Points are based on teams that are stable throughout the development process 1 13 5 2 3 8 20 40

40. User Stories – Estimation “Planning Poker” • Planning Poker • Collaborative estimation method to help the team align on the relative size and complexity of each user story • uses multiple card decks each consisting of 8 cards numbered 1, 2, 3, 5, 8, 13, 20, and 40.

41. User Stories – “Planning Poker” Rules • Iteration Master selects and reads the highest priority user story that has not already been estimated • Team briefly discusses the user story • Scrum team members SIMULTANEOUSLY show their selected card representing the story point estimate • The high and low team members in turn discuss why they selected the value they did (try to keep to less than 5 minutes for the total discussion) • The Scrum team then re-votes based on the views presented • The Iteration Master writes the value on the card and this becomes the story point value • Repeat the process for the next highest priority user story

42. Scrum Release PreparationUser Story Prioritization

43. User Story Prioritization • Overview • Opportunity for the Product Advisor, with input from the Scrum team to review and place the user stories into a prioritized order based on business value and customer need. • Outcomes • A set of prioritized project user stories

44. User Stories - Prioritization • User stories are prioritized by the Product Advisor with input from the Scrum team. • Highest priority user stories should be delivered during the earlier iterations • Prioritization methods • Business Value • Product Advisor opinion • Technical Feasibility • Internal voting • Survey customers

45. Quicksall.orgEstimation & Prioritization • Use the Antique Dealer ecommerce user stories already created • Take 20 minutesto estimate the story points for each • Review the user stories created previously with the group • Estimate the user stories using “Planning Poker” cards • Take 10 minutesto prioritize the created user stories • Review the user stories previously estimated • Product Advisor and Scrum team prioritize the user stories based on what needs to be completed first or has the most business value. • Place the user stories on the table in priority order

46. Scrum Release PreparationRelease Planning

47. Release Planning • Overview • Establish a plan and goals that the team can understand and communicate relative to the release of the project • The release plan establishes the goal of the release, the major risks, the features and functionality that the release will contain. It also establishes a probable delivery date • Outcomes • A determination of the user stories required for a release • The timing required for a release and functionality available • Documented activities required to perform a release

48. Release Planning – Determine Iterations • Scrum team determines how much work can be accomplished in each iteration.

49. Scrum Iteration ExecutionIteration Planning

50. Iteration Execution • Overview • Where the majority of work for the project gets completed • Each task created for the iteration is selected by a team member as a work function • During this time that team member is responsible for working toward completing that task • Outcomes • Working product, reviewed, and accepted by the Product Advisor • Team has reflected on the work and has a plan to improve