Delivering Agile Projects with Scrum

Introduction Welcome to Delivering Agile Projects with Scrum Emergency phone number Local emergency exit procedures Floor and facility layout Start and end expectations Breaks Attendance Agenda Passing this course Ground rules 1

Introduction Course Overview Module 1: Overview of Scrum Module 2: From a Vision to a Roadmap Module 3: Prioritizing the Backlog Module 4: Sprint Planning and Backlog Grooming Module 5: The Daily Stand-Up Module 6: Sprint Review and Retrospective 2

Introduction Course Objectives By the end of this course, you will be able to Describe the Scrum framework from start to finish Evaluate the values and the principles that drive many of the agile practices within the Scrum framework Explain and create Scrum artifacts Identify key roles and responsibilities within an agile project managed using Scrum Apply the Scrum framework to future projects 3

Introduction Introductions Please share: Your name and role Your current or most recent employer or job title What your experience is with agile What you expect from this training experience 4

Module 1 Overview of Scrum 1-1

Module 1 Module Objectives By the end of this module, you will be able to Evaluate agile principles and values Explain Scrum and the Scrum framework Describe Scrum values and pillars Identify roles and responsibilities in Scrum 1-2

Module 1 The Project Life Cycle 1-3

Module 1 Traditional and Agile Project Constraints 1-4

Module 1 Top Challenges/Drivers for Change Traditional methods have a number of challenges, including: Initiating challenges: The team is not involved in initiation. Planning challenges: Sometimes, there is forced scope management. Execution challenges: Change requests are hard to implement and are discouraged. Monitoring and Controlling challenges: Variances (including improvements) are seen as a deviation. Closing challenges: The customer encounters the deliverable for the first time. 1-5

Module 1 History of the Agile Movement In response to these challenges and failures, agile methods have been developed emphasizing the incremental delivery of working products or prototypes. 1-6

Module 1 Creation of the Manifesto for Agile Software Development The Manifesto for Agile Software Development Is known also as the Agile Manifesto Was created in 2001 by a group of advocates of iterative and incremental development methods Is the foundation document of the agile movement, which sets forth the underlying philosophical concepts of agile project management and includes a set of 12 principles 1-7

Module 1 The Agile Manifesto Manifesto for Agile Development "We are uncovering better ways of developing products by doing it and helping others do it. Through this work, we have come to value: "Individuals and Interactions over processes and tools "Working products 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." 1-8

Module 1 Agile Principles 1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. "Welcome [accept] changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. "Deliver working software [business value] frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. "Business people and developers [the team] 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 team is face-to-face conversation." 1 1 www.agilemanifesto.org 1-9

Module 1 Agile Principles (continued) 7. "Working software [value delivery] 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 fine tunes and adjusts its behavior accordingly." 1 1 www.agilemanifesto.org 1-10

Module 1 What Is Scrum? A development framework based on empirical process control wherein cross-functional, self-organizing teams deliver working software every 30 days (or less). 1-11

Module 1 Scrum Said Simply... Scrum is an iterative agile framework that is designed to deliver working software (or value) every 30 days (or less) and supports the practice of all agile principles and values Scrum has the following: Roles Ceremonies Artifacts Outputs 1-12

Module 1 Values and Pillars of Scrum Scrum Pillars Transparency Inspection Adaptation Scrum Values Commitment Openness Focus Respect Courage 1-13

Module 1 Exercise 1-1 Reflections on Agile and Scrum 1-14

Module 1 Scrum Artifacts 1-15

Module 1 Who Does What? Roles Artifacts Ceremonies Product owner Team members Scrum master Product backlog: What are we doing?/in what order? Sprint backlog: What are we doing now? Product increment: Delivered at the end of the sprint Burn-down chart: How are we doing this sprint? This release? Sprint planning: What are we doing next? Daily Scrum: How are we doing today? Sprint review: What did we do? Sprint retrospective: How can we improve? Supports ceremonies to ensure fidelity to Scrum 1-16

Module 1 The Umbrella of Methods 1-17

Module 1 The Scrum Team 1-18

Module 1 Phases of Team Development 1-19

Module 1 Scrum Roles Development Team Development Team Character Traits: Customer focused Self-organizing Team players Collaborative Accountable Goal oriented Innovative Servant leaders Focused Flexible Solution driven Courageous Knowledge sharers Empowered Value driven Quality conscious 1-20

Module 1 Scrum Roles Development Team (continued) The team Is responsible for turning the product backlog items into increments of value for each sprint Is cross-functional, 7 +/- 2 Is dedicated Consists of generalizing specialists Delivers value in small chunks Focuses on the customer Builds in quality Is self-organizing Is empowered 1-21

Module 1 Scrum Teams Self-organizing teams will Commit to work and complete it Collaborate to find innovative solutions Unleash creative passion Be active change agents Drive for continuous improvement Share knowledge and mentor each other Deliver value, not costs 1-22

Module 1 Scrum Roles Product Owner Product Owner Character Traits: Customer focused Well respected Team player Strategic Collaborative facilitator Influencer Goal oriented Pragmatic Servant leader Change champion Protective Solution driven Strong communicator Excellent presenter Value driven Focused 1-23

Module 1 Scrum Roles Product Owner (continued) The product owner Is responsible for maximizing the business value delivered by the team Is 1 person responsible for the backlog Accepts or rejects work Sets clear expectations for acceptance Is knowledgeable, empowered, and engaged Colocates with the team as much as feasible Manages stakeholder and sponsor expectations Motivates the team, celebrates success! Can have a team Eliminates potential project wastes 1-24

Module 1 Scrum Roles Scrum Master Scrum Master Character Traits: Mentor Motivator Change champion Protective Solution driven Strong communicator Supportive Positive Servant leader Teacher Well respected Trusting Goal oriented Team player Good listener Facilitator Pragmatic 1-25

Module 1 Agile Roles Scrum Master (continued) The Scrum master Is responsible for facilitating the Scrum process and ensuring the team is delivering value Facilitates the process Helps builds self-organizing teams Removes impediments; escalates to the product owner when needed Helps the team inspect and adapt the process Empowers the team through servant leadership Helps create visible information radiators Protects the team from disturbances Coaches the team 1-26

Module 1 Other Roles Within Your Agile Projects What is the role of the sponsor and stakeholders? What is the role of management? What is the role of the IT architect and control groups? What is the role of executives and leaders in agile? What are common, real-world agile role challenges? 1-27

Module 1 Scrum Roles Best Practices Product owners should not be Scrum masters. PMs should not be Scrum masters without an education on the nuances. Business analysts should not be the only ones who gather requirements. A product owner must have a decision-making ability or power. Testers should be part of the team. 1-28

Module 1 Scrum Roles Best Practices (continued) Create a sprint zero backlog (prioritized product backlog). Provide ongoing agile training for all your teams. Keep an improvement backlog. Rotate the role of Scrum master around the team. Empower your teams to make decisions. Encourage pairing and knowledge transfer. 1-29

Module 1 Key Messages Agile methodologies are a response to traditional waterfall methodologies of product management and development. The Agile Manifesto calls out the specific values and principles of the agile movement. Scrum is a specific agile methodology underpinned by 3 pillars and 5 values. The Scrum process includes specific artifacts and ceremonies. The 3 roles of the Scrum methodology are product owner, Scrum master, and development team. 1-30

Module 2 From a Vision to a Roadmap 2-1

Module 2 Module Objectives By the end of this module, you will be able to Describe how release planning supports the project vision and its backlog Describe release planning and why it is done Describe sprint zero and its application Create an agile project roadmap 2-2

Module 2 From Vision to Product Backlog 2-3

Module 2 Product Backlog 2-4

Module 2 User Story Life Cycle 2-5

Module 2 Release Planning 2-6

Module 2 What Is Sprint Zero? Sprint zero answers the following questions: What is the business idea/vision of the project or product? What is the definition of done and criteria of success? Who is on the Scrum team? Does everyone know how to do Scrum? Who are our customers and or stakeholders? What does the team need to do to prepare for the first sprint? What does the organization need to do to prepare for the first sprint? What does the developer need to do before they write code? 2-7

Module 2 Sprint Zero Checklist Vision Release plan Prioritized product backlog Agreed-upon story estimation technique Defined sprint length Team Testing agreements Team environments Architecture Risks and issues Resource management 2-8

Module 2 Roadmap Not part of the Scrum framework Typically done after a team or organization has defined their vision for its project, product, or services 2-9

Module 2 Release Planning Vision Are we clear on it? Who are our stakeholders? Who is the product owner? What are our products? Roadmap What is the order in which we want to get things? Who is our Scrum master? Who is our Scrum team? Release plan How do we want to package the product? When would we like to get the product/product increments? Is our product backlog ready? 2-10

Module 2 User Story Life Cycle 2-11

Module 2 Case Study 2-1 Roadmapping 2-12

Module 2 Key Messages A backlog is a list of working items that will be developed by the team in sprints. The backlog is developed by turning the vision into a roadmap, which, in turn, is split into releases. Before actually starting the project, it is recommended to do a sprint zero to make sure that everybody is on the same page and that the team has everything they need to start working. 2-13

Module 3 Prioritizing the Backlog 3-1

Module 3 Module Objectives By the end of this module, you will be able to Describe the MoSCoW (must have, should have, could have, won't have) and Kano methods used to prioritize your backlog Create a sprint calendar Explain user stories and their importance in a Scrum project Write user stories using the INVEST (independent, negotiable, valuable, estimable, small, testable) model, the 3Cs (card, conversation, and confirmation), and the user story template 3-2

Module 3 Prioritization How much should I prioritize? When should I prioritize? 3-3

Module 3 Prioritization Techniques MoSCoW MoSCoW method: Must have Should have Could have Won t have 3-4

Module 3 Prioritization Techniques Kano Model Kano: Uses need and satisfaction to derive Delighters Performance attributes Basic attributes 3-5

Module 3 Sprint Calendar 3-6

Module 3 How Long Should My Sprint Be? Recommend 1 4 week iterations. Determine per project: Supporting unique needs of the project is paramount. Some determining factors include the following: Examples: Length of project Project type Frequency of demos desired by the product owner Product owner tolerance for not adding stories Longer sprints for very large projects (4 weeks) Political climates requiring frequent demos suggest shorter sprints (2 weeks). 3-7

Module 3 User Stories One construct for writing user stories is the 3Cs: 1 Card: The user provides his or her perspective in a brief, simple requirement statement. Conversation: A story is an invitation for a face-to-face conversation. Confirmation: Each story should have a definition of done, which means when the product owner will accept the story. 1 Jeffries, Ron. Essential XP: Card, Conversation, Confirmation. XP Magazine, August 2001, p. 1. 3-8

Module 3 User Story 3-9

Module 3 User Story Formula Follow the INVEST guidelines for good stories: 3-10

Module 3 User Story Life Cycle 3-11

Module 3 Case Study 3-1 Writing User Stories 3-12

Module 3 Scrum of Scrums 3-13

Module 3 Advanced User Story Techniques Epics are either compound or complex: Compound: More than 1 independent story contained within Complex: 1 really big independent story that must be broken down to reduce its complexity. There is an art to doing this. Break large stories (epics) into smaller chunks using Process-based slicing Business-rule slicing CRUD (create, read, update, delete) User or platform slicing Acceptance test slicing 3-14

Module 3 Sample Epic Breakdown Compound Course Registration As a course administrator, I want to load courses for the coming period so that students can register on a course. As a student, I want to register for a course so that I can ensure I can attend. As a course tutor, I want to view details of the course listings so that I can print registration reports. 3-15

Module 3 Sample Complex Stories As an administrator, I want to enroll a new student into the system. As an administrator, I want to enter demographic information for a new student enrollment. As an administrator, I want to enter financial information for a new student enrollment. As an administrator, I want to enter previous course work information for a new student enrollment. 3-16

Module 3 Splitting Techniques Acceptance test based Process based Minimum end to end User/platform Note this is the most popular! Review the acceptance test for the story and determine which one(s) can be sliced into their own story. Draw a process diagram. Identify steps that offer a complete, valuable small deliverable. Use this minimal set of functionality to get the story working end to end; other stories to complete the feature could come later. Break down stories by specific user types of specific platforms (iphone, Internet Explorer, ipad) 3-17

Module 3 The Work Breakdown Process 3-18

Module 3 Example Theme>Epic>Story 3-19

Module 3 Example 2 3-20

Module 3 Acceptance Criteria A set of statements that Has a clear pass or fail result Specifies both functional and nonfunctional requirements for the specific use story Makes it clear when a story is completed and working as expected Is expressed in simple language the customer would use Is unambiguous about what is acceptable and what is not Must be actionable Is easily translated into manual or automated test case(s) Includes what is acceptable for open defects Includes some indication of an expected response time States intent but not the solution Are phrased in solution-agnostic language 3-21

Module 3 Other Nonuser Story Considerations Underpinning foundational stories Infrastructure, technology foundational requirements Clarifying nonfunctional stories Performance, usability, and so on Mitigating risk spike stories Research and analysis Defining levels of defect acceptance Defining maintenance and support requirements and so on 3-22

Module 3 Release Planning Meeting After you have prioritized and estimated the backlog, your next effort is to build the actual plan. Here is generally what comes next: Define what done means for your team. Determine your iteration length. Estimate the initial velocity. Map stories to iterations based on this estimate. Add fall-through, hardening, and prerelease iterations where needed. Arrive at an initial delivery date estimate. 3-23

Module 3 Case Study 3-2 Writing Acceptance Criteria 3-24

Module 3 Key Messages The product backlog is prioritized by business value for the customer. If the backlog is too big for 1 team, then a Scrum of Scrums might be a solution. In order for user stories to be correct, they should follow these rules: 3Cs: card, conversation, confirmation INVEST (independent, negotiable, valued, estimable, small, testable) User story formula (As a USER TYPE, I want THIS FUNCTIONALITY in order to get THIS BENEFIT) Sometimes, user stories are too big (complex or compound) and require splitting. Acceptance criteria are details added to a user story to decide when the story is done. 3-25

Module 4 Sprint Planning and Backlog Grooming 4-1

Module 4 Module Objectives By the end of this module, you will be able to Explain sprint planning and the importance of capacity planning Describe and use story points Estimate user stories Estimate team velocity Explain the purpose of backlog grooming and how it works Perform backlog grooming 4-2

Module 4 Sprint Planning Capacity What is it? The team validates its capacity. The total capacity is used to ensure a sustainable pace. This will determine the velocity at which the team can plan. Product backlog What's the top priority? Validate the user story (requirement). Validate the acceptance criteria. Estimate the user story. Sprint backlog What s going in the sprint? Break down the user story into tasks. Estimate the tasks in hours. Scrum team members sign up and commit to the work. 4-3

Module 4 Sprint Planning (continued) 4-4

Module 4 Estimating It is better to be roughly right than precisely wrong. John Maynard Keynes Relative vs. absolute estimating Relative estimating focuses on size and complexity, which happen at the story level. Absolute estimating focuses on ideal time, which happens at the task level. T-shirt sizing is often used for the relative estimation of bigger, more general work items like the epics. The modified Fibonacci scale is often used to estimate user stories. 4-5

Module 4 Relative Sizing The key concept behind using relative sizing is to compare stories against each other. This approach does not aim for perfection or precision; rather, it aims for relative and simple measures of effort. Story points are a common unit of measure for sizing stories. Using points, we can measure velocity. 4-6

Module 4 Sizing Stories Not time based Size: How large is the story? Complexity: What is the effort involved? What is the risk? What is the impact? How uncertain is the story? What potential problems could arise? How much experience does the team have? 4-7

Module 4 Why Story Points? Are easier and faster to measure and agree upon by the team than hours (the team owns the stories, so individual measurement units are useless) Drive cross-functional behavior Avoid the waste in time and effort associated with getting detailed estimates that change anyway Are a pure measure of size (estimate by analogy: this is like that ) and not timing ( this is when this will be done ) Are unlike ideal time/hour estimates, which will change drastically based on who is doing the work and their skills Are unlike ideal time, which encourages specialization very unproductive (waste) 4-8

Module 4 Story Points Scale for Epics Modified Fibonacci scale for larger epics (themes, features) This scale is also referred to as T-shirt sizing. 4-9

Module 4 Story Points Fibonacci Scale The Fibonacci scale is used for stories sliced to a small, granular level: How many stories a team gets done in each sprint is its velocity. 4-10

Module 4 Planning Poker The rules of Planning Poker are simple: Team gets together and discuss each story with the product owner until everyone has a clear understanding of it. Each person shows his or her card with his or her complexity vote but should not vote verbally so that others are not swayed by 1 person. If there is a major discrepancy, such as a 2 and an 8 vote, the parties hash it out by discussing their assumptions. The team votes again! (This can actually happen a few times.) A decision is reached with consensus! 4-11

Module 4 Team Velocity Understanding the team s velocity will enable release planning. Over time, use multiple data points to derive velocity: Fastest pace Average pace Slowest pace Plan by using your rolling average. NOTE: The first sprints are not very relevant, and their lower velocity can corrupt the average. 4-12

Module 4 Team Velocity (continued) Velocity is a team s rate of progress. It is measured by the number of story points a team can finish in 1 sprint. Velocity is an estimate. It should be a number that reflects the number of stories the team committed to. Velocity can be a measure of performance because in time, based on all the improvements the team will be making, it should increase. 4-13

Module 4 Team Velocity (continued) Factors affecting team velocity include: The number of resources Holidays Vacation Interruptions Multitasking The skill and experience of team members The stage of team development Over time, team velocity is derived from actual data. 4-14

Module 4 Estimating Initial Velocity Ask the team the following question: Which stories do you think you can commit to getting done from this release during the first sprint? Be realistic in your commitment. These stories make up the team's initial velocity. 4-15

Module 4 Velocity and Points 4-16

Module 4 How the Velocity Affects the Release Plan Teams with continuous release cycles build rolling work plans. 4-17

Module 4 Have Realistic Expectations! Remember the team maturity stages? It takes 3 sprints before the team reaches the performing stage! This does not mean it will deliver nothing, but it does mean that the team needs time to work together and become effective. You can expect velocity to start low, get better, and sometimes slow down again, but it will finally become steadily efficient when the team is in its true performing stage. Even when performing, the team can expect to be asked for more points (velocity) if the product owner needs to deliver more. 4-18

Module 4 Case Study 4-1 Estimating User Stories 4-19

Module 4 Advanced Estimating Business Value Business value should be determined relatively and should be justified in at least 1 category: Generates money (new business or up sell) Saves money Improves customer satisfaction Provides market opportunities Meets compliance Improves operational efficiency Mitigates risk Allows for learning 4-20

Module 4 Backlog Grooming Product backlog List any new stories. List any new dependencies. Write the acceptance criteria. Release plan Is the release plan still valid? Is the criteria of success still valid? How are we tracking toward the release plan? Preplan the next sprint The product owner communicates the next sprint goal. The product owner identifies stories that meet that goal. The stories based on business value using MoSCoW and business value points. 4-21

Module 4 Backlog Grooming Drivers A session driven by the product owner Are the customer and stakeholders happy with the current progress? Are there any organizational blockers that need the product owner? Check the product backlog priority is it still relevant? Do we have any new backlog Items? What would you like to see in the next sprint? Is the project/product success criteria still valid? Is the sprint length working? Do we have all the acceptance criteria for the next sprint stories? Are we acquiring any experience? How many new stories are we getting? What kind of feedback are we getting in the review? 4-22

Module 4 Case Study 4-2 Backlog Grooming 4-23

Module 4 Key Messages Sprint planning is the intersection of what should be implemented in the next sprint and how it will get done. The output of sprint planning is the sprint backlog. Stories are estimated using relative scales of story points. Velocity is the measure of points that a team can deliver in a sprint. The product owner grooms the backlog by adding new stories and reprioritizing existing ones. 4-24

Module 5 The Daily Stand-Up 5-1

Module 5 Module Objectives By the end of this module, you will be able to Describe the purpose and features of a daily scrum Explain the best practices of a daily scrum 5-2

Module 5 Daily Stand-Up/The Daily Scrum The daily Scrum Is a short-term planning tool Facilitates team-to-team and intra-team communication It lets teams Discuss project progress Identify shared dependencies Identify project roadblocks Refine schedules Remain synchronized with one another 5-3

Module 5 Daily Scrum 5-4

Module 5 Best Practices for a Daily Scrum A daily Scrum is no more than 15 minutes. Only 1 person speaks at once around the room. All stand during the process. Any impediments not already dealt with are taken and dealt with by the Scrum master, with the appropriate involvement of team members and others. Impediments are never discussed in any detail other than to call them out, It is good practice for the Scrum master role in the daily Scrum to move around the team. 5-5

Module 5 Key Messages The daily Scrum is a 15-minute meeting that facilitates the team's communication and keeps work moving and synchronized. The following 3 questions are answered by each team member: What have you done since the last Scrum? What will you do until the next Scrum? What problems distract you from accomplishing the sprint goals? 5-6

Module 6 Sprint Review and Retrospective 6-1

Module 6 Module Objectives By the end of this module, you will be able to Describe a sprint review Conduct a sprint review Conduct a sprint retrospective 6-2

Module 6 Sprint Review Demo The team demonstrates a completed product increment to the customer. The customer either via the product owner or directly accepts or rejects the items. Review What did we plan to do this sprint? What did we actually do? Is there a delta and why? Customer satisfaction Is the customer happy with the progress? Does the customer desire any change? What feedback are we getting? 6-3

Module 6 Sprint Review (continued) A brief forum to close out the iteration after you have performed a demo on the product increment Move unfinished stories to the product backlog. Review task completion. Discuss any outliers. Agree as a team what was done. Prepare the demo. Ask 3 questions for a review: What did we plan to do? What did we did we deliver? What is the delta and why? 6-4

Module 6 Case Study 6-1 Sprint Review 6-5

Module 6 The Sprint Retrospective The sprint retrospective provides a time to review the team s working practices and processes to ensure that they are as efficient as possible. It discusses What went well? What could have gone better? What could be improved upon in the next sprint? The next few? There should always be things that can be improved. 6-6

Module 6 Best Practices for the Sprint Retrospective Keep it structured and facilitated. Avoid personality issues. Focus on issues like Sprint length Realistic expectations New soft and technical skills needed New efficiencies How many extra points can be achieved How we can work smarter 6-7

Module 6 Case Study 6-2 Sprint Retrospective 6-8

Module 6 Final Course Retrospective Reflect on the content and think about What did I learn about that I currently do well in my agile projects? What did I learn about that I could improve upon and need to study more? What did I learn about that I could implement immediately in my current or next agile project? 6-9

Module 6 Key Messages The sprint review is the ceremony when the team shares publicly what it achieved in the last sprint. The sprint retrospective is the ceremony when the team distances itself from the product and focuses on itself as a team, working to improve processes and efficiency. 6-10

Return to Slide