History of AGILE

 The frustrations around seemingly unproductive software development activities, which were shared by
group of software leader, led to the now-famous Snowbird meeting in Utah in early 2001.

 This group included Kern, Extreme Programming pioneers Kent Beck and Ward Cunningham, Arie van
Bennekum, Alistair Cockburn, and twelve others, all well known today in the agile community.

 Jeff Sutherland and Ken Schwarber conceived the scrum process in the early 1990s and published it in
the form of a paper titled "SCRUM Software Development Process.

 Famous Agile Frameworks : Kanban, Scrum, Lean, XP

 The 12 Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
 The 12 Principles behind the Agile Manifesto
7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential. (This idea is central to
eliminating waste)

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
 Important Points in Agile Framework
1. It’s a team work - Driven by all the members, its not the job of just boss or manager

2. Consistently get feedbacks in various ceremonies

3. Feedback has to be applied in next ceremony

4. Be so clear about the roles and responsibilities the each members

5. No uncertainty encouraged
 AGILE TEAM CHARTER
People & Roles (Stakeholders)
CEO Client Testing Team Backend Team Frontend Team Hardware Team Cloud Eng. BA & SM
Rafiq Jafer, Shady, Jagdesan, Arun, Shaheed, Imran, Umar, Ramesh, Prem, Abu Rafeeq
Ahmed Thormozi, Magdi Sheik Abdullah Nadim Ayyub Ammar thalif

Strength & Assets Roles & Activities

Team Values

Conflict
Process
• Dedicated Employees • Client - UI & Frontend
? ? • Server - Admin & Web
• Employees who are
eager to learn new skills. • Server - Database
• Many employees who Purpose • Testing & deployment
are well-wishers of the • Hardware R&D
Communication

company. • • Graphic Design

PM tool : Jira •

Decision
Process
• Devices and application Team Collaboration
• Leaves : ERP (or) Email • • Project Manager
are the assets. Requirements : Client
• Urgent : Whatsapp, Call • Business Analyst
• Resource Flexibility Technology : Devos & CEO
• Scrum : Google Meet • • Product Owner

Weakness & Risks • Some resources has the limited knowledge & experience.
• Small Team – (We are expanding now) • Requirements keeps changing during development / Sprint.
• Working In Multiple Projects Simultaneously. • Hardware R&D Team & Activities are not competitive.
• Dropping the Task in-between due to another important task. • Too much of Bugs in the app, keeping the Devos busy.
(Maybe we need dedicated team for software support)
 BA Stages
Step 1: Gather Background Information.

Step 2: Identify Stakeholders

Step 3: Discover Business Objectives.

Step 4: Evaluate Options.

Step 5: Scope Definition.

Step 6: Business Analyst Delivery Plan.

Step 7: Define Project Requirements.

Step 8: Support Implementation Through SDLC.

 Split big into small user story
How to split user stories?

• WAHZUR
• Workflow steps
• Acceptance Criteria
• Happy / Unhappy path
• Zero / One / Many
• User role / Persona
• Rules
• T Model
• Breadth
• Depth
 Product Backlog

• As described in the Scrum Guide, the Product Backlog is an emergent, ordered list of what is needed to
improve the product. It is the single source of work undertaken by the Scrum Team.

• All Issues such as User-stories, Tasks & bugs has to be added in the product backlog

• All issues in the product backlog should be linked with an Epic.

• Creating and maintaining Product backlog efficiently is the role of product owner

• Product refinement shall be done in case of necessity because its not a mandatory project management
activity
 User Story

• User story has to be in the simplest form.

• It should not contain other new interlinked stories that should be performed before developing the
particular story we are up-to develop. In other words, It should not be able to breakdown further.
otherwise, its just an Epic, not story.

• INVEST Criteria need to be kept in mind while writing an user story

 I - Independent
 N - Negotiable
 V - Valuable
 E - Estimable
 S - Small
 T - Testable

• Definition of Ready (DOR) & Definition of Done (DOD) need to defined in user story
 User Story
Definition of Ready (DOR) Definition of Done (DOD)

The Definition of Ready defines the quality criteria for The Definition of Done (DoD) establishes the quality
the creation of any criteria for delivery of product increment. The DoD is
• User story used to assess when work is complete on the product
• Business epic increment.
• Product (release) theme
Characteristics of the DoD
to ensure that any backlog item being considered for
• Agreed between the team and the product
work is actually ready to be worked on and to be
owner
moved into the next sprint. Specifically, this means
• Applies to all work of the entire team –
that the development team can confidently commit
including user stories and defect resolution i.e.
and complete the backlog item by the end of a sprint.
bug fixes
• Must allow immediate release of product
increment
• Quality increases with maturity, hence the
various elements of the DoD are expected to
become more ambitious over time.
 Unwritten Universal User Story Format
User Requirement:

As a [Type of User]
I want to [Perform some Task]
So that I can [achieve some goal]

Acceptance Criteria: Write as many as possible

Given that [Come Content]

When [Perform some task]
Then [Achieve Some Goal]

Mockup:
Add the design of the page or feature that is drawn manually or designed using tool like Fiqma, Adobe Photoshop, Adobe
XD, Paint, sketch or screenshot.
 Bug - Format
Format
• What is the Issue?
• Example: Lat-Long is not showing
• What is expected?
• Example: It should show the right Lat-Long in-order-to find the location of the vehicle
• What is happening? (or) what is the actual result?
• Example: Lat-Long is highly fluctuated in the application
Extra Information
• Pictorial Representation: add the screenshot screen recorded video and URL of the issue page.
• Note: Eg- This is happening since this morning only.
• Steps to reproduce: Write it step by step to reproduce the scenario in-detail, For example,
• Step 1 : Login MVT app
• Step 2 : Go to Grid View to see the fluctuation in the map.
 Story Point Estimation
• It represents the effort required to put the product backlog item (PBI)

• Story Point Estimation should be done by the one who is going to do the task, not by the assignor.

• Ways to get it
• Can take Avg. from the value give from the number of stockholders in the Agile team
• Fibonacci series can be used in estimation

• Its more of Relative or abstract of the effort rather than time.

• Time is absolute. But Effort is relative with-respect-to man power, tools, skills and etc.
• So the Estimation has to be of relative measurement, not obsolete.

• Don’t use subjective measures, use objective measures

• Subjective measurement has explanation based on self-perception
• Objective measurement has just “yes” or “no”
 Story Point Estimation
• Estimation is not an Oath, as it varies based on the experience as it’s a relative measurement.

• Each Story point has to be discussed in sprint meeting.

• Maximum story point can be 20, if it exceeds, user story has to be spited.

• If the story point is 16-20, then it can take 16.30 hours of effort. (Concluded by experts based on
experience – its also not obsolete)
 Sprint Ceremonies

Investors
Employees
Customers /Clints
suppliers
 Sprint Basics – A Time Boxed Event
• Time duration shall be usually from 1 week to 4 weeks. Ideally its 2 weeks.

• A Sprint has to be delivered on time, irrespective of how many story point has completed.

• The priority has to be set by product owner / Client, inter-related user stories and security of the
application

• Bring the user story into the sprint and create tasks / subtasks in-order-to do the whole phase of the story.
• Example : A User story can have tasks related to various components, Hence subtask need to be
created with workflow and assign to a component.

• Components : A team with different skillset such as UI, Back-end, Designer, Testing, Database.

Dont’s in Sprint Cycle

1) Do not over commit
2) Do not postpone the release date at any cause
3) No new feature can be added during a sprint cycle.
 Sprint Planning (1 hr. for a week Sprint)
1. Members: Product Owner, Scrum Master & Developers

2. Retrospective recap – The outcome of last retrospective meeting need to be applied in this sprint

3. Leaves of members and Holidays need to be considered while planning so that we can reach the goal.

4. Product & Market updates from the product owner

5. Planning conversation = Sprint goal + Velocity

• Sprint Goal is implementing the stories from the backlog
• Velocity is the amount of work typically completed in a sprint

6. At last, Recap the plan, and each person’s action item first

7. Get verbal approval from everyone in the team about their commitment in this sprint
 Daily Scrum – Standup Meeting (15 Mins)
• Everyone has to answer for three questions in scrum meeting
• What did I do yesterday?
• What I am going to do today?
• What is blocking to do that?

• Before go to “Done” section in sprint, It has to be verified by the product owner based on the “Done
Document” or “Acceptance Criteria” in the daily scrum meeting or retrospective meeting.

Dont’s in SRUM

• Do not consume more time, detail discussion should be in sprint meeting or in retrospective meeting.

• Do not Skip or Post-Pone the meeting at any cause, It has to happen on time as planned.
 Sprint Review (1 hr. to 4 hrs.)
• In Sprint Review – Discussion should be about the product release (Technical Issues), such as,

• Discuss What is “done” and what is “not done” in the sprint backlog and analyse why.

• Team demonstrates the work done – Celebrate the team thar worked well

• Team Can ask question to observe the direction of project and next move
• Does it solves the customers problems
• Does it accountable for internal independencies

• Review Key Metrics

• Working Software
• Performance Improvement
• Customer behaviour

• Review the product backlog that influence the next sprint planning meet

• Deployment should be done after Sprint review meeting.

 Retrospective Meeting (30 Mins)
• Retrospective helps run the sprint smother in the feature. (Between Sprint review & Sprint planning)

• The discussion is create a batter culture among team so that they can work without pressure

• The discussion has to be documented in the Confluence and the conclusion has to be in the following
format.
1. Start doing – Use JIRA for all project related communication
2. Stop doing – Do not accept task that is not mentioned in JIRA
3. Keep doing – Document everything including mistakes, learnings, strategy in Confluence

• There are various documentation templates in Confluence application such as Master project doc, 1-2-1
meeting, Brainstorming, Daily stand-up, retrospective meeting, Design sprint & etc.
 Product Backlog Refinement Meeting

• Its not a sprint ceremony but a project management activity

• Usually 10% of development team involves with product owner and scrum master to refine the list of issues
in the product backlog.

• Its not a mandatory event but a best practice based on the project size.
 Requirement Traceability

• Requirements Traceability Matrix is a testing artifact that keeps track of all the user
requirements and the details of the test cases mapped to each of those requirements. It
serves as a documented proof that all the requirements have been accounted for and validated to
achieve their end purpose

• Requirements traceability is the ability to trace a requirement forwards and backwards in the
development lifecycle. Requirements are traced forward through other development artifacts,
including test cases, test runs, and issues.

• Forward traceability, backward traceability matrix and bidirectional traceability are the three
types of requirements for traceability.
Requirement Traceability Matrix (RTM)
 Reports : Sprint, Velocity, Burndown Chart

• If the team fails to finish the task on time, they are over committing

• If there is a sudden drop in the graph. Then the user story is not divided properly as subtask

• Addison of new issue can cause the delay

 Important Jargons

• Technical Dept is the code that gives the temporary solution also called Program Temporary Fix (PTF). The
code need to be refactored after the emergency period to avail a permanent solution.

• Spike is a user story for which the developers or team members has no clue to estimate the story point and
it certainly needs time to do R&D.

• A decision point is a combination of one or more conditions that define the conditions for the various
possibilities in the subsequent system behaviour. The various conditions collectively determine the
outcome of the decision point.