Class Ground Rules
Show up on time — respect the timebox
Come prepared for each session
Stay mentally and physically present
Everyone must participate
Attack the problem, not the person
Close decisions and identify action items
Why Product Development Matters
Research shows that 64% of product features are rarely or never used (Standish Group, 2006). Before building anything, teams must ask: Are we building the right things? and Are we building them the right way?
Types of Products Teams Build
- Mobile applications
- Online store applications and websites
- Software enhancements to existing systems
Key Insight
Agile software projects succeed 3× more often than Waterfall projects. Challenged Waterfall projects are typically late by 100%, over budget by 50%, and lack key functionality.
Software Development Life Cycle (SDLC)
SDLC is a process used by the software industry to design, develop, and test high-quality software. It aims to produce a product that meets customer expectations, on time and within budget.
The 7 SDLC Phases
- Phase 1 — Requirement Gathering: Collecting all relevant information from customers, sales, market surveys, and subject matter experts.
- Phase 2 — System Design: Using the BRD/SRS to derive software architecture and define all modules, including UI/UX.
- Phase 3 — Implementation/Coding: Actual development begins; code is generated based on the design.
- Phase 4 — System Testing: Unit testing (developers), Acceptance testing, Regression testing, and UAT (SMEs).
- Phase 5 — Staging: A replica of the production environment used for final testing before go-live.
- Phase 6 — Deployment: Product is formally released to market, sometimes in stages.
- Phase 7 — Operation & Maintenance: Post-deployment support — bug fixes, enhancements, and ongoing IT support.
Waterfall Model
| Waterfall Strengths | Waterfall Deficiencies |
|---|
| Easy to understand and use | All requirements must be known upfront |
| Provides structure for inexperienced staff | Deliverables are frozen — inhibits flexibility |
| Milestones are well understood | Can give a false impression of progress |
| Good for management control | Does not reflect iterative nature of software |
| Works well when quality trumps cost | Integration is one big bang at the end |
| Stable, well-known requirements | Little customer visibility until it may be too late |
When to Use Waterfall
- Requirements are very well known and stable
- Product definition is clear and unlikely to change
- Technology is fully understood by the team
- Porting an existing product to a new platform
The Agile Manifesto — 4 Core Values
The Agile Manifesto (2001) established a set of values that prioritize flexibility, collaboration, and working software over rigid processes and documentation.
We Value...
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Important Note
While there is value in the items on the right (processes, documentation, contracts, plans), Agile teams value the items on the left more. It is not about ignoring the right side entirely.
12 Agile Principles (Key Highlights)
Core Principles
- Satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development — change is a competitive advantage
- Deliver working software frequently — preference for shorter timescales
- Business people and developers must work together daily
- Build projects around motivated individuals and trust them to get the job done
- Working software is the primary measure of progress
- Promote sustainable development — maintain a constant pace
- At regular intervals, the team reflects and adjusts its behavior
Agile vs. Waterfall
| Aspect | Waterfall (Predictive) | Agile/Scrum (Adaptive) |
|---|
| Approach | Linear — phase by phase | Iterative — Sprint by Sprint |
| Requirements | Fixed upfront | Evolve throughout |
| Customer involvement | Beginning and end only | Continuous collaboration |
| Feedback | At final delivery | Every Sprint |
| Risk | Discovered late | Identified and managed early |
| Change | Resisted — expensive | Welcomed and embraced |
What is Scrum?
Scrum is a lightweight framework that helps teams generate value through adaptive solutions for complex problems. It is founded on empiricism — the idea that knowledge comes from experience and decisions should be based on what is actually observed.
Scrum's Three Pillars of Empiricism
- Transparency — Make the work and process visible to everyone involved
- Inspection — Regularly examine progress toward the Sprint Goal
- Adaptation — Adjust the process when inspection reveals problems
The Three Scrum Roles
🎯
Product Owner
Value Maximizer
Accountable for maximizing the value of the product. Manages and orders the Product Backlog. One person — not a committee.
🔄
Scrum Master
Servant Leader
Responsible for establishing Scrum as defined in the Scrum Guide. Coaches the team, removes impediments, and serves the organization.
💻
Developers
Builders
Committed to creating a usable Increment each Sprint. Self-organizing, cross-functional. Team size: 3–9 members.
Product Owner Responsibilities
The PO is accountable for:
- Clearly expressing Product Backlog items
- Ordering the Product Backlog to best achieve goals and mission
- Optimizing the value of the work the Development Team performs
- Ensuring the Product Backlog is visible, transparent, and clear to all
- Ensuring the Development Team understands items to the level needed
Key Rule
The Product Owner is one person, not a committee. For the PO to succeed, the entire organization must respect their decisions. No one can force the team to work from a different set of requirements.
Scrum Master Responsibilities
Serving the Product Owner
- Helping the team understand the need for clear and concise backlog items
- Finding techniques for effective Product Backlog management
- Facilitating Scrum events as requested or needed
- Ensuring the PO knows how to arrange the backlog to maximize value
Serving the Development Team
- Coaching the team in self-organization and cross-functionality
- Helping the team create high-value products
- Removing impediments to the team's progress
- Coaching the team in environments where Scrum is not yet understood
Serving the Organization
- Leading and coaching the organization in its Scrum adoption
- Planning Scrum implementations within the organization
- Causing change that increases the productivity of the Scrum Team
- Working with other Scrum Masters to increase Scrum effectiveness
Remember
The SM owns the process — not the people. The SM owns process improvement, team efficiency, and a passion for Agile principles. They do not assign tasks or manage performance.
Development Team
Team Characteristics
- Self-organizing — no one tells them how to turn backlog into Increments
- Cross-functional — QA, Programmers, UI Designers, Business Analysts, etc.
- No titles — Scrum recognizes no sub-teams or specialist titles within the team
- Size: 3–9 members — small enough to stay nimble, large enough to complete work
- Accountability belongs to the team — not individual members
- Members should be full-time; membership changes only between Sprints
Scrum Events Overview
Scrum has prescribed events to create regularity and minimize unnecessary meetings. All events are time-boxed — they have a maximum duration. The Sprint itself is fixed and cannot be shortened or lengthened.
| Event | Timebox (1-month Sprint) | Input | Output |
|---|
| Sprint |
4 weeks |
Product Backlog Items |
Increment of working software |
| Sprint Planning |
8 hours |
Ranked backlog with acceptance criteria |
Sprint Goal + Sprint Backlog |
| Daily Scrum |
15 minutes |
In-progress tasks |
Updated tasks + impediments raised |
| Sprint Review |
4 hours |
Completed stories demo |
Increment acceptance + feedback |
| Sprint Retrospective |
3 hours |
Scrum Team |
Process improvements + action items |
The Sprint
The heart of Scrum. A Sprint is a fixed time-box of one month or less during which a Done, useable, and potentially releasable product Increment is created. Sprints have consistent durations and run back-to-back with no gaps.
During the Sprint
- No changes that would endanger the Sprint Goal
- Quality goals do not decrease
- Scope may be clarified and re-negotiated between PO and team
Factors for Determining Sprint Length
- Risk appetite — stiff competition may drive shorter Sprints for faster delivery
- Release duration — shorter overall releases benefit from shorter Sprints
- Uncertainty — high uncertainty calls for shorter Sprints and more frequent feedback
Who Decides Sprint Length?
The whole team — Scrum Master, Product Owner, and Developers. If they cannot agree, the Scrum Master makes the call — but a good SM will exhaust collaborative options first.
Sprint Planning
The work to be performed in the Sprint is planned collaboratively by the entire Scrum Team. There are two parts: (1) What can be done? and (2) How are we going to do it?
1
Opening — review team capacity and velocity2
Sprint Goal — define and agree on the Sprint Goal3
Review highest priority Product Backlog items4
Team capacity calculation5
Review stories, identify tasks, confirm estimates6
Identify owners, issues, dependencies, and assumptions7
Team commitment to the Sprint Backlog8
Communication plan and closing
Daily Scrum
A 15-minute time-boxed event held every day of the Sprint at the same time and place. It is an internal meeting for the Development Team — not a status report to management.
The Three Daily Scrum Questions
- What did I do yesterday that helped the team meet the Sprint Goal?
- What will I do today to help the team meet the Sprint Goal?
- Are there any impediments preventing me or the team from meeting the Sprint Goal?
Common Mistake
The Daily Scrum is not a problem-solving session. Issues identified are taken offline after the meeting. The 15 minutes is for inspection and synchronization only.
Sprint Review
Held at the end of the Sprint to inspect the Increment and adapt the Product Backlog. The Scrum Team and stakeholders collaborate on what was done and what to do next.
1
Opening — PO reviews Sprint commitments and Sprint Goal2
Present review data — what was completed and what was not3
Demo accepted user stories — get stakeholder feedback4
Discuss what went well and challenges that arose5
Review current Product Backlog and upcoming priorities6
Review timeline, budget, and next anticipated releases7
Closing — PO or representative
Sprint Retrospective
An opportunity for the Scrum Team to inspect itself and create a plan for improvements in the next Sprint. This is the most important event for the Scrum Master.
The Retrospective Inspects
- People — how did individuals and the team work together?
- Processes — what worked and what needs to change?
- Tools — are we using the right tools effectively?
Key Output
At least one actionable improvement that the team commits to implementing in the next Sprint. The Scrum Master ensures the meeting is positive and productive.
The Three Scrum Artifacts
Product Backlog
- An emergent, ordered list of everything needed to improve the product
- The single source of work for the Scrum Team
- Owned and managed by the Product Owner
- Never complete — evolves as the product and environment evolves
- Higher-ordered items are more refined and have more detail
Sprint Backlog
- The Sprint Goal + selected PBIs + a plan for delivering the Increment
- Owned solely by the Developers — only they can change it during the Sprint
- A highly visible, real-time picture of work planned for the Sprint
- Includes at least one improvement identified in the previous Retrospective
Increment
- The sum of all Product Backlog items completed during a Sprint and all previous Sprints
- Must be in usable condition and meet the Definition of Done
- Must be potentially releasable — the Product Owner decides whether to release it
- Multiple Increments can be created within a single Sprint
User Stories & Requirements
A User Story is a short description of a feature from the end user's perspective. Format: "As a [user type], I want [goal] so that [benefit]."
INVEST Criteria for Good User Stories
- Independent — can be developed and delivered separately
- Negotiable — details are discussed, not set in stone
- Valuable — delivers value to the user or business
- Estimable — the team can estimate the effort required
- Small — fits within a Sprint
- Testable — acceptance criteria can be verified
Definition of Done (DoD)
A formal, shared understanding of what it means for work to be complete. The DoD creates transparency and ensures quality is built in — not inspected in at the end.
Why the DoD Matters
Without a shared Definition of Done, "done" means different things to different people. The DoD prevents technical debt from accumulating and ensures every Increment is truly shippable.
Release Planning
Release planning answers: "When will we be done?" or "Which features can I get by the end of the year?" It must balance customer value and quality against scope, schedule, and budget.
Three Release Planning Options
- Fixed Date — most Agile-friendly. Scope and budget must be flexible.
- Fixed Scope — all features must be delivered; date and cost may vary.
- Fixed Budget — work within a set cost; scope and timeline may flex.
MVP — Minimum Viable Product
- Also called MRF (Minimum Releasable Feature)
- The smallest set of "must have" features for the first release
- Studies show only 34% of features are the most used — identify those first
- Regularly re-evaluate and refine what truly constitutes the MVP
Estimation & Velocity
Story Points
- Relative units of effort — not hours or days
- Account for complexity, risk, and effort combined
- Common scale: Fibonacci (1, 2, 3, 5, 8, 13, 21...)
- Estimated by the Development Team — not the PO or SM
Velocity
- The number of story points completed per Sprint
- Used for forecasting — not as a performance target or comparison tool
- Takes 3–5 Sprints to establish a reliable baseline
- Used to predict how much work can be done in a given timeframe
Capacity Planning
- Based on actual availability of team members for the Sprint
- Accounts for holidays, meetings, training, and part-time availability
- Helps the team commit to a realistic amount of work
Scrum Master vs. Project Manager
| Project Manager | Scrum Master |
|---|
| Manages people using command and control | Facilitates the process |
| Directs the team | Coaches the team to be self-organized |
| Makes the team perform | Creates the environment for the team to perform |
| Gets things done | Empowers the team so they can get things done |
| Monitors the team | Facilitates events |
| Takes on risk management responsibility | Allegiance is to the team — not management |
| Goals: on time, on budget, on scope | Ensures the team follows Agile practices appropriately |
Agile & Scrum Best Practices
Engineering Practices
- TDD (Test Driven Development) — write the test before writing the code
- ATDD / BDD — acceptance and behavioral test driven development
- CI (Continuous Integration) — integrate code changes frequently to the main branch
- CD (Continuous Deployment) — automatically ship every change to production
- Pair Programming — two developers at one workstation; one writes, one reviews
- Swarming — whole team works on one critical item until it is done
- T-Shaped Skills — deep expertise in one area + broad knowledge across others
- Code Review — structured peer review before merging code
- Automation Testing — automated test suites using tools like Selenium
Process Practices
- Backlog Refinement — continuously add detail and estimates to backlog items
- Definition of Done (DoD) — shared quality standard for all Increments
- Definition of Ready (DoR) — minimum criteria before a story enters a Sprint
Kanban
Kanban is a visual workflow method that limits Work In Progress (WIP) to improve flow and identify bottlenecks. It is pull-based — work is pulled when capacity exists, not pushed by assignment.
Kanban vs. Scrum
- Kanban has no fixed iterations — work flows continuously
- Kanban has no prescribed roles (no SM, PO, or Developers)
- WIP limits are central to Kanban; Scrum uses Sprint commitments
- Kanban measures cycle time and lead time; Scrum measures velocity
- Good fit for: operations teams, support, maintenance, and service work
Key Kanban Metrics
- Lead Time — time from request to delivery (includes wait time)
- Cycle Time — time from when work starts to when it is done
- Throughput — number of items completed per time period
- WIP — current number of items in progress at any given time
Career Readiness — Becoming a Scrum Master
Recommended Certifications
- CSM (Certified ScrumMaster) — Scrum Alliance — great entry-level credential
- PSM I (Professional Scrum Master) — Scrum.org — rigorous, highly respected
- CSPO (Certified Scrum Product Owner) — for those pursuing the PO track
- SAFe certifications — for large enterprise Agile environments
Scrum Master Interview — STAR Method
- Situation — describe the context and background
- Task — explain your responsibility in that situation
- Action — describe the specific steps you took
- Result — share the measurable outcome
Tools to Know
Employers hiring for Agile roles commonly use: Jira (sprint boards, backlog, epics), Azure DevOps (ADO) (boards, pipelines, work items), and ServiceNow (ITSM, ticketing, Agile 2.0). Practical exposure to these tools is a strong differentiator.
Question 1 — Agile Manifesto
What does NOT belong to the cornerstones of the Agile Manifesto?
A. Individuals and interactions over processes and tools
B. Working software over comprehensive documentation
C. Processes over people ✓ CORRECT ANSWER
D. Customer collaboration over contract negotiation
E. Responding to change over following a plan
Question 2 — Scrum Events
What is the maximum timebox for a Sprint Retrospective in a one-month Sprint?
A. 1 hour
B. 2 hours
C. 3 hours ✓ CORRECT ANSWER
D. 4 hours
Question 3 — Scrum Roles
Who has the authority to cancel a Sprint?
A. The Scrum Master
B. The Product Owner ✓ CORRECT ANSWER
C. The Development Team
D. The Stakeholders
Question 4 — Scrum Artifacts
Who can change the Sprint Backlog during a Sprint?
A. The Product Owner
B. The Scrum Master
C. Only the Development Team ✓ CORRECT ANSWER
D. Any member of the Scrum Team
Question 5 — Team Size
What is the recommended Development Team size in Scrum?
A. 1–5 members
B. 2–7 members
C. 3–9 members ✓ CORRECT ANSWER
D. 5–15 members
© 2026 MickyMarvels LLC — All rights reserved
Practical Agile Mentoring · mickymarvels.info · +1 (213) 440-2770
