SlideShare a Scribd company logo

Agile Development with Scrum.pptx

Download as PPTX, PDF
Z
zuma14

The document provides an overview of agile development using Scrum. It discusses the foundations and principles of Scrum, including self-organizing cross-functional teams and delivering working software every sprint. The key roles of Product Owner, Scrum Master, and Scrum Team are defined. Sprints are short iterations usually 2-4 weeks where working software is delivered. Meetings like sprint planning, daily standups, reviews and retrospectives support the process.

Software
1 of 74
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
AGILE DEVELOPMENT WITH SCRUM 9/13/2012
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Official Scrum Definition A development framework wherein cross functional, self managing teams deliver working software every thirty days.
Unofficial ‘Zen of Scrum’  Hire Smart People  Put them in small cross functional teams  Trust & empower those teams  Ask them to demonstrate working stuff once a month
 What should we build?  Watt’s Humphries: “Requirements cannot be fully known until users have tried the software.”1  Jakob Nielsen: “For 50 years, almost all experience with traditional waterfall development methods have found that it results in poor user experience. The reason is simple: requirement specifications are always wrong.” 2 1Watts Humphrey's Requirements Uncertainty Principle 2Agile Usability: Best Practices for User Experience on Agile Development projects Why Scrum?
 Simple, Definable Projects:  Given a set of inputs, tasks can be defined that will generate the same outputs every time.  Complex, Chaotic Projects  Tasks cannot be defined that will generate consistent outputs  Axes of Certainty  Technical and Domain are only two…  Team stability, capability  Organizational agreement on priority 6 Technical Certainty High Low High Low Domain Certainty Simple Complex Chaotic Anarchic Complex Why Scrum?
 Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute 7 Why Scrum?
 Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute 8 Why Scrum?
 Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute… Why Scrum?
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster
What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster A solution to development problems Something that exposes development problems early and often
Agile Manifesto (2001)  A set of values: Over Over Over Over Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Product Backlog Sprint Backlog Daily 2-4 Weeks Potentially Releasable Increment Sprint Goal Scrum Overview The list of all desired work for a product, project, or team Prioritized (1-n) by the Product Owner to ensure:  Balanced stakeholder demands  Alignment to corporate strategy  Driving of profit engine Can be added to by anyone Ideally expressed such that each item has value to the users or customers of the product Frequently updated Potentially Releasable: 1. Delivers some value to users 2. High enough quality to release Vertical Slices:
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Three Roles in scrum  Product Owner  Scrum master  Scrum Team
Three Roles in scrum: Product Owner  Product Owner  Defines the features of the product, decides on release date and content  Is responsible for the profitability of the product (ROI)  Prioritizes features according to market value  Can change features and priority every sprint  Owns the “What to build” decisions
The 3 responsibilities of a Product Owner 1. Inspire The Team with your vision of what the product can become  Keep team focused on the Big Picture things like:  Target users, personas  Market opportunities  Long term strategy & roadmaps 2. Build The Product Backlog  Manage all stakeholder requests in a single, frequently update list  Present a clear, visible record of the product’s current priorities  Decompose large user problems into smaller ones as they approach implementation 3. Provide Feedback to the team:  You represent the users  Provide ongoing feedback during sprints and at sprint reviews
Three Roles in scrum: Scrum Master  Scrum master (1 per scrum team, initially)  Responsible for enforcing the values and practices of the process and the team  Remove impediments from the team  Remove barriers between team and others  Educate outside groups about how the team is working  Improve productivity in any way possible  Shields the team from external interferences  Owns the “Scrum Process” decisions
Three Roles in scrum: Scrum Team  Scrum Team  No formal concept of “Eng vs. QE”, only team members with individual expertise  7 developers, +/- 2 make up a scrum team  Scale through having multiple scrum teams  Selects the sprint backlog  Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal  Organizes itself and its work  Demos work results to the Product Owner  Owns the “How to build” decisions (including how fast)
 There are two main ways to structure teams:  Based on Architectural Layers  Cross-functionally Cross Functional vs. Architectural Layers Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Backend Team Frontend Team UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Cross Functional Scrum Team 1 UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Cross Functional Scrum Team 2
Overview of roles Product Owner Scrum Master Scrum Team What will we make? 1 per team or backlog Prioritize the Backlog  Provide Vision  Answer team’s questions  Work with all customers  Manage stakeholders Is the team healthy? Following the rules?  Ideally 1 per scrum team Team functioning highly  Team protected within sprints  Information team needs is readily available The oil that keeps the team running. How will we make it? How Fast?  ~7 people per team  Creative engineering solutions to customer problems  Architecture  Code Quality  Sprint Backlog  Commitments for the sprint
Working on product backlog Role Time spent on sprint Time spent on Product Backlog Product Owner 10-20% 80-90% Scrum Team member 90% 10% UX, Architect, etc. 50% 50%  Product Owner  Prioritize the backlog items  Work with stakeholders to add new items as they are requested  Ensure that high priority items are being decomposed to an appropriate size  Scrum Team  Provide estimates  Provide technical backlog items necessary to reach product vision  Help the P.O. decompose items
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking  Debrief
Sprints  Two to four week iteration  Deliver working software  Deadline is sacred  Drop scope to meet the deadline  Product Owner can’t add new stuff once they’ve started  Team Can  Product Owner can abnormally terminate
Scrum Meetings Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting Scrum of Scrums Meeting
Purpose of sprint planning  What is the primary goal of the sprint planning meeting? Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
Purpose of sprint planning  Arrive at a commitment to a sprint goal or set of product backlog items  Not “come up with a list of tasks”  Tasks and estimates are a tool to ensure we can commit Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
Sprint Planning  Day 1 of sprint  Sometimes broken into two parts:  Part 1 (4 hours):  Product Owner describes user stories  Clarifying discussion with the team  Sprint Goal is chosen  Initial Commitment from team  Part 2 (4 hours): Determine Capacity for sprint Break down stories into tasks (code, test, etc.)  Estimate tasks in hrs or days (1/2–2 days)  Final commitment for sprint  These two can be combined:  Discuss first backlog item,  Break it down into tasks  Task estimates  Team commits  Repeat with item 2 Product Backlog Sprint 1 Sprint 2 Sprint 3 Sprints 4-5 Sprints 6-10
Breakdown a story/feature into tasks Product Backlog Sprint Backlog At the end of the sprint planning meeting you have:  a set of estimated tasks  a team commitment to complete the product backlog items represented by the sprint backlog Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
Sprint Burndown Chart 1 0 9 8 7 6 5 4 3 2 1 0 50 40 30 20 10 0 Y: Stuff Left To Do: X: Time Left in Sprint:
What if we discover we’re over- committed?  Two options (team chooses): 0 200 400 600 800 1000 1200 1400 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0  Work overtime to meet the commitment  But: sustainable pace?  Remove work as soon as they think they’re over committed  This is a discussion with the product owner.
Daily Scrums 15 Minutes  Three Questions What have you done? What will you do? What’s in your way?  Goal 1: commit in front of peers.  Goal 2: ensure we’re on track to meet our commitments for the sprint.  Not for problem solving Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
Scrum of Scrums  Each team sends a representative  Rotate attendance based on whose skills are needed most  Usually 2-3 times per week  Four Questions What has your team done? What will your team do? What’s in your team’s way? What are you about to put in another team’s way?  These are problem solving meetings Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting Scrum of Scrums Meeting
Definition of Done  General Definition of Done: the template of development steps that all features should go through, determined by the team and the product owner at the beginning of the cycle.  Typically includes things like:  designed, coded, automated tests created, unit tests created, functional testing completed, unit tests passing, integration testing completed, documented.  Whatever your team agrees that EVERY feature must do to be considered done.  The more mature & disciplined the team, the more complete this list, including things like localization & loc testing complete, security audited, code peer-reviewed, etc.
Sprint Review  “Inspect” product  Team presents what was accomplished during the sprint  Typically a demo of new features  Informal No slides Minimal prep  Whole team participates  Invite the world Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
Sprint Retrospective Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting  “Inspect” process  Periodically take a look at what is and what isn’t working  Can be short, sometimes long  Done after every sprint  Whole team participates
Retrospectives & Self Management: A Tale of Three Sprints Sprint 7 Sprint 8 Sprint 9
Sprint 8 Retrospective  Team frustrated that work is not getting all done in a sprint  We’ve tried deferring earlier, now what?  Team agreed:  Decompose larger stories into much smaller stories for the next sprint  Each story needs to be testable  Mantra for next sprint planning: “and how will we test this?”  Be very careful with check-ins approaching end of sprint Before: After: Uh Oh! No Problem
Team “discovered” TDD, further vertical slicing Sprint 7 Sprint 8 Sprint 9  Sprint 9:  Team broke features down smaller  We could defer small stories at any time  Sprint planning meeting was test driven  Completed all work in the sprint!
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Goals of Agile Engineering Techniques  Remove defects as early as possible  Improve code health, eliminate technical debt  Promote collective ownership & understanding  Deliver razor thin slices as frequently as possible  Work at a sustainable pace
Agile Engineering Practices  Test Driven Development  Pair Programming  Peer Reviews  Continuous Integration  Automated Acceptance Testing
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Example Requirement Requirement 1.05a: The application should automatically save open documents at regular intervals
User Stories I want <some function>  User Stories add two pieces of information to a typical requirement:
Creating a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.
Example Requirement 1.05a: The application should automatically save open documents at regular intervals Why? Who needs this functionality?
Create a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.  Example: Auto-save document
Where are the details?  The product owner’s conditions of satisfaction can be added to the back  These are essentially tests
Where are the details?  The larger story can be broken into multiple smaller stories
Stories, Themes, and Epics User story A description of functionality told from the users perspective Theme A collection of related stories Epic A really big story
Ideas for splitting stories  Focus on “vertical slices”  Tracer Bullet  Break into Acceptance Tests/Conditions of Satisfaction  Then turn those into smaller stories  20 ways to split stories  http://xp123.com/xplor/xp0512/
Attributes of a good story  Independent  Negotiable  Valuable  Estimatable  Sized Appropriately  Testable  Eliminate as many dependencies as possible  Stories aren’t contracts, leave or imply some flexibility  To users  Plans are based on stories, so we need to estimate  Small enough to work on in a sprint if it’s close to implementation  How will we know it’s done? No partial credit
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Agile Planning & Estimation  Goal is always to be accurate  Precision increases as project goes on  Is more focused on planning than the plan  Encourages changes  Results in plans that are easily changed  Is spread throughout the project
Estimation accuracy over time X = Time Spent Y = Estimation Accuracy 100% 1 2 3 4 5 6 7 Highest ROI More Certainty, at higher cost
Traditional Time Estimates How long will it take to eat all of this candy?
Traditional Time Estimates How long will it take to eat all of this candy?  What factors might influence the answer?  Who is doing the work?  Interruptions?  What kind is it?  Motivations?  How tired?
Agile Estimates: Relative Size Candy Units = X Candy Units = 3
Orders of Magnitude 3 6
Orders of Magnitude 3 6 ? ?!?!
Limiting the set of possible values  We only estimate well within one order of magnitude  Difference between 3 and 6 is obvious, worth discussing  What about 103 and 106?  Limit possibilities to naturally occurring sets of increasing values:  Fibonacci: 1,2,3,5,8,13,21,etc.  Exponential: 1,2,4,8,16,32,etc.
Estimating Size in Story Points  Story Points:  The “bigness” of a backlog item  Influenced by how hard it is, how much there is  Unit is arbitrary, but relative  (6 story point item) should be 2x(3 story point item)  Estimate of getting the story “Done”
Estimating with Planning Poker  Iterative, team based approach 1. Each estimator has a deck of cards with potential estimates based on set (Fibonacci, etc.) 2. Product Owner reads a backlog item, brief clarifying discussion occurs 3. Estimators choose a card indicating their estimate 4. Cards are revealed all at once 5. Differences are discussed, especially outliers
Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
Two levels of planning Release Planning Sprint Planning Goal Enable product level decisions such as scope, release date, resources required Enable the scrum team to commit to a specific set of work for a given sprint Led By Product Owner Product Owner + Scrum Team Artifac t Product/Release Backlog Sprint Backlog Items User Stories/Features Tasks Units Story Points Task Hours Units over time Velocity Capacity Don’t confuse the goal, items, or units from one level with the activities of the other!
Building a Release Plan  Create Product Backlog  One Line Item – but can be months of work  Product Owner leads  Market Research, positioning, etc.  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20
Velocity  Total story points for all product backlog items meeting the definition of done at the end of a sprint  Averaged over time  Three ways to calculate: 1. Based on historical values 2. Ideally after a sprint or two 3. Forecasted when necessary
Projecting Velocity when historic values aren’t available Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to 20  Choose a few stories Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I 2  Break down to tasks, estimate Task Hours 128 210 272 225 45 Totals: 41 880  Compare totals to sprint capacity Sprint Capacity = ~900 Hours  Calculate Sprint Capacity Projected Velocity = ~ 42 story points per sprint  Estimate Velocity per sprint
Calculating Average Velocity (historic)  Average (30) 0 5 10 15 20 25 30 35 40 45 1 2 3 4 5 6 7 8 9 10 11 Velocity Last 8 sprints  Worst Case (23) Lowest 3  Best Case (38) Highest 3
Building a Release Plan  Create Product Backlog  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20  Average (30) Sprint 1 26 points May4-May31 Sprint 2 26 points Jun1-Jun28 Sprint 3 30 points Jun29-Jul26 Sprint 4 30 points Jul27-Aug23  Update after each sprint
Q&A
THANK YOU

More Related Content

PPTX
Azure dev ops
Tomy Rhymond
 
PPT
Agile Scrum Methodology
Dr. Syed Hassan Amin
 
PPT
Dot+Net+2010+Features
gurbaxrawat
 
PPT
Agile
kuldeep singh
 
PPT
Agile
AHM Pervej Kabir
 
PPT
Agile
Shehbaz Nadeem
 
PPT
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
varty
 
PDF
Agile Process Introduction
Nguyen Hai
 
Azure dev ops
Tomy Rhymond
 
Agile Scrum Methodology
Dr. Syed Hassan Amin
 
Dot+Net+2010+Features
gurbaxrawat
 
Agile
kuldeep singh
 
Agile
AHM Pervej Kabir
 
Agile
Shehbaz Nadeem
 
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
varty
 
Agile Process Introduction
Nguyen Hai
 

Similar to Agile Development with Scrum.pptx (20)

PPTX
Introduction to agile
Sandipp Vijj, Digital Disruptor
 
PPT
Introduction into Scrum
msorin
 
PPT
Intro To Scrum
scottycn
 
PDF
Scrum and Agile SDLC 101
Aniruddha Ray (Ani)
 
PPTX
Research paper presentation on agile scrum
Abdullah Raza
 
PPTX
Introduction to Scrum
James Walmsley CSM, PSM I, PSK I
 
PPT
An Introduction to Scrum
mbalas2
 
PPT
Redistributable Intro To Scrum
Erwin Verweij
 
PPT
Agile Scrum Methodology
Rajeev Misra
 
PPTX
Case Study on agile scrum methodology on shopping cart
Abdullah Raza
 
PPT
Scrum Testing Methodology
Gaya1985
 
PPTX
Introduction To Scrum Presentation for beginners
ssuser92ac1f
 
PPTX
Agile & SCRUM
ejlp12
 
PPTX
Ssw forte-agile-seminar
SSW
 
PPTX
Close to agile
philywu
 
PPTX
Agile methods
DUONG Trong Tan
 
PPT
notes-SRE Lec_2.ppt University of Education Lahore Pakistan
muhammadshan6133044
 
PPT
notes-SRE Lec_2(2).pptx education dg khan
WaleedAbdullah55
 
PPTX
Agile Methodology in Software Development
Raghav Seth
 
PPTX
Introduction to Agile Project Management - Scrum 101
Marge Tam, PMP, CSM, A-CSM
 
Introduction to agile
Sandipp Vijj, Digital Disruptor
 
Introduction into Scrum
msorin
 
Intro To Scrum
scottycn
 
Scrum and Agile SDLC 101
Aniruddha Ray (Ani)
 
Research paper presentation on agile scrum
Abdullah Raza
 
Introduction to Scrum
James Walmsley CSM, PSM I, PSK I
 
An Introduction to Scrum
mbalas2
 
Redistributable Intro To Scrum
Erwin Verweij
 
Agile Scrum Methodology
Rajeev Misra
 
Case Study on agile scrum methodology on shopping cart
Abdullah Raza
 
Scrum Testing Methodology
Gaya1985
 
Introduction To Scrum Presentation for beginners
ssuser92ac1f
 
Agile & SCRUM
ejlp12
 
Ssw forte-agile-seminar
SSW
 
Close to agile
philywu
 
Agile methods
DUONG Trong Tan
 
notes-SRE Lec_2.ppt University of Education Lahore Pakistan
muhammadshan6133044
 
notes-SRE Lec_2(2).pptx education dg khan
WaleedAbdullah55
 
Agile Methodology in Software Development
Raghav Seth
 
Introduction to Agile Project Management - Scrum 101
Marge Tam, PMP, CSM, A-CSM
 

Recently uploaded (20)

PDF
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
Andre Kraus
 
PDF
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
pts464036
 
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
PDF
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
IT IDOL Technologies
 
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
PDF
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
PPTX
Odoo POS Development Services by CandidRoot Solutions
CandidRoot Solutions Private Limited
 
PPTX
ManageIQ - Sprint 268 Review - Slide Deck
ManageIQ
 
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
William Chong
 
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
PDF
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
PDF
How Creative Agencies Leverage Project Management Software.pdf
Orangescrum
 
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
PPTX
history of c programming in notes for students .pptx
Vijayakumari829030
 
PDF
Raksha Bandhan Grocery Pricing Trends in India 2025.pdf
Actowiz Solustions
 
PDF
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
Andre Kraus
 
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
pts464036
 
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
IT IDOL Technologies
 
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
Odoo POS Development Services by CandidRoot Solutions
CandidRoot Solutions Private Limited
 
ManageIQ - Sprint 268 Review - Slide Deck
ManageIQ
 
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
William Chong
 
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
TechBuilder
 
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
How Creative Agencies Leverage Project Management Software.pdf
Orangescrum
 
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
history of c programming in notes for students .pptx
Vijayakumari829030
 
Raksha Bandhan Grocery Pricing Trends in India 2025.pdf
Actowiz Solustions
 
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 

Agile Development with Scrum.pptx

  • 2. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 3. Official Scrum Definition A development framework wherein cross functional, self managing teams deliver working software every thirty days.
  • 4. Unofficial ‘Zen of Scrum’  Hire Smart People  Put them in small cross functional teams  Trust & empower those teams  Ask them to demonstrate working stuff once a month
  • 5.  What should we build?  Watt’s Humphries: “Requirements cannot be fully known until users have tried the software.”1  Jakob Nielsen: “For 50 years, almost all experience with traditional waterfall development methods have found that it results in poor user experience. The reason is simple: requirement specifications are always wrong.” 2 1Watts Humphrey's Requirements Uncertainty Principle 2Agile Usability: Best Practices for User Experience on Agile Development projects Why Scrum?
  • 6.  Simple, Definable Projects:  Given a set of inputs, tasks can be defined that will generate the same outputs every time.  Complex, Chaotic Projects  Tasks cannot be defined that will generate consistent outputs  Axes of Certainty  Technical and Domain are only two…  Team stability, capability  Organizational agreement on priority 6 Technical Certainty High Low High Low Domain Certainty Simple Complex Chaotic Anarchic Complex Why Scrum?
  • 7.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute 7 Why Scrum?
  • 8.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute 8 Why Scrum?
  • 9.  Defined (predictable) projects  Define, Estimate, Create a Plan, and Execute to Plan  Empirical (chaotic) projects  Define Small Portion, Estimate, Create a Plan, Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute  Inspect & Adapt Plan  Create Plan & Execute… Why Scrum?
  • 10. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 11. What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster
  • 12. What Scrum is and what it is not: Scrum Is Not: Scrum Is: A development methodology that will make us build software faster A tool that will help us discover things we can do to build software faster A solution to development problems Something that exposes development problems early and often
  • 13. Agile Manifesto (2001)  A set of values: Over Over Over Over Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
  • 14. Product Backlog Sprint Backlog Daily 2-4 Weeks Potentially Releasable Increment Sprint Goal Scrum Overview The list of all desired work for a product, project, or team Prioritized (1-n) by the Product Owner to ensure:  Balanced stakeholder demands  Alignment to corporate strategy  Driving of profit engine Can be added to by anyone Ideally expressed such that each item has value to the users or customers of the product Frequently updated Potentially Releasable: 1. Delivers some value to users 2. High enough quality to release Vertical Slices:
  • 15. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 16. Three Roles in scrum  Product Owner  Scrum master  Scrum Team
  • 17. Three Roles in scrum: Product Owner  Product Owner  Defines the features of the product, decides on release date and content  Is responsible for the profitability of the product (ROI)  Prioritizes features according to market value  Can change features and priority every sprint  Owns the “What to build” decisions
  • 18. The 3 responsibilities of a Product Owner 1. Inspire The Team with your vision of what the product can become  Keep team focused on the Big Picture things like:  Target users, personas  Market opportunities  Long term strategy & roadmaps 2. Build The Product Backlog  Manage all stakeholder requests in a single, frequently update list  Present a clear, visible record of the product’s current priorities  Decompose large user problems into smaller ones as they approach implementation 3. Provide Feedback to the team:  You represent the users  Provide ongoing feedback during sprints and at sprint reviews
  • 19. Three Roles in scrum: Scrum Master  Scrum master (1 per scrum team, initially)  Responsible for enforcing the values and practices of the process and the team  Remove impediments from the team  Remove barriers between team and others  Educate outside groups about how the team is working  Improve productivity in any way possible  Shields the team from external interferences  Owns the “Scrum Process” decisions
  • 20. Three Roles in scrum: Scrum Team  Scrum Team  No formal concept of “Eng vs. QE”, only team members with individual expertise  7 developers, +/- 2 make up a scrum team  Scale through having multiple scrum teams  Selects the sprint backlog  Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal  Organizes itself and its work  Demos work results to the Product Owner  Owns the “How to build” decisions (including how fast)
  • 21.  There are two main ways to structure teams:  Based on Architectural Layers  Cross-functionally Cross Functional vs. Architectural Layers Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Backend Team Frontend Team UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Lead Architect Backend Programmer Backend Programmer Backend Programmer Backend Programmer Tester Tester Cross Functional Scrum Team 1 UX Designer Frontend Programmer Tester Tester Frontend Programmer Frontend Programmer Generalist Programmer Tester Cross Functional Scrum Team 2
  • 22. Overview of roles Product Owner Scrum Master Scrum Team What will we make? 1 per team or backlog Prioritize the Backlog  Provide Vision  Answer team’s questions  Work with all customers  Manage stakeholders Is the team healthy? Following the rules?  Ideally 1 per scrum team Team functioning highly  Team protected within sprints  Information team needs is readily available The oil that keeps the team running. How will we make it? How Fast?  ~7 people per team  Creative engineering solutions to customer problems  Architecture  Code Quality  Sprint Backlog  Commitments for the sprint
  • 23. Working on product backlog Role Time spent on sprint Time spent on Product Backlog Product Owner 10-20% 80-90% Scrum Team member 90% 10% UX, Architect, etc. 50% 50%  Product Owner  Prioritize the backlog items  Work with stakeholders to add new items as they are requested  Ensure that high priority items are being decomposed to an appropriate size  Scrum Team  Provide estimates  Provide technical backlog items necessary to reach product vision  Help the P.O. decompose items
  • 24. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking  Debrief
  • 25. Sprints  Two to four week iteration  Deliver working software  Deadline is sacred  Drop scope to meet the deadline  Product Owner can’t add new stuff once they’ve started  Team Can  Product Owner can abnormally terminate
  • 27. Purpose of sprint planning  What is the primary goal of the sprint planning meeting? Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
  • 28. Purpose of sprint planning  Arrive at a commitment to a sprint goal or set of product backlog items  Not “come up with a list of tasks”  Tasks and estimates are a tool to ensure we can commit Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
  • 29. Sprint Planning  Day 1 of sprint  Sometimes broken into two parts:  Part 1 (4 hours):  Product Owner describes user stories  Clarifying discussion with the team  Sprint Goal is chosen  Initial Commitment from team  Part 2 (4 hours): Determine Capacity for sprint Break down stories into tasks (code, test, etc.)  Estimate tasks in hrs or days (1/2–2 days)  Final commitment for sprint  These two can be combined:  Discuss first backlog item,  Break it down into tasks  Task estimates  Team commits  Repeat with item 2 Product Backlog Sprint 1 Sprint 2 Sprint 3 Sprints 4-5 Sprints 6-10
  • 30. Breakdown a story/feature into tasks Product Backlog Sprint Backlog At the end of the sprint planning meeting you have:  a set of estimated tasks  a team commitment to complete the product backlog items represented by the sprint backlog Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
  • 31. Sprint Burndown Chart 1 0 9 8 7 6 5 4 3 2 1 0 50 40 30 20 10 0 Y: Stuff Left To Do: X: Time Left in Sprint:
  • 32. What if we discover we’re over- committed?  Two options (team chooses): 0 200 400 600 800 1000 1200 1400 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0  Work overtime to meet the commitment  But: sustainable pace?  Remove work as soon as they think they’re over committed  This is a discussion with the product owner.
  • 33. Daily Scrums 15 Minutes  Three Questions What have you done? What will you do? What’s in your way?  Goal 1: commit in front of peers.  Goal 2: ensure we’re on track to meet our commitments for the sprint.  Not for problem solving Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
  • 34. Scrum of Scrums  Each team sends a representative  Rotate attendance based on whose skills are needed most  Usually 2-3 times per week  Four Questions What has your team done? What will your team do? What’s in your team’s way? What are you about to put in another team’s way?  These are problem solving meetings Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting Scrum of Scrums Meeting
  • 35. Definition of Done  General Definition of Done: the template of development steps that all features should go through, determined by the team and the product owner at the beginning of the cycle.  Typically includes things like:  designed, coded, automated tests created, unit tests created, functional testing completed, unit tests passing, integration testing completed, documented.  Whatever your team agrees that EVERY feature must do to be considered done.  The more mature & disciplined the team, the more complete this list, including things like localization & loc testing complete, security audited, code peer-reviewed, etc.
  • 36. Sprint Review  “Inspect” product  Team presents what was accomplished during the sprint  Typically a demo of new features  Informal No slides Minimal prep  Whole team participates  Invite the world Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting
  • 37. Sprint Retrospective Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting Sprint Retrospectiv e Meeting  “Inspect” process  Periodically take a look at what is and what isn’t working  Can be short, sometimes long  Done after every sprint  Whole team participates
  • 38. Retrospectives & Self Management: A Tale of Three Sprints Sprint 7 Sprint 8 Sprint 9
  • 39. Sprint 8 Retrospective  Team frustrated that work is not getting all done in a sprint  We’ve tried deferring earlier, now what?  Team agreed:  Decompose larger stories into much smaller stories for the next sprint  Each story needs to be testable  Mantra for next sprint planning: “and how will we test this?”  Be very careful with check-ins approaching end of sprint Before: After: Uh Oh! No Problem
  • 40. Team “discovered” TDD, further vertical slicing Sprint 7 Sprint 8 Sprint 9  Sprint 9:  Team broke features down smaller  We could defer small stories at any time  Sprint planning meeting was test driven  Completed all work in the sprint!
  • 41. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 42. Goals of Agile Engineering Techniques  Remove defects as early as possible  Improve code health, eliminate technical debt  Promote collective ownership & understanding  Deliver razor thin slices as frequently as possible  Work at a sustainable pace
  • 43. Agile Engineering Practices  Test Driven Development  Pair Programming  Peer Reviews  Continuous Integration  Automated Acceptance Testing
  • 44. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 45. Example Requirement Requirement 1.05a: The application should automatically save open documents at regular intervals
  • 46. User Stories I want <some function>  User Stories add two pieces of information to a typical requirement:
  • 47. Creating a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.
  • 48. Example Requirement 1.05a: The application should automatically save open documents at regular intervals Why? Who needs this functionality?
  • 49. Create a Product Backlog using User Stories  User Stories: As a <type of user>, I want <some function> so that <some goal>.  Example: Auto-save document
  • 50. Where are the details?  The product owner’s conditions of satisfaction can be added to the back  These are essentially tests
  • 51. Where are the details?  The larger story can be broken into multiple smaller stories
  • 52. Stories, Themes, and Epics User story A description of functionality told from the users perspective Theme A collection of related stories Epic A really big story
  • 53. Ideas for splitting stories  Focus on “vertical slices”  Tracer Bullet  Break into Acceptance Tests/Conditions of Satisfaction  Then turn those into smaller stories  20 ways to split stories  http://xp123.com/xplor/xp0512/
  • 54. Attributes of a good story  Independent  Negotiable  Valuable  Estimatable  Sized Appropriately  Testable  Eliminate as many dependencies as possible  Stories aren’t contracts, leave or imply some flexibility  To users  Plans are based on stories, so we need to estimate  Small enough to work on in a sprint if it’s close to implementation  How will we know it’s done? No partial credit
  • 55. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 56. Agile Planning & Estimation  Goal is always to be accurate  Precision increases as project goes on  Is more focused on planning than the plan  Encourages changes  Results in plans that are easily changed  Is spread throughout the project
  • 57. Estimation accuracy over time X = Time Spent Y = Estimation Accuracy 100% 1 2 3 4 5 6 7 Highest ROI More Certainty, at higher cost
  • 58. Traditional Time Estimates How long will it take to eat all of this candy?
  • 59. Traditional Time Estimates How long will it take to eat all of this candy?  What factors might influence the answer?  Who is doing the work?  Interruptions?  What kind is it?  Motivations?  How tired?
  • 60. Agile Estimates: Relative Size Candy Units = X Candy Units = 3
  • 63. Limiting the set of possible values  We only estimate well within one order of magnitude  Difference between 3 and 6 is obvious, worth discussing  What about 103 and 106?  Limit possibilities to naturally occurring sets of increasing values:  Fibonacci: 1,2,3,5,8,13,21,etc.  Exponential: 1,2,4,8,16,32,etc.
  • 64. Estimating Size in Story Points  Story Points:  The “bigness” of a backlog item  Influenced by how hard it is, how much there is  Unit is arbitrary, but relative  (6 story point item) should be 2x(3 story point item)  Estimate of getting the story “Done”
  • 65. Estimating with Planning Poker  Iterative, team based approach 1. Each estimator has a deck of cards with potential estimates based on set (Fibonacci, etc.) 2. Product Owner reads a backlog item, brief clarifying discussion occurs 3. Estimators choose a card indicating their estimate 4. Cards are revealed all at once 5. Differences are discussed, especially outliers
  • 66. Checkpoint  Foundations of Scrum  High Level Scrum Overview  Roles in Scrum  Sprints and the Definition of Done  Agile Engineering Techniques  Agile Requirements with User Stories  Agile Estimating  Release Planning and tracking
  • 67. Two levels of planning Release Planning Sprint Planning Goal Enable product level decisions such as scope, release date, resources required Enable the scrum team to commit to a specific set of work for a given sprint Led By Product Owner Product Owner + Scrum Team Artifac t Product/Release Backlog Sprint Backlog Items User Stories/Features Tasks Units Story Points Task Hours Units over time Velocity Capacity Don’t confuse the goal, items, or units from one level with the activities of the other!
  • 68. Building a Release Plan  Create Product Backlog  One Line Item – but can be months of work  Product Owner leads  Market Research, positioning, etc.  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20
  • 69. Velocity  Total story points for all product backlog items meeting the definition of done at the end of a sprint  Averaged over time  Three ways to calculate: 1. Based on historical values 2. Ideally after a sprint or two 3. Forecasted when necessary
  • 70. Projecting Velocity when historic values aren’t available Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to 20  Choose a few stories Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I 2  Break down to tasks, estimate Task Hours 128 210 272 225 45 Totals: 41 880  Compare totals to sprint capacity Sprint Capacity = ~900 Hours  Calculate Sprint Capacity Projected Velocity = ~ 42 story points per sprint  Estimate Velocity per sprint
  • 71. Calculating Average Velocity (historic)  Average (30) 0 5 10 15 20 25 30 35 40 45 1 2 3 4 5 6 7 8 9 10 11 Velocity Last 8 sprints  Worst Case (23) Lowest 3  Best Case (38) Highest 3
  • 72. Building a Release Plan  Create Product Backlog  Estimate relative sizes  Determine team velocity Pr i Story Size 1 As an editor, I want a new... 5 2 As a Sys Admin, I need a wa... 8 3 As a novice user, I want a pe... 13 4 As a test engineer, I want to... 13 5 As a pro photographer, I wa... 2 6 As an unregistered user, I ne... 3 7 As a user that never restarts... 8 8 As a developer, I need to ver... 20  Average (30) Sprint 1 26 points May4-May31 Sprint 2 26 points Jun1-Jun28 Sprint 3 30 points Jun29-Jul26 Sprint 4 30 points Jul27-Aug23  Update after each sprint
  • 73. Q&A

Editor's Notes

  • #32: Burndown is how the team knows if they’re on track to reach their commitment
  • #34: Daily inspect and adapt loop
  • #35: Daily inspect and adapt loop
  • #37: Sprint Review = Inspect & Adapt the product Sprint Retrospective = Inspect & Adapt the process
  • #38: Sprint Review = Inspect & Adapt the product Sprint Retrospective = Inspect & Adapt the process
  • #39: These three sprint burndown charts tell a story
  • #41: These three sprint burndown charts tell a story
  • #53: When an Epic’s priority start to rise, it gets broken down into smaller stories The stories that results from this process will likely become a theme It’s ok for items at the bottom of the product backlog to be large epics Items at the top should be broken into smaller and smaller stories as they get closer to implementation.