Project Management Process

Scope Engineering In Agile

Introduction

Agile come with new approach of requirements modeling, which called user story, the evolution of text-based requirements.

User Story in Depth

• Format

  • Who: User

  • What : Requirement

  • Why : Objective

• Good User Story:

  • Simple and easy to read, from 3-9 steps

  • No GUI details

  • No data format

  • At User goal level

• User stories problems:

  • Difficult to prioritize

  • Difficult to understand dependency

  • More smaller makes things worse

  • No single repository of artifacts like MDA, that represents the final version of the solution from all perspectives.

  • Upcoming user stories can replace and supersede previous ones

Persona In User stories

• What is? A persona 

  • Persona is a fictional, detailed profile representing a typical user of a product or system. It's based on real user data, behaviors, goals, and pain points.

  • All requirements are driven from the user persona, using the following pillars:

    • Functional requirements: from the persona values, problems, and challenges that they need to resolve.

    • Non-Functional requirements: from the different characteristics:

      • • Expectation of fast service

        • UX design

• Adding Personas to your user stories will enrich your solution requirements, as it focuses on the following areas:

  • Values:

    • • Goals

      • Demographics & background

      • Pain points & needs 

  • Characteristics

    • User behavior

    • Environment & usage context

Requirements Hierarchy

You can classify requirements as follows:

1. Theme

2. Initiative

3. Epic

4. Story

🧭 1. Theme

• Definition: Strategic business objective (broad direction)

• Scope: Company-wide vision or transformation goal

• Example: "Improve customer digital experience"
  
  

🎯 2. Initiative

• Definition: High-level investment to achieve part of the theme

• Scope: Cross-team or multi-epic objective

• Example: "Modernize online payment infrastructure"
  
  

🧩 3. Epic

• Definition: Large body of work requiring multiple sprints or teams

• Scope: Cross-functional development, decomposable into stories

• Example: "Implement new payment gateway API"
  
  

📋 4. Story (User Story)

• Definition: Smallest unit of work delivering user value

• Scope: Fits within a single sprint (2–5 days work)

• Format: “As a [persona], I want [feature], so that [benefit]”

• Example: "As a returning user, I want to save my credit card for faster checkout"

🔁 How it connects in DevOps:

• Theme → Initiative → Epic → Story

• Stories are implemented via CI/CD pipelines and tracked for metrics like lead time, deployment frequency, and change failure rate.

Example:

• Theme: Improve Platform Security

  1. Initiative: Automate Security Compliance

     1. Epic: Integrate SAST (Static Analysis)

        1. Story: Add SAST tool to CI/CD pipeline

        2. Story: Send alerts when vulnerabilities are found

     2. Epic: RBAC Implementation

        1. Story: Define access roles

        2. Story: Audit access logs

✅ Why it matters:

• Ensures strategic alignment across all levels

• Supports scaling Agile (e.g., SAFe, LeSS)

• Enables traceability, prioritization, and continuous delivery

• Clear breakdown from vision to execution

• Reporting, for example if the user request to review all developed stories regarding e-Payment

User Story Slicing Approach

What is User story slicing?

User Story Slicing is the practice of breaking down a large user story (epic or complex feature) into smaller, independent, and valuable stories that can be delivered and tested within a single sprint.

Why We need it?

• The story can’t be completed in a single sprint.

• It lacks a clear Definition of Done (DoD).

• The team struggles with estimating the effort.

• There are dependencies or an unclear scope.

• During backlog refinement or PI/Sprint Planning.

Slicing approaches?

• Scenario-Based

• Persona-Based

• Channel-Based

User story Vs Use cases

As the classification of DevOps can be as following:

1. Theme

2. Initiative

3. Epic

4. Story

But still the user story is totally different from the following as in the opposite graph, user story is functional, sprint focus, and cannot be considered as single repoitory of truth.

Agile Meetings

1. 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)

2. 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.

4. 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:

1. 🔄 What did I do yesterday?

2. 🎯 What will I do today?

3. 🚧 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

5. 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

• 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:

1. Workload distribution is not fair:

• Govern distribution according to capabilities, and make proper handover for business

2. The team exerts more effort to overcome sprint goals and deliver 

• having a concrete overtime and bonus policy

3. 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