WT
Uploaded byWilber Tuttleman
PDF, PPTX53 views

SPROTT - STUDENT WORKBOOK - INTRO TO AGILE.pdf

The document is an introduction to Agile and Scrum, presented by Patrick Van Abbema, who has over 25 years of experience in project management and digital transformation. It outlines the fundamentals of Agile Scrum, the roles and responsibilities involved, and contrasts Agile methodologies with traditional Waterfall approaches. Additionally, it discusses the importance of value-driven delivery, team engagement, and planning for successful Agile project execution.

Embed presentation

Download as PDF, PPTX
1 / 150
2 / 150
3 / 150
4 / 150
5 / 150
6 / 150
7 / 150
8 / 150
9 / 150
10 / 150
11 / 150
12 / 150
13 / 150
14 / 150
15 / 150
16 / 150
17 / 150
18 / 150
19 / 150
20 / 150
21 / 150
22 / 150
23 / 150
24 / 150
25 / 150
26 / 150
27 / 150
28 / 150
29 / 150
30 / 150
31 / 150
32 / 150
33 / 150
34 / 150
35 / 150
36 / 150
37 / 150
38 / 150
39 / 150
40 / 150
41 / 150
42 / 150
43 / 150
44 / 150
45 / 150
46 / 150
47 / 150
48 / 150
49 / 150
50 / 150
51 / 150
52 / 150
53 / 150
54 / 150
55 / 150
56 / 150
57 / 150
58 / 150
59 / 150
60 / 150
61 / 150
62 / 150
63 / 150
64 / 150
65 / 150
66 / 150
67 / 150
68 / 150
69 / 150
70 / 150
71 / 150
72 / 150
73 / 150
74 / 150
75 / 150
76 / 150
77 / 150
78 / 150
79 / 150
80 / 150
81 / 150
82 / 150
83 / 150
84 / 150
85 / 150
86 / 150
87 / 150
88 / 150
89 / 150
90 / 150
91 / 150
92 / 150
93 / 150
94 / 150
95 / 150
96 / 150
97 / 150
98 / 150
99 / 150
100 / 150
101 / 150
102 / 150
103 / 150
104 / 150
105 / 150
106 / 150
107 / 150
108 / 150
109 / 150
110 / 150
111 / 150
112 / 150
113 / 150
114 / 150
115 / 150
116 / 150
117 / 150
118 / 150
119 / 150
120 / 150
121 / 150
122 / 150
123 / 150
124 / 150
125 / 150
126 / 150
127 / 150
128 / 150
129 / 150
130 / 150
131 / 150
132 / 150
133 / 150
134 / 150
135 / 150
136 / 150
137 / 150
138 / 150
139 / 150
140 / 150
141 / 150
142 / 150
143 / 150
144 / 150
145 / 150
146 / 150
147 / 150
148 / 150
149 / 150
150 / 150
Grow your career. Level up for the future. Intro to Agile and Scrum Patrick van Abbema
Instructor Bio • Patrick van Abbema, MBA, PMP, CBAP, CSP, CSM, ITIL • Experienced Management Consultant with over 25 years of extensive experience. • I focus on two project management specialty areas: • Agile project management and • Digital Transformation • I have several progressive accomplishments as a senior management consultant in Information Management (IM), Information Technology (IT), Defensive Cyberspace Operations (DCO), Customer Relationship Management (CRM), Organizational Change Management (OCM), Enterprise Resource Planning (ERP), Enterprise Content Management (ECM) and Bimodal IT solutions. I have managed organizational change management initiatives that involved the development of coaching skills, process analysis, technology implementation, strategy development, and operational improvement services. • Linkedin Profile: https://www.linkedin.com/in/pvanabbema/ 2
Agenda Day 1 - Section 1-5 Day 2 – Section 6-14 01. 02.
Exercise - Discussion Thinking back to past projects, what were your biggest challenges (ex., unrealistic schedules)? Using post-it notes, take 5 minutes to write down 3 project challenges you have faced in the past. NOTE – This is brainstorming technique called brainwriting or method 6-3-5 (6 people - 3 ideas in 5 minutes) 4
Logistics • Please mute your phones, and other noise making devices • Feel free to stand up and stretch when you are feeling like you need to wake up or just move about • Interactive – please ask questions
Section 1 Introduction – Fundamentals of Agility 6
Section Learning Objectives • The learning objectives for this section are: – Understand the fundamentals of Agile Scrum – Review the Agile Product Life Cycle – Describe the Agile roles and responsibilities – Contrast Scrum with Waterfall
What Is Agile? • Agile is a framework that is used to structure, plan, and control iterative and incremental development. When applied to management, agile means that projects and processes are managed dynamically and flexibly. Lower planning and management intensity enable fast implementation of a project, high adaptability, and considerable autonomy. • Agile Scrum is one of the many “flavours” of Agile, but it is the most popular 8
The Agile Manifesto Statement of Values Process and tools Individuals and interactions over Following a plan Responding to change over Source: www.agilemanifesto.org Comprehensive documentation Working software (product) over Contract negotiation Customer collaboration over
FAST - Sprints (time-boxes) make it easier to adapt to changing market conditions. PRIORITIZED - Each user story and task has a clear and distinct success metric. FOCUSED - Transparency and a “points” system make prioritization a rational and productive conversation PREDICTABLE - Daily “stand-up” plus the points system help to identify blockers & eliminate surprises effectively. The Agile Way
Agile Principles 1. Satisfy the Customer 2. Welcome Change 3. Deliver Frequently 4. Work as a Team 5. Motivate People 6. Communicate Face-to-Face 7. Measure Working Software 8. Maintain Constant Pace 9. Excel at Quality 10. Keep it Simple 11. Evolve Designs 12. Reflect Regularly 11
Exercise 1A: Review the Scrum Terms and Concepts Cheat Sheet • As an individual, review the Scrum Cheat Sheet 1. Identify key terms and concepts • As a class 2. Discuss which terms sound familiar, which may be new, and which may have caused confusion in your work environment • As individuals or groups 3. Refer to the Cheat Sheet when new terms and concepts are introduced, or when working on exercises
High Level Agile Scrum Framework •Product Owner •ScrumMaster •Team Roles •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Burndown charts Artifacts
Scrum Roles – High Level • Scrum Master • Coach/Lead the Scrum team • Ensure team effectiveness • Product Owner • Prioritize the Product backlog • Ensure project success • Scrum Team • Small (5-9), self-directed team • Cross-functional (BA, Dev, QA, DBA, UI, etc.) • Multiple Scrum Teams (Scrum of Scrums)
Agile Product Life Cycle (SCRUM) NOTE : We will discuss in detail later in the course
AGILE METHODOLOGY Scrum Process Daily stand-up Meeting Review End product Retrospective Daily Scrum Product Backlog Refinement Developmen t & Tests Sprint end date, goal and team deliverables do not change every 24 H Sprint 1-4 Weeks Scrum Master Sprint Review & Retrospective Sprint Planning PRODUCT OWNER the Team Product Backlog Sprint Backlog Features Tasks Sprint Planning meeting Team agrees on how much to complete by sprint's end Burndown / Up Charts Information from end-users, customers, team and stakeholders
•Agile Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. •It allows us to rapidly and repeatedly inspect actual working services and/or software (every two weeks to one month). •The business sets priorities. Teams self- organize to determine the best way to deliver the highest priority features. Agile Scrum in Less Than 100 Words 17
Waterfall vs. Agile Change (Learning) Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements 18
Exercise 1B: Challenges to Building End-to-End Systems Brainwrite the following answers: 1) How would you see Agile helping teams build end-to-end systems? 2) What are some of the challenges you think you will face? Brainwriting – Write 3 ideas in 5 minutes and then discuss as a group 19
Introducing Agile Scrum to the Organization • It is about moving ideas between minds (attitude, trust, distance, tacit knowledge, work environments) • It is about identifying the Shifting of Power, new roles (decision makings, role definitions, power centers) • It is about knowing the Implications of distance, face-to-face, tacit versus documented, culture • Increasing team cohesion, visibility displays, collaborative requirements/planning applications 20
Section Summary and Conclusions The learning objectives for this section were: – Fundamentals of Agile Scrum ✓ Simulation exercise ✓ Manifesto (Statement of Values) ✓ 12 Principles – Review the Agile Product Life Cycle – Describe the Agile roles and responsibilities – Contrast Scrum with Waterfall 21
Section 2 Value Driven Delivery – Identify Case Study and Agile Team 22
Section Learning Objectives • The learning objectives for this section are: – Understand why agile development focuses so heavily on value and adaptive planning – Review the Agile application lifecycle, Agile project characteristics, and Agile roles – Select a Case Study and assemble the Agile Team 23
Value-Driven Development • Agile is based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross- functional teams. • Unlike traditional 6-12 month planning and execution cycles, Agile allows the team to adapt to fast-changing conditions, respond to immediate needs, and prove ROI quickly and consistently. 24
Agile Scrum Characteristics • Self-organizing teams • Product progresses in a series of 2 to 4 week long “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed • Uses generative rules to create an agile environment for delivering projects 25
Exercise 2a: Select the Case Study Select an initiative for your Agile case study • In groups that will become an Agile team 1. Identify projects from your work that meet these criteria: • Not too far along, or not started (< 20% complete) • Not too small or too big (6-18 months) -- A single phase of a larger product can work • Sufficiently complex to be interesting • A team member knows (or can improvise) enough to play the role of Product Owner 2. Select the best candidate for an Agile project • In teams with the Instructor 3. Discuss alternatives, focusing on merits for subsequent exercises 26
Assemble the Agile Team •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Burndown charts Artifacts •Product Owner •ScrumMaster •Team Roles 27
AGILE METHODOLOGY Scrum Role Allocation The Product Owner is responsible for economic success, and represents the interests of users and stakeholders PRODUCT OWNER The Scrum Master acts as the moderator of the project team, and ensures compliance with the rules SCRUM MASTER They are self-organized and responsible for development tasks TEAM MEMBERS Stakeholders communicate their general product needs and requirements STAKEHOLDER S The customer pays for product development in order to use the product later CUSTOMERS SCRUM ROLES
SCRUM – TEAM Supporting Activities ▪ Finding techniques for effective Product Backlog management ▪ Helping the Scrum team understand the need for clear and concise Product Backlog items ▪ Facilitates Scrum implementation ▪ Coaching in self-organization and teamwork and removing impediments from the development team ▪ Helps the development team to create high-value products ▪ Facilitates Scrum implementation ▪ Leading and coaching the organization in its Scrum adaption, planning Scrum implementation within the organization ▪ Helping employees and stakeholders understand and enact Scrum and empirical product development PRODUCT OWNER DEVELOPMENT TEAM SCRUM MASTER ORGANIZATION Source: ©Scrum.Org and ScrumInc., Ken Schwaber and Jeff Sutherland: Scrum Guide
Product Owner • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) and Return on Value (ROV) • Prioritize features according to market value • Adjust features and priorities between (not during) every iteration, as needed • Accept or reject work results 30
Identify the Product Owner Product decision-maker • Authority to make decisions • Responsibility for product success • “Single Wring-able Neck” • One Individual • May represent others • Speaks for all product users • Knows business processes • Understands difficulties and unique needs 31
Exercise 2b: Select the Product Owner • In small groups 1. Discuss the Case Study stakeholders 2. List the people or groups the Product Owner must represent 3. Identify who the ‘real-life’ Product Owner should be, and why (and who will assume the Product Owner’s persona for the Case Study) • As a class 4. Each group presents its Product Owner and decision criteria 32
Build the Scrum Team Establish the team early so they can: • Participate in project initiation • Help with the Product Backlog • Produce initial (coarse-grain) estimates • Jell as a team before the work begins 33
The Scrum Master • Represents management of the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences 34
Team Collaboration • Ideal team members • Identify with the team's goals • Empowered and entrusted with tasks • Supported by manager • Experienced and knowledgeable in field • Represent colleagues • Time to participate • Want to contribute to the success • Avoid representation through proxy 35
Exercise 2c: Build the Scrum Team • In small groups 1. Discuss competencies needed 2. Identify who the ‘real-life’ Scrum Master should be, and why (and who will assume the Scrum Master’s persona for the Case Study) 3. Identify all of the Committed Team roles (full- time and part-time) and who will play them, and who else is on the Non-Committed Team • As a class 4. Each group presents its Team composition 36
Section Summary and Conclusions The learning objectives for this section were: – Value and adaptive planning – Agile application lifecycle, Agile project characteristics, and Agile roles – Selecting a Case Study, assembling the Team ✓ Product Owner ✓ Scrum Master ✓ Committed Team ✓ Non-Committed Team 37
Section 3 Team Member Engagement Envision the Product 38
Section Learning Objectives • The learning objectives for this section are: – Understand the motivation behind team member expectations – Develop high-level functionality to support goals and strategies – Develop an overview for realizing the Vision with Agile ceremonies 39
Exercise 3a: Review Agile Checklist • In small groups 1. Review the Agile Checklist document • Agile Development Rhythms • Meeting Checklists – Strategy Meeting • Getting Started 2. Discuss and capture the key elements that are in the checklist 40
SCRUM – Preparation Sp r i n t C y c l e S p r i n t 1, 2, 3 … N ▪ Business case & funding ▪ Contractual agreement ▪ Vision ▪ Initial Product Backlog ▪ Initial Release plan ▪ Stakeholder buy-in ▪ Assemble team PREPARATION RELEASE N SCRUM PROCESS PRODUCT BACKLOG PRODUCT BACKLOG BURNDOWN SPRINT BACKLOG SCRUM MASTER TEAM MEMBERS STAKEHOLDER USERS PRODUCT OWNER SPRINT BACKLOG BURNDOWN IMPEDIMENT LIST PRODUCT BACKLOG DELTA REPORT SPRINT PLANNING MEETING UPDATE PRODUCT BACKLOG PRODUCT INCREMENT SPRINT REVIEW SPRINT RETROSPECTIVE DAILY SCRUM / DAILY WORK
Team Member Needs • Identify and engage effective and empowered business team members who are engaged with the team • Identify and engage all stakeholders (current and future) by promoting knowledge sharing early and throughout the project to ensure the unimpeded flow of value throughout the lifespan of the project Source: PMI ACP certification summary 42
Product Envisioning – an Agile Best Practice • A common agile practice is to perform some high-level requirements envisioning early in the project to help come to a common understanding as to the scope of what you're trying to accomplish. • The goals at this point are to identify the business goals for the effort, develop a common vision, and swiftly identify the initial requirements for the system at a high-level. 43
Product Vision and Scope Project Scope in Agile environment is dynamic • Start with high-level business and technical needs • Envision ‘Epics’ to be broken down into features, stories, development activities • May need more envisioning to refine product and service groupings, business process capabilities, and value streams 44
Articulate Business Functionality High-level features; not all of the detail • Either User Stories • As a {business role}, • I need {specific functionality}, • So that {business purpose}. • Or high-level Use Case outline • User goal and ‘happy path’ outcome • Measures of success: “Given, when, then …” 45
Articulate Technical Functionality High-level; not all of the detail • Either technical capabilities • Infrastructure • Operational expectations • Architecture framework • Or high-level User Story • As a {system component}, • I need {specific functionality}, • So that {business purpose} 46
Articulate Technical Functionality High-level; not all of the detail •Either technical capabilities • Infrastructure • Operational expectations • Architecture framework •Or high-level User Story • As a {system component}, • I need {specific functionality}, • So that {business purpose} 47
Agile Realization Business motivation – a set of product, service or architectural needs (Product Vision) – realized in: • Product Backlog consists of high-level stories (Project Vision, Epics and Features) • Minimum marketable feature set (Release Plan) • New initiative (Sprint Zero, Spikes) • Rate of development (Velocity, Burn Down) • Sprint Backlog (Stories, Tasks, Test Criteria) • Complex projects (Sprint Stabilization) • Multiple initiatives (Scrum of Scrums) 48
Section Summary and Conclusions The learning objectives for this section were: – Understand the motivation behind stakeholder expectations ✓ Stakeholder engagement ✓ Strategy meeting ✓ Elevator pitch – Develop an overview for realizing the Vision with Agile ceremonies ✓ Agile checklist 49
Section 4 Initiate an Agile Project– Planning Releases 50
Section Learning Objectives • The learning objectives for this section are: – Discuss how you would initiate an Agile project – Discuss common practices that work when planning Agile projects – Determine how you will organize features and releases 51
Exercise 4a: Adapting to a Change-Driven Project Plan • Group discussion 1. How do you adapt to a change-driven approach from a (traditional) plan-driven approach? Questions to ask: - Do you have all the facts that will provide clarity for planning the ENTIRE project? - Are there any known unknowns? - Do you have multiple options to choose from during the project? 52
Planning in the Agile Product Development Life Cycle 53 “Five Levels of Agile Planning”
Initial Release Plan The initial release plan is understood to be rough. It must be detailed enough only to get us started by predicting that the project will deliver enough return on investment to more than pay for it. REMEMBER In Agile projects we plan continuously, and we correct our course as we go. 54
Product-Level Planning Customer-specific product release success criteria share the following characteristics: • Identify specify current or prospective customer ‘personas’ so the team knows who they are trying to satisfy • Define specific actions by the customer that will indicate the product release has met its goal • Set timeframes during which actions must take place for the product release to be considered a success 55
Prioritize Releases Since initial Product Backlog items can be difficult to prioritize, it’s useful to prioritize Releases first, then items within and, if necessary, across themes Factors to consider when determining priorities: • Value • Knowledge • Uncertainty and risk • “Releasability” • Dependencies 56
Group Initial Product Backlog Items 57
Exercise 4b: Create Release Plan Using the case study and Release Planning checklist discuss an initial Release Plan • In teams 1. Expand business and technical functionality (more features and capabilities) to produce an initial Product Backlog 2. Team and Product Owner consider multiple factors to organize features in a Release Plan • As a class 3. Discuss release schedule and constraints 58
Section Summary and Conclusions The learning objectives for this section were: – Discuss how you would initiate an Agile project ✓ Five Levels of Agile Planning – Discuss common practices that work when planning Agile projects ✓ Release Plan Meeting 59
Section 5 Coarse-Grain Estimates and Time-Boxed Iterations 60
Section Learning Objectives • The learning objectives for this section are: – Determine high-level items in Product Backlog – Estimate at the level of detail sufficient for planning and prioritizing – Estimate throughput (delivered items) within time and resource constraints 61
Embrace High-Level Vision and Release Plan Product Life Cycle budget requires estimating how many Sprints will it take to achieve the desired outcome. Individual Sprint components may include: • Modeling • Implementation and testing • Deployment, configuration management, training and documentation • Synchronization, refactoring and data hygiene • Environment changes 62
Develop the Product Backlog • A list of all desired work on the project • Each item has value to the users or customers of the product • Prioritized by product owner (and the team) • Become ‘requirements’ • Allows team to estimate items when needed, at the level of detail needed This is the Product Backlog 63
Guidelines for the Product Backlog Guidelines for creating the Product Backlog are: • Keep your Product Backlog between 50 and 100 items total • The top 20 to 40 items are small enough to be estimated at a high level • Put acceptance criteria on top 20-40 items 64
Establish Decision and Acceptance Criteria for User Stories Writing user stories is simple if you follow these simple steps: 1. As a [role], I can [feature] so that [reason] 2. Use index cards and a Sharpie 3. Make it testable with acceptance stories • Given [context], when [event], then [outcome] 4. Connect the dots [start the conversation] 65
Exercise 5a: Elaborate Business Functionality • In small groups 1. Agree on documenting with User Stories 2. Decompose high-priority business functionality into at least 10 user stories (one per 3x5 sticky note) with success criteria 3. Note technical functionality associated with user stories as additional success criteria • As a class 4. Each group presents stories they have added to their Product Backlog 66
Estimate Complexity Using Story Points • Relative measure of effort to implement User Stories • Abstract number for ‘how hard’ the story is • ‘Hard’ could be related to technical functions, complexity, unknowns and deployment tasks • Defined by team and constant over all Sprints • Examples (shirt size, scale 1-10, or fibonacci): • “Send to a Friend” = 2 • “Shopping Cart” = 8 67
Coarse-Grain Estimates • Team estimates relative complexity • For each Business User Story (or Use Case) • “Coarse-grain” estimate based on high-level functionality and technical factors • Unit of measure: “Story Points” 1 point = routine story, low effort, little or no complexity, with an average team doing concentrated, un-interrupted work • Scrum Master facilitates estimation 68
Exercise 5b: Estimate Complexity (Coarse-Grain) • In small groups 1. Estimate each story • ScrumMaster facilitates the game • Team does the estimating • Product Owner does not estimate! • Estimate Story Points 2. Write the effort estimates on the story cards • As a class 3. Each group presents their Estimates 69
Agile (Scrum) Is Time-Boxed • Invert the Iron Triangle • Fix date and resources • Vary scope • Reduce waste • Estimate throughput • Optimize value (each Sprint; entire Project) • Prioritize needs • Deliver maximum value in time allowed 70
Project Time-Box Considerations • Required end-date • Project budget • Resource availability • Others? The project will deliver the greatest possible business value (as defined by the Product Owner) within the project time-box 71
Establish Core Hours • How will the team work during the day? • How many hours can you get from your committed resources during the sprint? • What impact does this have the team’s capacity? 72
Team Velocity • Over a number of sprints you will see how many story points you can achieve – the velocity • This allows you to predict throughput based on number of story points in the backlog REMEMBER – one team’s story point is not the same as another's 73
Project Time-Box •Time-boxing represents the project timeline, given Product Backlog and Team Velocity • Begin date • End date • Sprint length • Number of Sprints Jan Feb Mar Apr May Jun Jul Sprint #1 Sprint #2 Sprint #3 Sprint #4 Sprint #5 Sprint #6 Sprint #7 74
Section Summary and Conclusions The learning objectives for this section were: – Determine high-level items in Product Backlog ✓ User stories and acceptance criteria – Estimate at the level of detail sufficient for planning and prioritizing – Estimate throughput (delivered items) within time and resource constraints ✓ Velocity ✓ Time-box 75
Section 6 Plan the Iteration (Part I) 76
Section Learning Objectives • The learning objectives for this section are: – How to plan an Agile iteration (Sprint) – Review Day 1 planning activities, roles and expectations – Address common challenges of Agile planning 77
Sprint Planning • Scrum projects make progress in a series of “Sprints” • Typical duration is less than a calendar month • Time-boxing leads to better rhythm, efficiency • Potentially shippable product is specified, designed, coded, tested and accepted • Sprint Planning selects Sprint Backlog items and develops understanding of Tasks 78
Iteration Planning in Context of Agile Unified Process 79 • ‘Inception’, ‘transition’ and ‘production’ phases apply to the flow within a Sprint, and to the overall plan across multiple Sprints
Exercise 6a: Sprint ‘Zero’ Activities • In small groups, discuss 1. What is Sprint Zero? 2. What activities could be included in Sprint Zero? For a simple project? For a complex project? • As a class 3. Do you expect the first sprints to be clean and well executed? Why or why not? How do you address this? 80
Spikes • Stories to • Research technical and functional issues • Secure budget and reach financial decisions • Prototype capabilities that require feedback • Help understand complexity • Often ‘thrown away’ • Output is a better estimate for original story If we knew what we were doing it wouldn’t be research - Albert Einstein 81
Master Test Plan An Agile master test plan includes: • Intro with objectives and team members • Scope (what will be tested) • Assumptions and risks • Test approach (including automation) • Test environment • Milestones/deliverables with the schedule 82
Backlog Accuracy Continuous planning is much more accurate if it occurs on at least two levels: • At the release level, identify and prioritize the features the PO must have, would like to have, and can do without by the deadline • At the iteration level, pick and plan for the next batch of features to implement, in priority order Features too large to be estimated or delivered within a single iteration must be broken down or researched further 83
1st Half of Sprint Planning Meeting • First part of the meeting - collaborative effort • Product Owner, Team, Scrum Master • Anyone who wants to attend is welcome • Set Sprint goal and scope • Based on progress to date and any changes • Learn more detail about highest priority items • Accept Product Backlog items into Sprint • Time-boxed marching plans for the Team 84
Sprint Goal and Scope • Small reversible steps • Welcome change • Cross-functional team • Include design and testing • Maintain constant pace • Share commitment • ‘DONE’ • Get feedback quickly This Sprint 85
Identify PBIs for the Sprint ScrumMaster facilitates while Product Owner and Team collaborate to: • Break down larger stories • Prioritize stories • Decide which PBIs may be put into production • Team collaborates to: • Review velocity and capacity • Select stories for current iteration 86
Story Size and Sprint Capacity If XYZ story can be accepted in one Sprint: • Add support for XYZ • Consider adding another story If XYZ story cannot be accepted in one Sprint: • Consider what elements can be worked • Create User Interface/Workflow for XYZ • Process normal XYZ success (no exceptions) • Apply all business rules to XYZ 87
Exercise 6B: Confirm and Refine High-Priority Product Backlog Items • Using the Iteration Planning checklist 1. Using the Backlog PBI Create 1. An EPIC 2. Five Features 3. Three Stories for the first feature 4. Estimate complexity of the User Stories (T- Shirt sizes, or 1.3.5) • As a class 3. Discuss the advantages and disadvantages of this approach 88
Section Summary and Conclusions The learning objectives for this section were: – How to plan an Agile iteration (Sprint) – Review Day 1 planning activities, roles and expectations ✓ Iteration Plan Meeting ✓ Estimating with T-Shirt Size or 1,3,5 – Address common challenges of Agile planning ✓ Sprint ‘0’, Spike, Master Test Plan 89
Section 7 Plan the Iteration (Part II) 90
Section Learning Objectives • The learning objectives for this section are: – How to complete planning for a Sprint – How to estimate at the task level and identify risk factors – Understand who commits to and approves the Sprint plan 91 AIM
2nd Half of Sprint Planning Meeting Second half of meeting - collaborative effort within Team: • Clarify Sprint Backlog items • Break down stories to associated tasks • Identify modeling requirements • Create initial list of issues, dependencies, assumptions, non- functional requirements • Estimate tasks (Ideal Days or Hours) • Definition of DONE • Tasks become committed for the Sprint 92
Estimate Relative Effort (Fine Grain) •Team estimates relative effort • For each task • ‘Fine-grain’ estimate based on team’s experience and different perspectives •Scrum Master facilitates estimation •Option: • Self-select tasks first, then team member estimates own tasks 93
Sprint Backlog Example Includes rough estimates Prioritized by value & risk Publicly visible Better to describe as user stories 94
Finalize the Sprint Plan Scrum Master Facilitates: • Product Owner and Team collaborate to finalize what will be delivered in the Sprint, based on: • Sprint Goal • Initial plan for this Sprint • Team’s velocity • Other information 95
Section Summary and Conclusions The learning objectives for this section were: – How to complete planning for a Sprint – How to estimate at the task level and identify risk factors ✓ Ideal Days – Understand who commits to, and approves, the Sprint plan 96
Section 8 Tools and Techniques for Managing Scrums 97
Section Learning Objectives • The learning objectives for this section are: – Review the four main tools and techniques that guide progress – Discuss how to use these techniques in an Agile environment 98
Manage the Scrum To maintain rhythm and sustainable pace of work, manage Scrum activities through • Self-selecting tasks near to priority order • Displaying work in progress • Communicating status and spotting obstacles daily • Reporting progress that is visible, highly transparent, and easily understood 99
Daily Scrum Meeting • Only 15 minutes a day • Stand up meeting • Only “committed” members can talk • 3 questions are asked • Commitment and accountability • Say what you do, do what you say • Whole world is invited This is the Daily Scrum Meeting 100
Example #2 SCRUM Task Board 101
Burndown Chart • On a Scrum project, the team tracks its progress against a sprint or release plan by updating a burndown chart • The horizontal axis of the chart shows the time, and the vertical axis shows the amount of work remaining • Work remaining can be shown in whatever unit the team prefers – story points, ideal days, team days, and so on 102
SCRUM – BURNDOWN CHART
Exercise 8a – Discussion –Create a Scrum board with work streams • As a team, discuss how you would create a Scrum board with work streams 104
Section Summary and Conclusions The learning objectives for this section were: – Review the four main tools and techniques that guide progress ✓ Self-managing teams ✓ Daily Standup meeting ✓ Task Board ✓ Burndown Chart – Discuss how to use these techniques in an Agile environment 105
Section 9 Running the Sprint 106
Section Learning Objectives • The learning objectives for this section are: – Understand how requirements emerge, change and are satisfied during the Sprint – Discuss the importance of self-managed teams – Demonstrate how the Daily Standup Meeting fosters collaboration and communicates status to committed and non-committed resources 107 AIM
Paradigm Shift in Requirements • Plan-driven limitations • Documents do not generate value directly • Unidirectional from author perspective • Agile ‘User Story’ represents a conversation • Visual display, easily annotated • Whiteboard modeling for clarity and insight • ‘Given, when, then’ conditions • Automated tests confirm details • Artifacts (cards) are only temporary 108
Select ‘Next Priority’ Task • Each team member selects (one) task-level item • Next highest in priority ranking • Dependency item, cover item or other association with related requirements • Skill level and capacity • Unresolved issues • Level of collaboration • Re-estimate in hours or ideal days • Post on Task Board 109
Validate Agile Requirements • Identify assumptions • Define measurable evaluation criteria • Determine business value • Determine dependencies for benefits realization • Evaluate alignment with business case and opportunity cost 110
Create Test Scenarios and Test Cases from User Stories • User story detail (exhaustive, comprehensive) • Measures of success • Non-functional quality of service criteria • Integration and synchronization • Automated testing Note – Demonstrate completed work items at the Sprint Review meeting (Sprint Demo) 111
Managing Scrums with Daily Stand-Up Committed Team with cross-functional skills does the actual work 3 Questions are asked: • What have you completed since we last met? • What are you planning to complete until we meet again? • What, if any, impediments are you encountering that are preventing you from completing your work? 112
Daily Scrum Rules •Purpose • Status update to synchronize Team’s work • Highlight ‘WIP’ ‘done’ or new impediments • Foster collaboration and self-organization •Logistics • Every business day, usually early in the morning • Short (time-boxed) and stand-up (no chairs) • Report status and take discussion off-line • NO presentations, problem-solving or decision-making! 113
Review: Committed vs. Non-Committed • Committed resources have skin in the game • Everyone doing technical work on the project • Competencies (development, testing, DBA …) • So they may speak and show accountability • Non-Committed resources only contribute • Everyone else • Executive, Sponsor, Manager, Customer … • So they must remain silent, but remain engaged by listening and observing progress 114
Removing Impediments to Progress Scrum Master ensures: • Interested Team members collaborate after the meeting to solve Technical problems • SM action items to clear the Team’s path and secure other groups’ cooperation to remove Organizational roadblocks • SM action items to shield team from Political infighting • SM action items to defend process integrity against attempts to circumvent Scrum practices 115
Authority to Change Sprint Backlog Only the Team can change the Sprint Backlog in the middle of a Sprint • Add items if necessary to achieve the Sprint goal or if resources are available for more work • Remove/modify items if the Sprint goal is still achieved AND if the Product Owner agrees • Priority was ‘low’ during planning • Scope has changed • Assess changes in Sprint Review and add back to the Product Backlog for next Sprint 116
Section Summary and Conclusions The learning objectives for this section were: – Understand how requirements emerge, change and are satisfied during the Sprint ✓ Facilitated workshops, preshops – Discuss the importance of self-managed teams – Demonstrate how the Daily Standup Meeting fosters collaboration and communicates status to committed and non-committed resources ✓ Roles and authority to change 117
Section 10 Sprint Review 118
Section Learning Objectives • The learning objectives for this section are: – Understand why and how to conduct a Sprint Review 119
Traditional Acceptance and Sign-off • Customer acceptance is important for requirements approval • Team acceptance is important because they agree to accept the requirements and build them into a product • Sign-off on a requirements document is an act of customer approval of the requirements and brings closure before the requirements development process 120
Exercise 10a: Discuss Review Planning Checklist • In small groups 1. Review the Iteration Review meeting checklist 2. Discuss and capture the key elements that are in the checklist • As a class 3. What makes Agile (Scrum) Sprint Review different from a traditional project approach? 121
Sprint Review: Working Product Is Showing Progress Sprint Review focuses on the finished product increment • Did the team produce what they promised? • Does it meet the Product Owner’s expectations? • Is it acceptable to the customers? • Was the Sprint goal achieved? 122
Prepare for Sprint Review • Team presents what it accomplished • Typically takes the form of a brief demo of new features or underlying architecture • JAD workshops, prototypes, testing occur within the Sprint as a completed Task • Informal • 2-hour prep time, no slides • Whole team participates (invite the world) • Product Owner accepts deliverables, adjusts Product Backlog 123
Organizational Readiness What is it? • Organizational readiness reflects ability to accept and implement change • Requires necessary knowledge, skills, resources to assess and support • Critical to successfully implementing complex service delivery changes • Time to plan is early, while time to affirm is now • Accountability may rest with the Product Owner 124
Definition of Done (DoD) Definition of Done (DoD) • The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. 125
Input for the Next Sprint • Update the user stories and their priorities as customers' needs change • Break down user stories that are likely to be implemented in the next sprint 126
Exercise 10b: Conduct a Sprint Review • In small groups using the Review meeting checklist 1. Prepare for a Sprint Review • Assume goal is complete but certain tasks were changed • Consider this Sprint in context of Release Plan 2. Conduct the Sprint Review • As a class 3. Contrast Review meeting with traditional UAT 127
Section Summary and Conclusions The learning objectives for this section were: – Understand why and how to conduct a Sprint Review ✓ Sprint Review meeting ✓ Validation ✓ Organizational Readiness ✓ Definition of Done (DoD) 128
Section 11 Sprint Retrospective 129
Sprint Retrospective Quick Lessons Learned at end of every Sprint • What is working well for the team? • What is problematic for the team? • What practice changes shall we try? • Not more than 2 or 3 • Low-hanging fruit • Determine at the next Retrospective if the changes will be made permanent 130
Key Process Indicators • Agile processes should be tailored to better serve the organization and project • Success metrics (quality indicators) for Agile • Planning (velocity as a reliable tool) • Collaboration (quality of relationships) • Requirements (validity after testing) • Deliverables (working software) • Deployment (service management) • Assessment mechanism: open discussion 131
Sprint Retrospective Guidelines • Done after every Sprint • Typically 15–30 minutes • ScrumMaster facilitates open discussion among committed team • Review improvements from previous Sprint • Add any impediments not cited in Daily Scrum • Include non-committed team for part of the discussion as appropriate • Identify most important issues to work on for next Sprint, focusing on process not people 132
Exercise 11b: Pop Quiz! • Is it OK for a project to have more than 1 Product Owner? Why? • What is the Product Owner’s primary responsibility? ScrumMaster? Team Member? • Define these terms: • Time-boxed • Self-organizing team • Planning poker • Definition of Done 133
Section Summary and Conclusions The learning objectives for this section were: – Understand why and how to conduct a Sprint Retrospective ✓ Retrospective meeting ✓ Metrics 134
Section 12 Boosting Team Performance 135
Section Learning Objectives • The learning objectives for this section are: – Raise concerns with introducing Agile methods in a Waterfall culture – Discuss scaling larger projects and portfolios – Introduce performance issues facing Agile teams 136 AIM
Scaling with Larger Teams Can committed resources represent small groups of technical peers? • Factors in scaling • Type of application • Team size • Team dispersion • Project duration http://whitewaterprojects.com/20 10/09/17/why-is-7-2-the-ideal- scrum-team-size/# 137
The Dangers of Agile Scrum • It’s hard! • It requires significant change • It makes all dysfunction visible • It demands honesty, transparency and accountability • Bad products will be delivered sooner, and doomed projects will fail faster • Partial adoption may be worse than none at all • Be forewarned: many Scrum adoptions fail 138
Begin with Stakeholder Engagement Keys to improving stakeholder engagement: • Team Formation • Team Empowerment • Team Collaboration • Team Commitment Then, as an on-going activity: • Coach • Solve Problems 139
Exercise 12a: Discussion on issues with people and process Based on the organization’s current competencies and future needs, how can it best manage the transition to Agile? 1. What are the process issues 2. What are the people issues 3. How can we remove the impediments to progress? 140
Section Summary and Conclusions The learning objectives for this section were: – Raise concerns with introducing Agile methods in a Waterfall culture – Discuss scaling larger projects and portfolios – Introduce performance issues facing Agile teams 141
Section 13 Transitioning from Waterfall 142
Waterfall Cultural Roots •Origins in structured programming with quality process control •Project management • Known requirements • Variance from plan • Management culture, project leadership, project focus •Business analysis • Plan-driven requirements management 143 Requirements Planning Design Build Test Deploy
Waterfall vs. Agile Change (Learning) Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements 144
Exercise 13a: Comparing Waterfall (Plan-Driven) versus Agile (Change-Driven As a class determine the advantages and disadvantages of the Waterfall and Agile Framework 145
Module 14 Wrap Up and Additional Information 146
Course Learning Objectives Summary The learning objectives for this course were: This course shall help you develop and enhance your Agile skills so that they can provide significant value to projects and the business enterprise 147
Agile Product Life Cycle (SCRUM) NOTE : ✓ Discussed in detail! 148
Agile Reading List • Agile and Iterative Development: A Manager’s Guide by Craig Larman • Agile Estimating and Planning by Mike Cohn • Agile Project Management with Scrum by Ken Schwaber • Agile Retrospectives by Esther Derby and Diana Larsen • Agile Software Development Ecosystems by Jim Highsmith • Agile Software Development with Scrum by Ken Schwaber and Mike Beedle • Scrum and The Enterprise by Ken Schwaber • User Stories Applied for Agile Software Development by Mike Cohn • Lots of weekly articles at www.scrumalliance.org 149
150 Questions?

More Related Content

PDF
Introduction to Agile and Scrum
byManoj Gupta, CSM®,
 
PPT
Scrum-Agile : An Introduction
byGlobal SQA
 
PDF
Scrum-Master-itlearn-software -engineering
byDorisRois
 
PDF
Fundamentals of Agile Methodologies - Part I
byGopinath Ramakrishnan, Ph.D, CSM
 
PPTX
Agile Methodology
byAciron Consulting
 
PPT
Introduction to Agile & Scrum
byConscires Agile Practices
 
PPT
Let’s Play Agile ! 12-09-15-testers_hub
byOwner Tester's Hub
 
PDF
Fundamentals of Agile
bysparkagility
 
Introduction to Agile and Scrum
byManoj Gupta, CSM®,
 
Scrum-Agile : An Introduction
byGlobal SQA
 
Scrum-Master-itlearn-software -engineering
byDorisRois
 
Fundamentals of Agile Methodologies - Part I
byGopinath Ramakrishnan, Ph.D, CSM
 
Agile Methodology
byAciron Consulting
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
Let’s Play Agile ! 12-09-15-testers_hub
byOwner Tester's Hub
 
Fundamentals of Agile
bysparkagility
 

Similar to SPROTT - STUDENT WORKBOOK - INTRO TO AGILE.pdf

PDF
Agile scrum brown bag
byBernadette Charlescar PMP, CSM
 
PPTX
Agile for Business
byDigitalCatapultDevelopmentPractices
 
PDF
Intro to scrum webinar
byConscires Agile Practices
 
PPT
Introduction to agile scrum
byConscires Agile Practices
 
PDF
scrum-talk
byNopparat Slisatkorn
 
PDF
Introduction to Agile & Scrum
byConscires Agile Practices
 
PPT
Introduction to Agile & Scrum
byConscires Agile Practices
 
PPTX
Agile 101 for Resource Planners
byJerry Manas
 
PDF
Agile project management using scrum
byPrudentialSolutions
 
PPT
Introduction to agile scrum july 18th
byConscires Agile Practices
 
PDF
Intro to scrum bachan anand
byConscires Agile Practices
 
PPT
Intro to agile business analysis
bySumit Mahajan
 
PPT
Introduction to Agile & Scrum
byConscires Agile Practices
 
PPTX
agilescrumbasics-1909060648272727279.pptx
byChetanLunthi
 
PDF
Introduction to Scrum
byConscires Agile Practices
 
PPT
Introduction to Agile & Scrum
byConscires Agile Practices
 
PDF
Agile & SCRUM basics
byArun R
 
PPTX
What are the Tools & Techniques in Agile Project Management?
byTuan Yang
 
PPT
Introduction to Agile & Scrum
byConscires Agile Practices
 
PDF
Introduction to scrum by bachan anand
byConscires Agile Practices
 
Agile scrum brown bag
byBernadette Charlescar PMP, CSM
 
Agile for Business
byDigitalCatapultDevelopmentPractices
 
Intro to scrum webinar
byConscires Agile Practices
 
Introduction to agile scrum
byConscires Agile Practices
 
scrum-talk
byNopparat Slisatkorn
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
Agile 101 for Resource Planners
byJerry Manas
 
Agile project management using scrum
byPrudentialSolutions
 
Introduction to agile scrum july 18th
byConscires Agile Practices
 
Intro to scrum bachan anand
byConscires Agile Practices
 
Intro to agile business analysis
bySumit Mahajan
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
agilescrumbasics-1909060648272727279.pptx
byChetanLunthi
 
Introduction to Scrum
byConscires Agile Practices
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
Agile & SCRUM basics
byArun R
 
What are the Tools & Techniques in Agile Project Management?
byTuan Yang
 
Introduction to Agile & Scrum
byConscires Agile Practices
 
Introduction to scrum by bachan anand
byConscires Agile Practices
 

More from Wilber Tuttleman

PPT
Mike Cohn - Agile Estimation and Planning.ppt
byWilber Tuttleman
 
PPTX
Module 2 - Participation Assignment 2 (Quiz 2).pptx
byWilber Tuttleman
 
PPTX
Class 1 VALUE of PM education introduction
byWilber Tuttleman
 
PPTX
Class 1 - PM Basics and learning about projects
byWilber Tuttleman
 
DOCX
3. Quiz - estimating in projects and techniques
byWilber Tuttleman
 
DOCX
Quiz - Leadership Quiz in college including management
byWilber Tuttleman
 
PPTX
Project costing in healthcare can analysis the project
byWilber Tuttleman
 
PPT
7-Summary for the PMI SP exam study preperation
byWilber Tuttleman
 
DOC
3. Creation Quiz for studying PMI SP exam
byWilber Tuttleman
 
PPT
1-Introduction PMI schedule exam for document
byWilber Tuttleman
 
PDF
PMI-SP sample exam q and a for schedule exam
byWilber Tuttleman
 
DOC
10-Example RAM Template for responsibility .doc
byWilber Tuttleman
 
DOC
Unit 2 - for a project Project_Charter Template.doc
byWilber Tuttleman
 
PPTX
00. Template for planning a business plan
byWilber Tuttleman
 
DOC
1. Business Plan_MBHS document for planning start up
byWilber Tuttleman
 
DOC
Class 1 - used for cost justification Business Case TEMPLATE.doc
byWilber Tuttleman
 
DOCX
Project+Instructions+Documenti_i WORD.docx
byWilber Tuttleman
 
DOC
Simple Business requirement document for projects
byWilber Tuttleman
 
DOCX
Business REquirement document to be used in projects
byWilber Tuttleman
 
DOC
BRD_PSO_Business for project Requirements.doc
byWilber Tuttleman
 
Mike Cohn - Agile Estimation and Planning.ppt
byWilber Tuttleman
 
Module 2 - Participation Assignment 2 (Quiz 2).pptx
byWilber Tuttleman
 
Class 1 VALUE of PM education introduction
byWilber Tuttleman
 
Class 1 - PM Basics and learning about projects
byWilber Tuttleman
 
3. Quiz - estimating in projects and techniques
byWilber Tuttleman
 
Quiz - Leadership Quiz in college including management
byWilber Tuttleman
 
Project costing in healthcare can analysis the project
byWilber Tuttleman
 
7-Summary for the PMI SP exam study preperation
byWilber Tuttleman
 
3. Creation Quiz for studying PMI SP exam
byWilber Tuttleman
 
1-Introduction PMI schedule exam for document
byWilber Tuttleman
 
PMI-SP sample exam q and a for schedule exam
byWilber Tuttleman
 
10-Example RAM Template for responsibility .doc
byWilber Tuttleman
 
Unit 2 - for a project Project_Charter Template.doc
byWilber Tuttleman
 
00. Template for planning a business plan
byWilber Tuttleman
 
1. Business Plan_MBHS document for planning start up
byWilber Tuttleman
 
Class 1 - used for cost justification Business Case TEMPLATE.doc
byWilber Tuttleman
 
Project+Instructions+Documenti_i WORD.docx
byWilber Tuttleman
 
Simple Business requirement document for projects
byWilber Tuttleman
 
Business REquirement document to be used in projects
byWilber Tuttleman
 
BRD_PSO_Business for project Requirements.doc
byWilber Tuttleman
 

Recently uploaded

PPTX
Cyber_Security_Presentation (1).pptx......
bywnwfp1234
 
PPT
Hydrosphere, oceanic structure,ocean depthetc
bykisankumar4241
 
PDF
reStartEvents 12:11 TS:SCI & Above Employer Directory.pdf
byKen Fuller
 
PDF
Drying PPt.mjolkhhjjjjjjjjjjjjjjiiiiiiiijiii
bydanamukhi3
 
PPTX
Weed_Management_With_Images.pptx bsc agriculture 1st year agronomy presentation
bykanhabarik852
 
PDF
ENTREP - Q1 - Lesson 2.pdf...........................
bycastanorienahope
 
PDF
Dr.Pothireddy Syrendranath Reddy Bio.pdf
bySurendranath Reddy Pothireddy
 
PPTX
WEPP MODEL for computing soil erosion .pptx
bysnehilchandrakar
 
PDF
Wildcard cas for McKinsey interview prep
byMaybeSomeplace
 
PDF
Step-by-Step Process for Buying a Verified Apple Pay ....pdf
bybxi4tn48i3wkgpbyyfg
 
PPTX
Evaluation and Benchmarking of LLM Agents: Full Slide Deck (2025).pptx
byroshinijoga
 
PDF
954466621-Spreadsheet-Training-Needs-Assessment-v2-xlsx.pdf
bypradybade
 
PPTX
COMPUTER SYSTEMS AND BINARY NUMBERS ARCH
bywakandapemah
 
PPT
yh4yj46j46j46j746j7467j46j746j746j74j2.ppt
bysumodmjohn3
 
PDF
IGC 1 meetingg no 1+ 2 exam preparation document.pdf
bychatif3
 
PDF
Indira_Gandhi_Matritva_Sahyog_Yojana[1].pdf
byakankshalahase1
 
PDF
Enhanced Research Proposal Help UK for Strong Academic Outcomes
byResearch Proposal Help
 
PPTX
Curriculum Design in Higher Education FIP NITW dated 5th December 2025.pptx
byBiolifesolutions
 
PPTX
ISTHIS A PPT I UPLOADED THAT IS NOT SO MUCH OF USE ANYWAYS
bynelsonochieng
 
PDF
Latitude & Longitude ,timezone and international Time zone
bykisankumar4241
 
Cyber_Security_Presentation (1).pptx......
bywnwfp1234
 
Hydrosphere, oceanic structure,ocean depthetc
bykisankumar4241
 
reStartEvents 12:11 TS:SCI & Above Employer Directory.pdf
byKen Fuller
 
Drying PPt.mjolkhhjjjjjjjjjjjjjjiiiiiiiijiii
bydanamukhi3
 
Weed_Management_With_Images.pptx bsc agriculture 1st year agronomy presentation
bykanhabarik852
 
ENTREP - Q1 - Lesson 2.pdf...........................
bycastanorienahope
 
Dr.Pothireddy Syrendranath Reddy Bio.pdf
bySurendranath Reddy Pothireddy
 
WEPP MODEL for computing soil erosion .pptx
bysnehilchandrakar
 
Wildcard cas for McKinsey interview prep
byMaybeSomeplace
 
Step-by-Step Process for Buying a Verified Apple Pay ....pdf
bybxi4tn48i3wkgpbyyfg
 
Evaluation and Benchmarking of LLM Agents: Full Slide Deck (2025).pptx
byroshinijoga
 
954466621-Spreadsheet-Training-Needs-Assessment-v2-xlsx.pdf
bypradybade
 
COMPUTER SYSTEMS AND BINARY NUMBERS ARCH
bywakandapemah
 
yh4yj46j46j46j746j7467j46j746j746j74j2.ppt
bysumodmjohn3
 
IGC 1 meetingg no 1+ 2 exam preparation document.pdf
bychatif3
 
Indira_Gandhi_Matritva_Sahyog_Yojana[1].pdf
byakankshalahase1
 
Enhanced Research Proposal Help UK for Strong Academic Outcomes
byResearch Proposal Help
 
Curriculum Design in Higher Education FIP NITW dated 5th December 2025.pptx
byBiolifesolutions
 
ISTHIS A PPT I UPLOADED THAT IS NOT SO MUCH OF USE ANYWAYS
bynelsonochieng
 
Latitude & Longitude ,timezone and international Time zone
bykisankumar4241
 

SPROTT - STUDENT WORKBOOK - INTRO TO AGILE.pdf

  • 1.
    Grow your career. Levelup for the future. Intro to Agile and Scrum Patrick van Abbema
  • 2.
    Instructor Bio • Patrickvan Abbema, MBA, PMP, CBAP, CSP, CSM, ITIL • Experienced Management Consultant with over 25 years of extensive experience. • I focus on two project management specialty areas: • Agile project management and • Digital Transformation • I have several progressive accomplishments as a senior management consultant in Information Management (IM), Information Technology (IT), Defensive Cyberspace Operations (DCO), Customer Relationship Management (CRM), Organizational Change Management (OCM), Enterprise Resource Planning (ERP), Enterprise Content Management (ECM) and Bimodal IT solutions. I have managed organizational change management initiatives that involved the development of coaching skills, process analysis, technology implementation, strategy development, and operational improvement services. • Linkedin Profile: https://www.linkedin.com/in/pvanabbema/ 2
  • 3.
    Agenda Day 1 -Section 1-5 Day 2 – Section 6-14 01. 02.
  • 4.
    Exercise - Discussion Thinkingback to past projects, what were your biggest challenges (ex., unrealistic schedules)? Using post-it notes, take 5 minutes to write down 3 project challenges you have faced in the past. NOTE – This is brainstorming technique called brainwriting or method 6-3-5 (6 people - 3 ideas in 5 minutes) 4
  • 5.
    Logistics • Please muteyour phones, and other noise making devices • Feel free to stand up and stretch when you are feeling like you need to wake up or just move about • Interactive – please ask questions
  • 6.
  • 7.
    Section Learning Objectives •The learning objectives for this section are: – Understand the fundamentals of Agile Scrum – Review the Agile Product Life Cycle – Describe the Agile roles and responsibilities – Contrast Scrum with Waterfall
  • 8.
    What Is Agile? •Agile is a framework that is used to structure, plan, and control iterative and incremental development. When applied to management, agile means that projects and processes are managed dynamically and flexibly. Lower planning and management intensity enable fast implementation of a project, high adaptability, and considerable autonomy. • Agile Scrum is one of the many “flavours” of Agile, but it is the most popular 8
  • 9.
    The Agile Manifesto Statementof Values Process and tools Individuals and interactions over Following a plan Responding to change over Source: www.agilemanifesto.org Comprehensive documentation Working software (product) over Contract negotiation Customer collaboration over
  • 10.
    FAST - Sprints(time-boxes) make it easier to adapt to changing market conditions. PRIORITIZED - Each user story and task has a clear and distinct success metric. FOCUSED - Transparency and a “points” system make prioritization a rational and productive conversation PREDICTABLE - Daily “stand-up” plus the points system help to identify blockers & eliminate surprises effectively. The Agile Way
  • 11.
    Agile Principles 1. Satisfythe Customer 2. Welcome Change 3. Deliver Frequently 4. Work as a Team 5. Motivate People 6. Communicate Face-to-Face 7. Measure Working Software 8. Maintain Constant Pace 9. Excel at Quality 10. Keep it Simple 11. Evolve Designs 12. Reflect Regularly 11
  • 12.
    Exercise 1A: Reviewthe Scrum Terms and Concepts Cheat Sheet • As an individual, review the Scrum Cheat Sheet 1. Identify key terms and concepts • As a class 2. Discuss which terms sound familiar, which may be new, and which may have caused confusion in your work environment • As individuals or groups 3. Refer to the Cheat Sheet when new terms and concepts are introduced, or when working on exercises
  • 13.
    High Level AgileScrum Framework •Product Owner •ScrumMaster •Team Roles •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Burndown charts Artifacts
  • 14.
    Scrum Roles –High Level • Scrum Master • Coach/Lead the Scrum team • Ensure team effectiveness • Product Owner • Prioritize the Product backlog • Ensure project success • Scrum Team • Small (5-9), self-directed team • Cross-functional (BA, Dev, QA, DBA, UI, etc.) • Multiple Scrum Teams (Scrum of Scrums)
  • 15.
    Agile Product LifeCycle (SCRUM) NOTE : We will discuss in detail later in the course
  • 16.
    AGILE METHODOLOGY Scrum Process Dailystand-up Meeting Review End product Retrospective Daily Scrum Product Backlog Refinement Developmen t & Tests Sprint end date, goal and team deliverables do not change every 24 H Sprint 1-4 Weeks Scrum Master Sprint Review & Retrospective Sprint Planning PRODUCT OWNER the Team Product Backlog Sprint Backlog Features Tasks Sprint Planning meeting Team agrees on how much to complete by sprint's end Burndown / Up Charts Information from end-users, customers, team and stakeholders
  • 17.
    •Agile Scrum isan agile process that allows us to focus on delivering the highest business value in the shortest time. •It allows us to rapidly and repeatedly inspect actual working services and/or software (every two weeks to one month). •The business sets priorities. Teams self- organize to determine the best way to deliver the highest priority features. Agile Scrum in Less Than 100 Words 17
  • 18.
    Waterfall vs. Agile Change(Learning) Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements 18
  • 19.
    Exercise 1B: Challengesto Building End-to-End Systems Brainwrite the following answers: 1) How would you see Agile helping teams build end-to-end systems? 2) What are some of the challenges you think you will face? Brainwriting – Write 3 ideas in 5 minutes and then discuss as a group 19
  • 20.
    Introducing Agile Scrum tothe Organization • It is about moving ideas between minds (attitude, trust, distance, tacit knowledge, work environments) • It is about identifying the Shifting of Power, new roles (decision makings, role definitions, power centers) • It is about knowing the Implications of distance, face-to-face, tacit versus documented, culture • Increasing team cohesion, visibility displays, collaborative requirements/planning applications 20
  • 21.
    Section Summary andConclusions The learning objectives for this section were: – Fundamentals of Agile Scrum ✓ Simulation exercise ✓ Manifesto (Statement of Values) ✓ 12 Principles – Review the Agile Product Life Cycle – Describe the Agile roles and responsibilities – Contrast Scrum with Waterfall 21
  • 22.
    Section 2 Value DrivenDelivery – Identify Case Study and Agile Team 22
  • 23.
    Section Learning Objectives •The learning objectives for this section are: – Understand why agile development focuses so heavily on value and adaptive planning – Review the Agile application lifecycle, Agile project characteristics, and Agile roles – Select a Case Study and assemble the Agile Team 23
  • 24.
    Value-Driven Development • Agileis based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross- functional teams. • Unlike traditional 6-12 month planning and execution cycles, Agile allows the team to adapt to fast-changing conditions, respond to immediate needs, and prove ROI quickly and consistently. 24
  • 25.
    Agile Scrum Characteristics •Self-organizing teams • Product progresses in a series of 2 to 4 week long “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed • Uses generative rules to create an agile environment for delivering projects 25
  • 26.
    Exercise 2a: Selectthe Case Study Select an initiative for your Agile case study • In groups that will become an Agile team 1. Identify projects from your work that meet these criteria: • Not too far along, or not started (< 20% complete) • Not too small or too big (6-18 months) -- A single phase of a larger product can work • Sufficiently complex to be interesting • A team member knows (or can improvise) enough to play the role of Product Owner 2. Select the best candidate for an Agile project • In teams with the Instructor 3. Discuss alternatives, focusing on merits for subsequent exercises 26
  • 27.
    Assemble the AgileTeam •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Burndown charts Artifacts •Product Owner •ScrumMaster •Team Roles 27
  • 28.
    AGILE METHODOLOGY Scrum RoleAllocation The Product Owner is responsible for economic success, and represents the interests of users and stakeholders PRODUCT OWNER The Scrum Master acts as the moderator of the project team, and ensures compliance with the rules SCRUM MASTER They are self-organized and responsible for development tasks TEAM MEMBERS Stakeholders communicate their general product needs and requirements STAKEHOLDER S The customer pays for product development in order to use the product later CUSTOMERS SCRUM ROLES
  • 29.
    SCRUM – TEAM SupportingActivities ▪ Finding techniques for effective Product Backlog management ▪ Helping the Scrum team understand the need for clear and concise Product Backlog items ▪ Facilitates Scrum implementation ▪ Coaching in self-organization and teamwork and removing impediments from the development team ▪ Helps the development team to create high-value products ▪ Facilitates Scrum implementation ▪ Leading and coaching the organization in its Scrum adaption, planning Scrum implementation within the organization ▪ Helping employees and stakeholders understand and enact Scrum and empirical product development PRODUCT OWNER DEVELOPMENT TEAM SCRUM MASTER ORGANIZATION Source: ©Scrum.Org and ScrumInc., Ken Schwaber and Jeff Sutherland: Scrum Guide
  • 30.
    Product Owner • Definethe features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) and Return on Value (ROV) • Prioritize features according to market value • Adjust features and priorities between (not during) every iteration, as needed • Accept or reject work results 30
  • 31.
    Identify the ProductOwner Product decision-maker • Authority to make decisions • Responsibility for product success • “Single Wring-able Neck” • One Individual • May represent others • Speaks for all product users • Knows business processes • Understands difficulties and unique needs 31
  • 32.
    Exercise 2b: Selectthe Product Owner • In small groups 1. Discuss the Case Study stakeholders 2. List the people or groups the Product Owner must represent 3. Identify who the ‘real-life’ Product Owner should be, and why (and who will assume the Product Owner’s persona for the Case Study) • As a class 4. Each group presents its Product Owner and decision criteria 32
  • 33.
    Build the ScrumTeam Establish the team early so they can: • Participate in project initiation • Help with the Product Backlog • Produce initial (coarse-grain) estimates • Jell as a team before the work begins 33
  • 34.
    The Scrum Master •Represents management of the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences 34
  • 35.
    Team Collaboration • Idealteam members • Identify with the team's goals • Empowered and entrusted with tasks • Supported by manager • Experienced and knowledgeable in field • Represent colleagues • Time to participate • Want to contribute to the success • Avoid representation through proxy 35
  • 36.
    Exercise 2c: Buildthe Scrum Team • In small groups 1. Discuss competencies needed 2. Identify who the ‘real-life’ Scrum Master should be, and why (and who will assume the Scrum Master’s persona for the Case Study) 3. Identify all of the Committed Team roles (full- time and part-time) and who will play them, and who else is on the Non-Committed Team • As a class 4. Each group presents its Team composition 36
  • 37.
    Section Summary andConclusions The learning objectives for this section were: – Value and adaptive planning – Agile application lifecycle, Agile project characteristics, and Agile roles – Selecting a Case Study, assembling the Team ✓ Product Owner ✓ Scrum Master ✓ Committed Team ✓ Non-Committed Team 37
  • 38.
    Section 3 Team MemberEngagement Envision the Product 38
  • 39.
    Section Learning Objectives •The learning objectives for this section are: – Understand the motivation behind team member expectations – Develop high-level functionality to support goals and strategies – Develop an overview for realizing the Vision with Agile ceremonies 39
  • 40.
    Exercise 3a: ReviewAgile Checklist • In small groups 1. Review the Agile Checklist document • Agile Development Rhythms • Meeting Checklists – Strategy Meeting • Getting Started 2. Discuss and capture the key elements that are in the checklist 40
  • 41.
    SCRUM – Preparation Sp r i n t C y c l e S p r i n t1, 2, 3 … N ▪ Business case & funding ▪ Contractual agreement ▪ Vision ▪ Initial Product Backlog ▪ Initial Release plan ▪ Stakeholder buy-in ▪ Assemble team PREPARATION RELEASE N SCRUM PROCESS PRODUCT BACKLOG PRODUCT BACKLOG BURNDOWN SPRINT BACKLOG SCRUM MASTER TEAM MEMBERS STAKEHOLDER USERS PRODUCT OWNER SPRINT BACKLOG BURNDOWN IMPEDIMENT LIST PRODUCT BACKLOG DELTA REPORT SPRINT PLANNING MEETING UPDATE PRODUCT BACKLOG PRODUCT INCREMENT SPRINT REVIEW SPRINT RETROSPECTIVE DAILY SCRUM / DAILY WORK
  • 42.
    Team Member Needs •Identify and engage effective and empowered business team members who are engaged with the team • Identify and engage all stakeholders (current and future) by promoting knowledge sharing early and throughout the project to ensure the unimpeded flow of value throughout the lifespan of the project Source: PMI ACP certification summary 42
  • 43.
    Product Envisioning – anAgile Best Practice • A common agile practice is to perform some high-level requirements envisioning early in the project to help come to a common understanding as to the scope of what you're trying to accomplish. • The goals at this point are to identify the business goals for the effort, develop a common vision, and swiftly identify the initial requirements for the system at a high-level. 43
  • 44.
    Product Vision andScope Project Scope in Agile environment is dynamic • Start with high-level business and technical needs • Envision ‘Epics’ to be broken down into features, stories, development activities • May need more envisioning to refine product and service groupings, business process capabilities, and value streams 44
  • 45.
    Articulate Business Functionality High-levelfeatures; not all of the detail • Either User Stories • As a {business role}, • I need {specific functionality}, • So that {business purpose}. • Or high-level Use Case outline • User goal and ‘happy path’ outcome • Measures of success: “Given, when, then …” 45
  • 46.
    Articulate Technical Functionality High-level;not all of the detail • Either technical capabilities • Infrastructure • Operational expectations • Architecture framework • Or high-level User Story • As a {system component}, • I need {specific functionality}, • So that {business purpose} 46
  • 47.
    Articulate Technical Functionality High-level;not all of the detail •Either technical capabilities • Infrastructure • Operational expectations • Architecture framework •Or high-level User Story • As a {system component}, • I need {specific functionality}, • So that {business purpose} 47
  • 48.
    Agile Realization Business motivation– a set of product, service or architectural needs (Product Vision) – realized in: • Product Backlog consists of high-level stories (Project Vision, Epics and Features) • Minimum marketable feature set (Release Plan) • New initiative (Sprint Zero, Spikes) • Rate of development (Velocity, Burn Down) • Sprint Backlog (Stories, Tasks, Test Criteria) • Complex projects (Sprint Stabilization) • Multiple initiatives (Scrum of Scrums) 48
  • 49.
    Section Summary andConclusions The learning objectives for this section were: – Understand the motivation behind stakeholder expectations ✓ Stakeholder engagement ✓ Strategy meeting ✓ Elevator pitch – Develop an overview for realizing the Vision with Agile ceremonies ✓ Agile checklist 49
  • 50.
    Section 4 Initiate anAgile Project– Planning Releases 50
  • 51.
    Section Learning Objectives •The learning objectives for this section are: – Discuss how you would initiate an Agile project – Discuss common practices that work when planning Agile projects – Determine how you will organize features and releases 51
  • 52.
    Exercise 4a: Adaptingto a Change-Driven Project Plan • Group discussion 1. How do you adapt to a change-driven approach from a (traditional) plan-driven approach? Questions to ask: - Do you have all the facts that will provide clarity for planning the ENTIRE project? - Are there any known unknowns? - Do you have multiple options to choose from during the project? 52
  • 53.
    Planning in theAgile Product Development Life Cycle 53 “Five Levels of Agile Planning”
  • 54.
    Initial Release Plan Theinitial release plan is understood to be rough. It must be detailed enough only to get us started by predicting that the project will deliver enough return on investment to more than pay for it. REMEMBER In Agile projects we plan continuously, and we correct our course as we go. 54
  • 55.
    Product-Level Planning Customer-specific productrelease success criteria share the following characteristics: • Identify specify current or prospective customer ‘personas’ so the team knows who they are trying to satisfy • Define specific actions by the customer that will indicate the product release has met its goal • Set timeframes during which actions must take place for the product release to be considered a success 55
  • 56.
    Prioritize Releases Since initialProduct Backlog items can be difficult to prioritize, it’s useful to prioritize Releases first, then items within and, if necessary, across themes Factors to consider when determining priorities: • Value • Knowledge • Uncertainty and risk • “Releasability” • Dependencies 56
  • 57.
    Group Initial ProductBacklog Items 57
  • 58.
    Exercise 4b: CreateRelease Plan Using the case study and Release Planning checklist discuss an initial Release Plan • In teams 1. Expand business and technical functionality (more features and capabilities) to produce an initial Product Backlog 2. Team and Product Owner consider multiple factors to organize features in a Release Plan • As a class 3. Discuss release schedule and constraints 58
  • 59.
    Section Summary andConclusions The learning objectives for this section were: – Discuss how you would initiate an Agile project ✓ Five Levels of Agile Planning – Discuss common practices that work when planning Agile projects ✓ Release Plan Meeting 59
  • 60.
    Section 5 Coarse-Grain Estimates andTime-Boxed Iterations 60
  • 61.
    Section Learning Objectives •The learning objectives for this section are: – Determine high-level items in Product Backlog – Estimate at the level of detail sufficient for planning and prioritizing – Estimate throughput (delivered items) within time and resource constraints 61
  • 62.
    Embrace High-Level Vision andRelease Plan Product Life Cycle budget requires estimating how many Sprints will it take to achieve the desired outcome. Individual Sprint components may include: • Modeling • Implementation and testing • Deployment, configuration management, training and documentation • Synchronization, refactoring and data hygiene • Environment changes 62
  • 63.
    Develop the ProductBacklog • A list of all desired work on the project • Each item has value to the users or customers of the product • Prioritized by product owner (and the team) • Become ‘requirements’ • Allows team to estimate items when needed, at the level of detail needed This is the Product Backlog 63
  • 64.
    Guidelines for theProduct Backlog Guidelines for creating the Product Backlog are: • Keep your Product Backlog between 50 and 100 items total • The top 20 to 40 items are small enough to be estimated at a high level • Put acceptance criteria on top 20-40 items 64
  • 65.
    Establish Decision andAcceptance Criteria for User Stories Writing user stories is simple if you follow these simple steps: 1. As a [role], I can [feature] so that [reason] 2. Use index cards and a Sharpie 3. Make it testable with acceptance stories • Given [context], when [event], then [outcome] 4. Connect the dots [start the conversation] 65
  • 66.
    Exercise 5a: ElaborateBusiness Functionality • In small groups 1. Agree on documenting with User Stories 2. Decompose high-priority business functionality into at least 10 user stories (one per 3x5 sticky note) with success criteria 3. Note technical functionality associated with user stories as additional success criteria • As a class 4. Each group presents stories they have added to their Product Backlog 66
  • 67.
    Estimate Complexity Using StoryPoints • Relative measure of effort to implement User Stories • Abstract number for ‘how hard’ the story is • ‘Hard’ could be related to technical functions, complexity, unknowns and deployment tasks • Defined by team and constant over all Sprints • Examples (shirt size, scale 1-10, or fibonacci): • “Send to a Friend” = 2 • “Shopping Cart” = 8 67
  • 68.
    Coarse-Grain Estimates • Teamestimates relative complexity • For each Business User Story (or Use Case) • “Coarse-grain” estimate based on high-level functionality and technical factors • Unit of measure: “Story Points” 1 point = routine story, low effort, little or no complexity, with an average team doing concentrated, un-interrupted work • Scrum Master facilitates estimation 68
  • 69.
    Exercise 5b: EstimateComplexity (Coarse-Grain) • In small groups 1. Estimate each story • ScrumMaster facilitates the game • Team does the estimating • Product Owner does not estimate! • Estimate Story Points 2. Write the effort estimates on the story cards • As a class 3. Each group presents their Estimates 69
  • 70.
    Agile (Scrum) IsTime-Boxed • Invert the Iron Triangle • Fix date and resources • Vary scope • Reduce waste • Estimate throughput • Optimize value (each Sprint; entire Project) • Prioritize needs • Deliver maximum value in time allowed 70
  • 71.
    Project Time-Box Considerations •Required end-date • Project budget • Resource availability • Others? The project will deliver the greatest possible business value (as defined by the Product Owner) within the project time-box 71
  • 72.
    Establish Core Hours •How will the team work during the day? • How many hours can you get from your committed resources during the sprint? • What impact does this have the team’s capacity? 72
  • 73.
    Team Velocity • Overa number of sprints you will see how many story points you can achieve – the velocity • This allows you to predict throughput based on number of story points in the backlog REMEMBER – one team’s story point is not the same as another's 73
  • 74.
    Project Time-Box •Time-boxing representsthe project timeline, given Product Backlog and Team Velocity • Begin date • End date • Sprint length • Number of Sprints Jan Feb Mar Apr May Jun Jul Sprint #1 Sprint #2 Sprint #3 Sprint #4 Sprint #5 Sprint #6 Sprint #7 74
  • 75.
    Section Summary andConclusions The learning objectives for this section were: – Determine high-level items in Product Backlog ✓ User stories and acceptance criteria – Estimate at the level of detail sufficient for planning and prioritizing – Estimate throughput (delivered items) within time and resource constraints ✓ Velocity ✓ Time-box 75
  • 76.
    Section 6 Plan theIteration (Part I) 76
  • 77.
    Section Learning Objectives •The learning objectives for this section are: – How to plan an Agile iteration (Sprint) – Review Day 1 planning activities, roles and expectations – Address common challenges of Agile planning 77
  • 78.
    Sprint Planning • Scrumprojects make progress in a series of “Sprints” • Typical duration is less than a calendar month • Time-boxing leads to better rhythm, efficiency • Potentially shippable product is specified, designed, coded, tested and accepted • Sprint Planning selects Sprint Backlog items and develops understanding of Tasks 78
  • 79.
    Iteration Planning inContext of Agile Unified Process 79 • ‘Inception’, ‘transition’ and ‘production’ phases apply to the flow within a Sprint, and to the overall plan across multiple Sprints
  • 80.
    Exercise 6a: Sprint‘Zero’ Activities • In small groups, discuss 1. What is Sprint Zero? 2. What activities could be included in Sprint Zero? For a simple project? For a complex project? • As a class 3. Do you expect the first sprints to be clean and well executed? Why or why not? How do you address this? 80
  • 81.
    Spikes • Stories to •Research technical and functional issues • Secure budget and reach financial decisions • Prototype capabilities that require feedback • Help understand complexity • Often ‘thrown away’ • Output is a better estimate for original story If we knew what we were doing it wouldn’t be research - Albert Einstein 81
  • 82.
    Master Test Plan AnAgile master test plan includes: • Intro with objectives and team members • Scope (what will be tested) • Assumptions and risks • Test approach (including automation) • Test environment • Milestones/deliverables with the schedule 82
  • 83.
    Backlog Accuracy Continuous planningis much more accurate if it occurs on at least two levels: • At the release level, identify and prioritize the features the PO must have, would like to have, and can do without by the deadline • At the iteration level, pick and plan for the next batch of features to implement, in priority order Features too large to be estimated or delivered within a single iteration must be broken down or researched further 83
  • 84.
    1st Half ofSprint Planning Meeting • First part of the meeting - collaborative effort • Product Owner, Team, Scrum Master • Anyone who wants to attend is welcome • Set Sprint goal and scope • Based on progress to date and any changes • Learn more detail about highest priority items • Accept Product Backlog items into Sprint • Time-boxed marching plans for the Team 84
  • 85.
    Sprint Goal andScope • Small reversible steps • Welcome change • Cross-functional team • Include design and testing • Maintain constant pace • Share commitment • ‘DONE’ • Get feedback quickly This Sprint 85
  • 86.
    Identify PBIs forthe Sprint ScrumMaster facilitates while Product Owner and Team collaborate to: • Break down larger stories • Prioritize stories • Decide which PBIs may be put into production • Team collaborates to: • Review velocity and capacity • Select stories for current iteration 86
  • 87.
    Story Size andSprint Capacity If XYZ story can be accepted in one Sprint: • Add support for XYZ • Consider adding another story If XYZ story cannot be accepted in one Sprint: • Consider what elements can be worked • Create User Interface/Workflow for XYZ • Process normal XYZ success (no exceptions) • Apply all business rules to XYZ 87
  • 88.
    Exercise 6B: Confirmand Refine High-Priority Product Backlog Items • Using the Iteration Planning checklist 1. Using the Backlog PBI Create 1. An EPIC 2. Five Features 3. Three Stories for the first feature 4. Estimate complexity of the User Stories (T- Shirt sizes, or 1.3.5) • As a class 3. Discuss the advantages and disadvantages of this approach 88
  • 89.
    Section Summary andConclusions The learning objectives for this section were: – How to plan an Agile iteration (Sprint) – Review Day 1 planning activities, roles and expectations ✓ Iteration Plan Meeting ✓ Estimating with T-Shirt Size or 1,3,5 – Address common challenges of Agile planning ✓ Sprint ‘0’, Spike, Master Test Plan 89
  • 90.
    Section 7 Plan theIteration (Part II) 90
  • 91.
    Section Learning Objectives •The learning objectives for this section are: – How to complete planning for a Sprint – How to estimate at the task level and identify risk factors – Understand who commits to and approves the Sprint plan 91 AIM
  • 92.
    2nd Half ofSprint Planning Meeting Second half of meeting - collaborative effort within Team: • Clarify Sprint Backlog items • Break down stories to associated tasks • Identify modeling requirements • Create initial list of issues, dependencies, assumptions, non- functional requirements • Estimate tasks (Ideal Days or Hours) • Definition of DONE • Tasks become committed for the Sprint 92
  • 93.
    Estimate Relative Effort(Fine Grain) •Team estimates relative effort • For each task • ‘Fine-grain’ estimate based on team’s experience and different perspectives •Scrum Master facilitates estimation •Option: • Self-select tasks first, then team member estimates own tasks 93
  • 94.
    Sprint Backlog Example Includesrough estimates Prioritized by value & risk Publicly visible Better to describe as user stories 94
  • 95.
    Finalize the SprintPlan Scrum Master Facilitates: • Product Owner and Team collaborate to finalize what will be delivered in the Sprint, based on: • Sprint Goal • Initial plan for this Sprint • Team’s velocity • Other information 95
  • 96.
    Section Summary andConclusions The learning objectives for this section were: – How to complete planning for a Sprint – How to estimate at the task level and identify risk factors ✓ Ideal Days – Understand who commits to, and approves, the Sprint plan 96
  • 97.
    Section 8 Tools andTechniques for Managing Scrums 97
  • 98.
    Section Learning Objectives •The learning objectives for this section are: – Review the four main tools and techniques that guide progress – Discuss how to use these techniques in an Agile environment 98
  • 99.
    Manage the Scrum Tomaintain rhythm and sustainable pace of work, manage Scrum activities through • Self-selecting tasks near to priority order • Displaying work in progress • Communicating status and spotting obstacles daily • Reporting progress that is visible, highly transparent, and easily understood 99
  • 100.
    Daily Scrum Meeting •Only 15 minutes a day • Stand up meeting • Only “committed” members can talk • 3 questions are asked • Commitment and accountability • Say what you do, do what you say • Whole world is invited This is the Daily Scrum Meeting 100
  • 101.
    Example #2 SCRUMTask Board 101
  • 102.
    Burndown Chart • Ona Scrum project, the team tracks its progress against a sprint or release plan by updating a burndown chart • The horizontal axis of the chart shows the time, and the vertical axis shows the amount of work remaining • Work remaining can be shown in whatever unit the team prefers – story points, ideal days, team days, and so on 102
  • 103.
  • 104.
    Exercise 8a –Discussion –Create a Scrum board with work streams • As a team, discuss how you would create a Scrum board with work streams 104
  • 105.
    Section Summary andConclusions The learning objectives for this section were: – Review the four main tools and techniques that guide progress ✓ Self-managing teams ✓ Daily Standup meeting ✓ Task Board ✓ Burndown Chart – Discuss how to use these techniques in an Agile environment 105
  • 106.
  • 107.
    Section Learning Objectives •The learning objectives for this section are: – Understand how requirements emerge, change and are satisfied during the Sprint – Discuss the importance of self-managed teams – Demonstrate how the Daily Standup Meeting fosters collaboration and communicates status to committed and non-committed resources 107 AIM
  • 108.
    Paradigm Shift inRequirements • Plan-driven limitations • Documents do not generate value directly • Unidirectional from author perspective • Agile ‘User Story’ represents a conversation • Visual display, easily annotated • Whiteboard modeling for clarity and insight • ‘Given, when, then’ conditions • Automated tests confirm details • Artifacts (cards) are only temporary 108
  • 109.
    Select ‘Next Priority’Task • Each team member selects (one) task-level item • Next highest in priority ranking • Dependency item, cover item or other association with related requirements • Skill level and capacity • Unresolved issues • Level of collaboration • Re-estimate in hours or ideal days • Post on Task Board 109
  • 110.
    Validate Agile Requirements •Identify assumptions • Define measurable evaluation criteria • Determine business value • Determine dependencies for benefits realization • Evaluate alignment with business case and opportunity cost 110
  • 111.
    Create Test Scenariosand Test Cases from User Stories • User story detail (exhaustive, comprehensive) • Measures of success • Non-functional quality of service criteria • Integration and synchronization • Automated testing Note – Demonstrate completed work items at the Sprint Review meeting (Sprint Demo) 111
  • 112.
    Managing Scrums with DailyStand-Up Committed Team with cross-functional skills does the actual work 3 Questions are asked: • What have you completed since we last met? • What are you planning to complete until we meet again? • What, if any, impediments are you encountering that are preventing you from completing your work? 112
  • 113.
    Daily Scrum Rules •Purpose •Status update to synchronize Team’s work • Highlight ‘WIP’ ‘done’ or new impediments • Foster collaboration and self-organization •Logistics • Every business day, usually early in the morning • Short (time-boxed) and stand-up (no chairs) • Report status and take discussion off-line • NO presentations, problem-solving or decision-making! 113
  • 114.
    Review: Committed vs. Non-Committed •Committed resources have skin in the game • Everyone doing technical work on the project • Competencies (development, testing, DBA …) • So they may speak and show accountability • Non-Committed resources only contribute • Everyone else • Executive, Sponsor, Manager, Customer … • So they must remain silent, but remain engaged by listening and observing progress 114
  • 115.
    Removing Impediments toProgress Scrum Master ensures: • Interested Team members collaborate after the meeting to solve Technical problems • SM action items to clear the Team’s path and secure other groups’ cooperation to remove Organizational roadblocks • SM action items to shield team from Political infighting • SM action items to defend process integrity against attempts to circumvent Scrum practices 115
  • 116.
    Authority to ChangeSprint Backlog Only the Team can change the Sprint Backlog in the middle of a Sprint • Add items if necessary to achieve the Sprint goal or if resources are available for more work • Remove/modify items if the Sprint goal is still achieved AND if the Product Owner agrees • Priority was ‘low’ during planning • Scope has changed • Assess changes in Sprint Review and add back to the Product Backlog for next Sprint 116
  • 117.
    Section Summary andConclusions The learning objectives for this section were: – Understand how requirements emerge, change and are satisfied during the Sprint ✓ Facilitated workshops, preshops – Discuss the importance of self-managed teams – Demonstrate how the Daily Standup Meeting fosters collaboration and communicates status to committed and non-committed resources ✓ Roles and authority to change 117
  • 118.
  • 119.
    Section Learning Objectives •The learning objectives for this section are: – Understand why and how to conduct a Sprint Review 119
  • 120.
    Traditional Acceptance andSign-off • Customer acceptance is important for requirements approval • Team acceptance is important because they agree to accept the requirements and build them into a product • Sign-off on a requirements document is an act of customer approval of the requirements and brings closure before the requirements development process 120
  • 121.
    Exercise 10a: DiscussReview Planning Checklist • In small groups 1. Review the Iteration Review meeting checklist 2. Discuss and capture the key elements that are in the checklist • As a class 3. What makes Agile (Scrum) Sprint Review different from a traditional project approach? 121
  • 122.
    Sprint Review: WorkingProduct Is Showing Progress Sprint Review focuses on the finished product increment • Did the team produce what they promised? • Does it meet the Product Owner’s expectations? • Is it acceptable to the customers? • Was the Sprint goal achieved? 122
  • 123.
    Prepare for SprintReview • Team presents what it accomplished • Typically takes the form of a brief demo of new features or underlying architecture • JAD workshops, prototypes, testing occur within the Sprint as a completed Task • Informal • 2-hour prep time, no slides • Whole team participates (invite the world) • Product Owner accepts deliverables, adjusts Product Backlog 123
  • 124.
    Organizational Readiness What isit? • Organizational readiness reflects ability to accept and implement change • Requires necessary knowledge, skills, resources to assess and support • Critical to successfully implementing complex service delivery changes • Time to plan is early, while time to affirm is now • Accountability may rest with the Product Owner 124
  • 125.
    Definition of Done(DoD) Definition of Done (DoD) • The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. 125
  • 126.
    Input for theNext Sprint • Update the user stories and their priorities as customers' needs change • Break down user stories that are likely to be implemented in the next sprint 126
  • 127.
    Exercise 10b: Conducta Sprint Review • In small groups using the Review meeting checklist 1. Prepare for a Sprint Review • Assume goal is complete but certain tasks were changed • Consider this Sprint in context of Release Plan 2. Conduct the Sprint Review • As a class 3. Contrast Review meeting with traditional UAT 127
  • 128.
    Section Summary andConclusions The learning objectives for this section were: – Understand why and how to conduct a Sprint Review ✓ Sprint Review meeting ✓ Validation ✓ Organizational Readiness ✓ Definition of Done (DoD) 128
  • 129.
  • 130.
    Sprint Retrospective Quick LessonsLearned at end of every Sprint • What is working well for the team? • What is problematic for the team? • What practice changes shall we try? • Not more than 2 or 3 • Low-hanging fruit • Determine at the next Retrospective if the changes will be made permanent 130
  • 131.
    Key Process Indicators •Agile processes should be tailored to better serve the organization and project • Success metrics (quality indicators) for Agile • Planning (velocity as a reliable tool) • Collaboration (quality of relationships) • Requirements (validity after testing) • Deliverables (working software) • Deployment (service management) • Assessment mechanism: open discussion 131
  • 132.
    Sprint Retrospective Guidelines •Done after every Sprint • Typically 15–30 minutes • ScrumMaster facilitates open discussion among committed team • Review improvements from previous Sprint • Add any impediments not cited in Daily Scrum • Include non-committed team for part of the discussion as appropriate • Identify most important issues to work on for next Sprint, focusing on process not people 132
  • 133.
    Exercise 11b: PopQuiz! • Is it OK for a project to have more than 1 Product Owner? Why? • What is the Product Owner’s primary responsibility? ScrumMaster? Team Member? • Define these terms: • Time-boxed • Self-organizing team • Planning poker • Definition of Done 133
  • 134.
    Section Summary andConclusions The learning objectives for this section were: – Understand why and how to conduct a Sprint Retrospective ✓ Retrospective meeting ✓ Metrics 134
  • 135.
    Section 12 Boosting TeamPerformance 135
  • 136.
    Section Learning Objectives •The learning objectives for this section are: – Raise concerns with introducing Agile methods in a Waterfall culture – Discuss scaling larger projects and portfolios – Introduce performance issues facing Agile teams 136 AIM
  • 137.
    Scaling with LargerTeams Can committed resources represent small groups of technical peers? • Factors in scaling • Type of application • Team size • Team dispersion • Project duration http://whitewaterprojects.com/20 10/09/17/why-is-7-2-the-ideal- scrum-team-size/# 137
  • 138.
    The Dangers ofAgile Scrum • It’s hard! • It requires significant change • It makes all dysfunction visible • It demands honesty, transparency and accountability • Bad products will be delivered sooner, and doomed projects will fail faster • Partial adoption may be worse than none at all • Be forewarned: many Scrum adoptions fail 138
  • 139.
    Begin with StakeholderEngagement Keys to improving stakeholder engagement: • Team Formation • Team Empowerment • Team Collaboration • Team Commitment Then, as an on-going activity: • Coach • Solve Problems 139
  • 140.
    Exercise 12a: Discussionon issues with people and process Based on the organization’s current competencies and future needs, how can it best manage the transition to Agile? 1. What are the process issues 2. What are the people issues 3. How can we remove the impediments to progress? 140
  • 141.
    Section Summary andConclusions The learning objectives for this section were: – Raise concerns with introducing Agile methods in a Waterfall culture – Discuss scaling larger projects and portfolios – Introduce performance issues facing Agile teams 141
  • 142.
  • 143.
    Waterfall Cultural Roots •Originsin structured programming with quality process control •Project management • Known requirements • Variance from plan • Management culture, project leadership, project focus •Business analysis • Plan-driven requirements management 143 Requirements Planning Design Build Test Deploy
  • 144.
    Waterfall vs. Agile Change(Learning) Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements 144
  • 145.
    Exercise 13a: ComparingWaterfall (Plan-Driven) versus Agile (Change-Driven As a class determine the advantages and disadvantages of the Waterfall and Agile Framework 145
  • 146.
    Module 14 Wrap Upand Additional Information 146
  • 147.
    Course Learning ObjectivesSummary The learning objectives for this course were: This course shall help you develop and enhance your Agile skills so that they can provide significant value to projects and the business enterprise 147
  • 148.
    Agile Product LifeCycle (SCRUM) NOTE : ✓ Discussed in detail! 148
  • 149.
    Agile Reading List •Agile and Iterative Development: A Manager’s Guide by Craig Larman • Agile Estimating and Planning by Mike Cohn • Agile Project Management with Scrum by Ken Schwaber • Agile Retrospectives by Esther Derby and Diana Larsen • Agile Software Development Ecosystems by Jim Highsmith • Agile Software Development with Scrum by Ken Schwaber and Mike Beedle • Scrum and The Enterprise by Ken Schwaber • User Stories Applied for Agile Software Development by Mike Cohn • Lots of weekly articles at www.scrumalliance.org 149
  • 150.