Agile Frameworks
SCRUM
Embedded Files
3 Day(s)
🎯 LEARNING OBJECTIVES
By the end of this lecture, you will be able to:
Understand the Scrum framework, its principles, and its role in Agile software development.
Explain the Scrum accountabilities: Product Owner, Scrum Master, and Developers.
Understand Scrum events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Identify Scrum artifacts: Product Backlog, Sprint Backlog, and Increment, including their commitments.
Understand how to manage product backlogs, prioritize requirements, and define Sprint Goals.
Explain how Scrum supports iterative delivery, transparency, inspection, and adaptation.
Apply Scrum practices to improve team collaboration, product quality, and continuous delivery.
Recognize common Scrum anti-patterns and implementation challenges.
🧠 PREREQUISITES
Basic understanding of Agile principles and the Agile Manifesto.
Familiarity with software development and the Software Development Life Cycle (SDLC).
Basic understanding of project management and team collaboration.
Awareness of product requirements, user stories, and backlog concepts is beneficial but not mandatory.
AGile Frameworks
Intoroduction
Intoroduction
As agile is a manifesto of values and principles, different frameworks have arised to apply these values from different perspectives, each one cares about a set of agile aspects, like management aspects, engineering aspects, and delivery aspects.
We can highlight the most important frameworks as follows:
1.Scrum Core Process
1.Scrum Core Process
Management Focus framework
Releases Management
Sprints Management
Iterative-time boxed
Daily Startup meetings
Sprint Reviews and approval of the product owner
Retrospectives
Prevent changes during the iteration
Scrum: the team with single objective to achieve, Means : An ordered formation of players
Team Characteristics:
Light-weight
Self-Managed
Cross-Functional
Well-defined roles
Make the team focused on the sprint objectives
Delivery focus
Measures
Velocity
Burn-Up Chart
Burn-Down Chart
2.SCRUM Practices In Depth
2.SCRUM Practices In Depth
Project Planning: Not subject for discussion in Agile
Product Budget planning: Not subject for discussion in Agile
Sprint 0:
Release Planning
Sprint Planning
Sprint Execution
Sprint Review
Sprint Delivery
Sprint Retrospective
Backlog grooming
3.Estimation Approach In SCRUM
3.Estimation Approach In SCRUM
A.Life Before Agile:
A.Life Before Agile:
There were different sizing models, to estimate the size, and the effort accordingly:
FPA (Function point analysis): Build estimation around required functionality, before object oriented analysis phase
UCP (Use case point): Build estimation around resulted use cases
COCOMO & COCOMO II: Cocomo (Constructive Cost Model) is a regression model based on LOC
Delphi: Consensus model
B.Life In Agile:
B.Life In Agile:
You can use the previously mentioned models, but Agile has moved for a new sizing approach called the Poker technique, taken from the Poker cards, which can be described as follows:
Consensus model, as all team members discuss the estimation and approve the approach
Around the reference point: Definition for sizing reference point will be taken to decrease the sizing variance across team members, for example, agreement on the size of login screen, or feedback screen.
Using the Fibonacci series
a series of numbers
Each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, etc.
Why use this approach?
enable the slicing of the stories
C.How to make the reference point clear?
C.How to make the reference point clear?
Select a Baseline Story: Choose a user story everyone understands well., Example: “Login page with username/password validation” = 3 points.
Document Why It’s the Baseline: Note effort, complexity, and risk, and best approach is to use MDA approach for modeling:
Use cases for the functionality
Sequence diagram that will mention objects and expected operations.
Periodically Recalibrate: If team velocity or size changes, revisit the reference.
D.Sizing Meeting:
D.Sizing Meeting:
All the team should share the estimation process
Reference Point for sizing take place
Poker Estimation Technique
Poker Card numbers
Zero
Unknown
Setting limits
Discussion mechanism
PO clarify the user story
Discussion takes place between the Upper estimation and the lower estimation
Map Points detailed estimation: For example, 1 point = 2 Days
E.Estimation using Scrum Poker Application
E.Estimation using Scrum Poker Application
Download scrum poker application
Use Fibonacci model
Each member pick the estimation according to the reference point, hiding the selected number
The anomalies (Upper and lower estimations) should have a public discussion in order to brainstorm the variance
Re-Estimate again, till having consensus between the team
G.Best Practice:
G.Best Practice:
Combine techniques depending on project stage:
Early Phase → T-shirt sizing, affinity
Refinement → Story points, poker
Release Planning → Velocity-based forecasting
Agile = flexible, not one-size-fits-all.
4.Estimation Governance Model
4.Estimation Governance Model
As most of enterprises suffer from the sizing process, in this section we are going to govern the estimation process as following:
A.Scope Definition
A.Scope Definition
Feature-based vs Story-based
Feature-based scope defines what business capability will be delivered, while story-based scope focuses on how it is incrementally implemented. Best practice is to estimate at feature level for predictability, then refine using stories for sprint execution.Scope Governance – 4C
Scope governance ensures estimates are credible and controlled by validating scope against four quality dimensions before sizing.
Completeness
All required functional and non-functional elements are identified. Missing scope is the primary root cause of under-estimation.Consistency
Scope is aligned across business, architecture, and delivery teams. Inconsistencies create rework and invalidate estimates.Correctness
Scope accurately reflects business intent and constraints. Incorrect scope leads to false confidence in delivery dates.Clarity
Scope is unambiguous and measurable. Clear scope reduces interpretation risk and estimation variance.
B. Sizing Approach
B. Sizing Approach
Design-based Sizing
Sizing is anchored to solution design, architecture complexity, and integration points rather than vague requirements. This aligns effort with real technical work.Reuse Engineering Consideration
Ready components reduce effort only when integration, customization, testing, and ownership are explicitly sized. Reuse ≠ zero effort.Non-Functional Consideration
Performance, security, availability, compliance, and scalability must be sized explicitly, as NFRs often consume 30–50% of total effort.
C. Estimation Pitfalls
C. Estimation Pitfalls
Big Sizing Unit (Sprint-Based)
Estimating only in sprints hides true scope size and creates false predictability. Sprint counts are execution metrics, not estimation units.Absence of Dependencies
Ignoring technical, vendor, or organizational dependencies results in optimistic timelines and unmanaged delivery risk.Absence of Assumptions
Unstated assumptions invalidate estimates. Every estimate must have explicit assumptions documented and approved.Ignoring Team Quality
Velocity varies by team capability, stability, and experience. Assuming all teams perform equally leads to systemic estimation errors.Lack of Ownership
Estimates without a clear accountable owner degrade quickly. Ownership ensures estimates are defended, updated, and governed.Eliminate Over-Engineering
Over-design inflates effort without proportional business value. Estimation must reflect fit-for-purpose, not theoretical perfection.
D. Estimation Governance
D. Estimation Governance
Reference Point Sizing
Using historical, proven reference solutions creates calibration and reduces subjectivity across teams and initiatives.Yearly Estimation Defense (Management)
Annual reviews validate strategic assumptions, capacity models, and investment realism at portfolio level.Quarterly Estimation Defense (Management)
Quarterly checkpoints reassess scope changes, risk exposure, and forecast accuracy to prevent drift.Sprint-Based Estimation Defense (Team)
Sprint-level defense validates execution realism, surfaces blockers early, and continuously improves estimation accuracy.
5.Estimation Defense Session
5.Estimation Defense Session
A.Purpose
A.Purpose
Estimation Defense Sessions are structured meetings to validate, challenge, and approve estimates at different levels (Team, Quarter, Year) to ensure transparency, accuracy, and alignment with business priorities.
B.How to Manage:
B.How to Manage:
Agenda-Driven: Define scope, assumptions, dependencies, and sizing upfront.
Role-Based Participation: Product Owner / Business, Technical Lead / Architect, QA, and Delivery Manager.
Reference-Based: Use historical data, complexity points, and previous velocity as objective benchmarks.
Time-Boxed & Facilitated: Keep sessions focused; a neutral facilitator enforces process and fairness.
C.Eliminating Fights / Conflicts:
C.Eliminating Fights / Conflicts:
Facts, not opinions: Always anchor discussions to data and reference points, and be specific to:
Design-based estimation
Assumption-based estimation
Document Assumptions: Every estimate must have clearly stated assumptions to prevent “he said / she said” arguments.
Decision Rights Clear: The session facilitator or assigned owner has the final call if consensus fails.
Use Structured Scoring: For large features, consider weighted complexity scoring to remove subjective debate.
Escalation Path: Open disagreements that cannot be resolved at session level are escalated to Management or Portfolio governance.
D.Outcome:
D.Outcome:
A defended, transparent, and approved estimate with documented rationale, reducing rework, disputes, and scope creep
6.Finding estimation issues: Over/Under
6.Finding estimation issues: Over/Under
Compare planned vs. actual effort: Compare the effort estimated at sprint planning with the actual effort required to complete the work.
Monitor progress during the sprint: Compare the percentage of completed work with the percentage of sprint time elapsed. Significant gaps should trigger investigation.
Compare with historical velocity: Compare the current commitment with the team's average velocity over the previous 3–5 sprints.
Calculate estimate accuracy:
Estimate Accuracy = Actual Effort ÷ Estimated Effort
A ratio consistently below 1.0 may indicate over-estimation.Analyze remaining work: If a large amount of work remains late in the sprint while significant capacity has already been consumed, review whether the original estimates were excessive or whether other factors affected delivery.
Check completed stories: Identify stories that were consistently estimated at high points but completed with significantly less effort than expected.
Look for recurring patterns: One inaccurate estimate is normal. Repeated over-estimation across several sprints indicates a potential estimation problem.
Separate estimation from delivery problems: Low delivery does not automatically mean over-estimation. Check for dependencies, production support, defects, scope changes, technical debt, interruptions, and excessive WIP.
Use tolerance thresholds:
🟢 ≤10% variance — Healthy
🟡 10–20% variance — Investigate
🔴 >20% consistently — Potential estimation/capacity issue
8-Agile Meetings
8-Agile Meetings
A.Backlog grooming
A.Backlog grooming
A recurring Agile meeting to review, refine, prioritize, and clarify items in the product backlog.
Scope:
Clarify backlog items (user stories, bugs, tech tasks)
Break down large items (epics → stories)
Add acceptance criteria
Prioritize based on business value
Estimate effort (if needed)
Remove outdated/irrelevant items
Preparation:
Product Owner prepares a prioritized list of items\
Dev Team reviews items beforehand
Define DoR (Definition of Ready) checklist
Bring previous sprint learnings
Expected Outcomes:
Well-defined, prioritized, and estimated backlog
Stories ready for upcoming sprint planning
Shared understanding across the team
When:
Once per sprint (usually mid-sprint)
Duration: ~30–60 minutes/week (depends on team velocity and backlog size)
B.Sprint readiness
B.Sprint readiness
Ensures enough ready backlog items for the sprint.
Typically happens 1–2 days before sprint planning.
Involves reviewing priority, estimates, acceptance criteria, dependencies.
Confirms alignment with Sprint Goal.
Checks team capacity and velocity.
Uses Definition of Ready (DoR) as a checklist.
Often includes PO, Scrum Master, Tech Lead.
Helps avoid planning delays or surprises.
improvement, and turnover that may lead to potential failure.
C.Sprint planning
C.Sprint planning
🕓 When? : Day 1 of the Sprint (or last day of the previous Sprint)
👥 Who? Entire Scrum Team:
Product Owner
Scrum Master
Development Team
Testing team
🎯 Purpose : Define what will be delivered and how it will be achieved.
📋 What to Cover? 🔍 Review Sprint Goal
Select stories from prioritized, ready backlog
Break stories into tasks
Estimate task effort (if needed)
Clarify acceptance criteria
Confirm team capacity & velocity
Identify risks or blockers
Finalize commitment
⚙️ Output:
Sprint Goal
Sprint Backlog (stories + tasks)
Team commitment
🚫 Avoid:
Unrefined backlog items
Overcommitting beyond capacity
Ambiguous goals
D.Daily standup meeting (Execution Phase)
D.Daily standup meeting (Execution Phase)
🕘 When? Every working day — same time, same place
👥 Who?
- Entire Scrum/Dev Team
- (Optional: Scrum Master, Product Owner as observers)
🎯 Purpose : Ensure team alignment, surface blockers, and track progress
📋 Each Member Answers:
🔄 What did I do yesterday?
🎯 What will I do today?
🚧 Are there any blockers?
⚙️ Meeting Rules:
Keep it time-boxed (≤15 min)
Stand up (to encourage brevity)
Focus on team progress, not problem-solving
Discuss blockers after the standup if needed
📝 Output:
Shared team understanding
Blockers identified early
Adjustments made to stay on track
🚫 Avoid:
Diving into technical discussions
Status reporting to a manager
Skipping the meeting or multitasking
E.Sprint review meeting
E.Sprint review meeting
🕓 When? At the end of the Sprint (before Retrospective)
👥 Who?
Scrum Team
Product Owner
Stakeholders (business, users, sponsors)
Testing team
🎯 Purpose
Demonstrate what was done
Collect feedback
Adapt the Product Backlog
📋 What to Cover?
Review Sprint Goal achievement
Live demo of Done stories
Discuss metrics (velocity, burndown)
Get stakeholder input
Review market/roadmap changes
Identify new backlog items
⚙️ Output:
Updated Product Backlog
Adjusted roadmap or priorities
Shared understanding of product state
🚫 Avoid:
Treating it like a status meeting
Demoing incomplete work
Ignoring stakeholder questions
6- Retrospective meeting
6- Retrospective meeting
The most important meeting from an enterprise perspective in agile is the Retrospective. It is used for :
improving the overall process
Resolving internal communication issues between the team
Resolving external communication issues with customers
Resolving staff issues within the enterprise and resolving cultural issues
Without this meeting and real corrective actions, Enterprise will expect zero growth, zero improvement, and turnover that may lead to potential failure.
Real cases:
Workload distribution is not fair:
Govern distribution according to capabilities, and make proper handover for business
The team exerts more effort to overcome sprint goals and deliver
having a concrete overtime and bonus policy
Dependencies are not considered between SQUADs
Sprint grooming meeting should highlight all dependencies
Once detected, to be shared with relevant SQUADs
Involve management for support
Weekly alignment meeting across SME/TL team members
9-Requirements Management Process
9-Requirements Management Process
A.Requirements types
A.Requirements types
Functional Requirements
Represents the functional requirements that touches the core system functionality to achieve customers objectives.
Example:
Enable Adding/Deducting items from and to store.
Non-Functional requirements
Generic requirements that touch and govern the system behavior within the working environment.
Example:
Response, User friendly, Auditability, Security
Transformation Requirements:
Which support the solution purpose, and the improvement requirements between the old and the new states, whatever these states(system, direction)
Example:
Increase customer productivity 50% than old solution
Sample of Non-Functional Requirements
B.Software Analysis Process
B.Software Analysis Process
From the OOA perspective, the process should be as follow:
Object responsibility
Object configuration
Domain generic attributes
Domain-specific attributes
Object functionalities
Main scenarios
Alternative scenarios
BRM: Business rules management
BPM: Business process management
Object Views
Object states
Sender: What to send to the world
Subscribers: What to listen for from the world
Integration requirements
Cross modules
Third Parties
Reports and visualization
Object Security
Object metadata
Object data
Object characteristics in OOA
Requirements Management ensures that business needs are systematically elicited, validated, analyzed, baselined, traced, and approved before they are handed over to architecture and development.
C.Requirements Planning & Preparation
C.Requirements Planning & Preparation
Review the approved Requirements Elicitation Plan.
Review available business, commercial, and impact-analysis information.
Establish the project landscape and create the EA/Azure DevOps starting point.
Define the system boundary and identify what is inside and outside the solution scope.
Identify related systems, integration points, and organizational dependencies.
Identify the appropriate customer-side business and domain experts.
Primary Role: Product Owner (PO)
Supporting Roles: Business/Customer, Enterprise Architect (EA), Project Manager (PM)
Key Outputs:
Project/EA Start Page
System Boundary
Initial Integration Boundaries
Requirements Sources
D.Requirements Elicitation
D.Requirements Elicitation
The Product Owner works with stakeholders to understand the business problem, expected outcomes, users, and operational context.
Study the business domain, applicable standards, competitors, and comparable solutions.
Identify user personas and their business objectives.
Identify opportunities that can provide additional value beyond existing solutions.
Prepare stakeholder interview questions using appropriate techniques such as:
Pyramid – move from broad questions to detailed questions.
Funnel – start broad and progressively narrow the discussion.
Diamond – expand, narrow, and then expand again to explore alternatives.
Understand the current business/system workflow.
Capture functional requirements.
Capture quantitative non-functional requirements, such as performance, availability, security, usability, and response time.
Capture quantitative digital-transformation requirements.
Primary Role: Product Owner
Supporting Roles: Customer/Business Stakeholders, Scrum Master, Business Analyst, EA
Key Output:
Identified and documented requirements
Initial user stories
Current-state workflow
E.Requirements Documentation & Specification
E.Requirements Documentation & Specification
Requirements are transformed into structured and understandable work products.
Define the required content and documentation format.
Prepare and distribute the approved content through the appropriate project channels.
Document required software and hardware interfaces.
Identify associated product documentation and training requirements.
Define acceptance criteria for requirements and user stories.
Document requirements using the approved repository and project tools.
Primary Roles: PO, Scrum Master
Supporting Roles: Business Analyst, Technical Lead, QC/Test Team
Key Outputs:
Structured User Stories
Acceptance Criteria
Interface Requirements
Supporting Documentation
F.Requirements Traceability & Approval
F.Requirements Traceability & Approval
Requirements must be traceable from business needs through use cases and implementation.
Establish traceability between:
Requirements ↔ Use Cases
Personas ↔ Use Cases
Use Cases ↔ Classes/Objects
Review requirements with the requirement provider/customer.
Obtain formal approval through the agreed mechanism, such as:
Email approval
Meeting Minutes (MOM)
Electronic/signature approval
Store approved requirements in the Enterprise Architect/Azure DevOps repository.
Primary Role: Product Owner
Supporting Roles: Technical Lead, Customer/Requirement Provider, EA
Key Output:
Approved and traceable requirements
G.Requirements Validation
G.Requirements Validation
Validation confirms that requirements are complete, consistent, unambiguous, traceable, and testable.
Review EA models and requirements for quality.
Verify that every formal requirement is traceable to a higher-level requirement.
Identify inconsistencies between requirements and project work products.
Record findings in a deficiency/defect report.
Classify and prioritize identified defects.
Assign defects to the responsible analyst.
Correct the defects and update the affected requirements.
Revalidate the corrections.
Close the defects after successful verification.
Primary Roles: Test Team (TT), Customer, Test Manager (TM)
Supporting Roles: Analyst (AN), Product Owner
Key Outputs:
Defect/Deficiency Report
Corrected Requirements
Validated Requirements
Baselined EA Repository
H.Requirements Analysis
H.Requirements Analysis
Validated requirements are analyzed in sufficient detail to support solution design and implementation.
Examine the solution type and determine the required level of detail.
Refine and classify user stories.
Establish traceability to high-level requirements/use cases.
Group related stories into Epics and Features.
Identify non-functional requirements for each relevant user story, including:
Performance
Response time
Availability
Security
Connectivity
Accessibility
Usability
Establish a common solution glossary for business and technical terminology.
Create BPMN models where business-process analysis is required.
Create use-case models.
Identify system actors and their relationships.
Define for each use case:
Preconditions
Postconditions
Main scenario
Alternative/exception scenarios
Triggers
Primary Role: Product Owner
Supporting Roles: QC, Development Team, Scrum Master, UX
I.UX, Workflow & Solution Modeling
I.UX, Workflow & Solution Modeling
Requirements are further analyzed through visual and behavioral models.
Develop wireframes/prototypes for important scenarios.
Validate wireframes with the testing and implementation teams.
Convert use cases into activity diagrams.
Identify missing or dependent scenarios.
Develop class/data models based on business entities.
Create UI mockups and link UI elements to corresponding use cases.
Apply usability and data-visualization principles.
Define object:
Attributes
Operations
Lifecycle
Filters
Reports
Dashboards
Security requirements
Logging requirements
Integration requirements
Primary Roles: Product Owner, UX
Supporting Roles: QC, Development Team, Technical Lead
Key Outputs:
Wireframes
Use Cases
Activity Diagrams
Class/Data Models
UI Mockups
Object/Feature Models
J.Analytics, Measurement & Reporting Requirements
J.Analytics, Measurement & Reporting Requirements
Where applicable, define analytical and reporting requirements as part of the requirements analysis.
Define measurements at:
Record/instance level
Object level
Relationship level
Cross-object level
Define required:
KPIs
Trends
Comparative reports
Dashboards
Correlations
Forecasting
Analytical models
Define required reporting frequency, such as:
Daily
Weekly
Monthly
Quarterly
Yearly
On-demand
Primary Role: Product Owner
Supporting Roles: Business Stakeholders, Data/BI Team, UX, Development Team
K.Requirements Conflict Resolution
K.Requirements Conflict Resolution
Conflicts must be identified and resolved before requirements are baselined.
Identify requirement-to-requirement conflicts.
Identify conflicts between different users/personas.
Identify missing business rules and scenarios.
Identify requirements that cannot be adequately tested.
Review conflicts with relevant stakeholders.
Negotiate and agree on the appropriate resolution.
Update the requirements and related models.
Communicate the resolution to affected stakeholders.
Primary Role: Product Owner
Supporting Roles: Customer, QC Team, Development Team, Technical Team
Key Principle:
Requirements should be complete, correct, consistent, feasible, unambiguous, and testable.
L. Requirements Baseline & Commitment
L. Requirements Baseline & Commitment
Once requirements have been reviewed and conflicts resolved:
Update all affected requirements and models.
Perform final requirements review.
Baseline the approved requirements and analysis models.
Obtain formal customer/requirement-provider approval.
Obtain implementation-team commitment.
Store the baseline in the approved repository.
Establish change control for subsequent modifications.
Primary Role: Product Owner
Supporting Roles: Customer, Technical Team, QC, Scrum Master, Project Manager
Key Outputs:
Baselined Requirements
Baselined Analysis Models
Customer Approval
Team Commitment
M. Handover to Architecture & Development
M. Handover to Architecture & Development
The approved requirements package becomes the input to the next lifecycle stage.
The baseline should contain, where applicable:
Approved User Stories
Epics and Features
Acceptance Criteria
Use Cases
Personas/Actors
Business Processes
Activity Diagrams
Data/Class Models
UI/Wireframes
Non-Functional Requirements
Integration Requirements
Security Requirements
Reporting & Analytics Requirements
Traceability Matrix
Approved Defects/Resolutions
Customer Approval
Output: Enterprise Architect Repository / Approved Requirements Baseline
Next Process: Architecture & Solution Design.
Roles & Responsibilities
Roles & Responsibilities
Product Owner (PO)
Owns requirements elicitation, analysis, prioritization, clarification, stakeholder alignment and approval
Customer / Business Stakeholder
Provides business needs, validates requirements and approves the baseline
Enterprise Architect (EA)
Supports business/system modeling, boundaries, integrations and architecture traceability
Business Analyst / Analyst (AN)
Analyzes requirements, resolves assigned defects and maintains requirement documentation
Scrum Master
Facilitates the process, supports documentation and team alignment
Technical Lead (TL)
Reviews technical feasibility and requirements-to-solution traceability
UX
Converts requirements into user-centered workflows, wireframes and UI models
QC / Test Team
Validates completeness, testability, missing scenarios, business rules and acceptance criteria
Test Manager (TM)
Manages requirement-validation defects, prioritization, delegation and closure
Development Team
Reviews feasibility, identifies technical conflicts and commits to implementation
Tools
Tools
Enterprise Architect, a CASE tool used by all engineering team members
Microsoft Team Foundation Server
Dr. Ghoniem Lawaty
Tech Evangelist
Page updated
Google Sites
Report abuse