Course Contents

i. Agile Revision
i. Mainfesto, values, Principals and methodologies
of Agile.
ii. Scrum
i. Tineline and Activities
ii. Product backlog & user stories.
iii.Measuring productivity, estimates and due dates
iii.Scrum vs other Agile methodologies.

● What could go wrong? And, How to fix?

 Agile Revision

Mainfesto, values and roles

Waterfall Model
 Waterfall
● Requirements are very ● No working software is
well documented, clear produced until late
and fixed
● Product definition is ● Cannot accommodate
stable changing requirements.
● Works well for smaller
projects where ● Not a good model for
requirements are very complex projects
well understood
● Process and results are
well documented
Project Constrain and why it's
important
 Waterfall problem in 1990s
● There were a frustration in the 1990s because The
enormous time lag between business requirements
(the applications and features customers were
requesting) and the delivery of technology that
answered those needs.
● Many projects were canceled
● Many projects were difficult to be altered.
Agile Manfesto Meeting
Agile Manfesto meeting
 The Four Values of The Agile
Manifesto
● Individuals and interactions over processes and
tools.
● Working software over comprehensive
documentation.
● Customer collaboration over contract
negotiation.
● Responding to change over following a plan.
That is, while there is value in the items on
the right, we value the items on the left more.
 The Twelve Agile Manifesto
Principles
● Customer satisfaction through early and continuous
software delivery
● Accommodate changing requirements throughout
the development process
● Frequent delivery of working software
● Enable face-to-face interactions – Communication is
more successful when development teams are co-
located.
 The Twelve Agile Manifesto
Principles
● Support, trust, and motivate the people involved –
Motivated teams are more likely to deliver their
best work than unhappy teams.
● Self-organizing teams encourage great
architectures, requirements, and designs – Skilled
and motivated team members who have decision-
making power, take ownership, communicate
regularly with other team members, and share
ideas that deliver quality products.
 The Twelve Agile Manifesto
Principles

● Working software is the primary measure of

progress.
● Agile processes to support a consistent development
pace – Teams establish a repeatable and
maintainable speed at which they can deliver
working software
 The Twelve Agile Manifesto
Principles
● Collaboration between the business stakeholders and
developers throughout the project
● Attention to technical detail and design enhances
agility – The right skills and good design ensures the
team can maintain the pace, constantly improve the
product, and sustain change.
 The Twelve Agile Manifesto
Principles
● Simplicity – Develop just enough to get the job
done for right now.
● Regular reflections on how to become more
effective – Self-improvement, process
improvement, advancing skills, and techniques
help team members work more efficiently.
 Agile methodologies
The Agile methodologies outlined below share
much of the same overarching philosophy,
however, each has its own unique mix of practices,
terminology, and tactics.
● Scrum
● Kanban
● Extreme Programming (XP)
 Agile methods differes on
● Roles
● Timeline, due dates
● Measurment of productivity
● Handling changes
● Type of projects fit for.
Agile Team Values
SCRUM Methodology
 Principals
1. Empirical Process Control
2. Self-organization (Shared-Ownership)
3. Collaboration
4. Value-based Prioritization
5. Time-boxing
6. Iterative Development
Time Boxed Sprints
Scrum Aspects
 Traditional software team vs
SCRUM team
● The traditional software team
is organized hierarchically,
with an assigned manager “on
top” and developers
“below.” .
● PM is responsible for
managing every thing!
● Self-Managed Agile teams,
on the other hand, are cross-
functional groups where
“individuals manage their
own workload, shift work
among themselves based on
need and best fit, and
participate in team decision
making.
● Team is fully responsible
with along with PO and
scrum master
Roles
PO Role
Scrum Master Role
 3- The Scrum Team
● Cross-functionality
● Self-organization
● Collaboration
Cross-Functional
Self-organizing
 Collabortaion
● Individuals working together need to be aware of
each other’s work.
● Collaborating individuals must partition work into
units, divide the units among team
● members, and then after the work is done,
reintegrate it.
● Identify risks
● Continous improvments
 Tech vs Business
● Targets , sales, usability, Money ● Code and quality orianted.
orianted ● Projects driven purely by
● Projects driven purely by technical people don't make a
business people, impossible to sustainable business.
implement due to technology
problems.

Stop thinking about “us vs them”

and start building solutions together,
which fulfil the given requirements.
 Confliect resolution
● Win Win
● Listen, understand then
speak out
● Win Lose
● Be imparcial
● Lose Lose
● Consider the other person's
●
Lose Win constrain
●
Smooth and acomodate
● Explain in easy to
understand terms.
● Delay till you think
through.
● Get back to the team.
Scrum Meetings
All is time boxed
 Sprints must have
● A specified goal.
● Set of Product backlog items selected from the product back log
each has acceptance criteria. And the priority of each item
should be known.
● Team with defined Capacity
● Time boxed length.
● Tool to help planing and monitor progress.
Sprint Activities
 Sprint Zero Goals
● Create the project’s skeleton.
● Setting the project environment.
● Develop epics.
● A release plan assigning each epic/stories to a
release.
● Create user stories.
● Epic, feature, user story, task, sub task, technical
user story , bug, and spike.
 Stability sprint / Bug sprints
● A Bug Sprint is a sprint specifically for fixing
bugs and increase stability.
● Needed when velocity in previous sprints are high
and testing is low.
● Bugs and code to be refactore are a technical dept.
 Sprint planning meeting
● It is Timeboxed to eight hours for a one-month
Sprint
● This meeting have two parts:
● Objectives part 50% of time
– Sprint Goal
– User stories
● Capacity and estimate part 50% of time
– Team capacity.
– Tasks estimate.
– Assignment.
 Team Capacity Calculation
The available hours of the Agile team for the upcoming Sprint.
Capacity TFS
Remember ..
● Put time for meetings.
● Put time for week ends, national holidays
and individual vacations and ask team to
menaion any possible planned vacation
ahead.
● Keep focus factor for any thing that can not
be plan. That value can vary 75% to 95%
 Team Velocity
By looking at the amount of work your team completed in previous
sprints, you should be able to estimate how much work they can do
in future sprints. In Agile development, this estimate is known as
sprint velocity.

- Sprint 1: 3 user stories x 8 story points = 24

- Sprint 2: 4 user stories x 8 story points = 32
- Sprint 3: 5 user stories x 8 story points = 40
- Total = 96
So, your average sprint velocity is 96 ÷ 3 = 32
 Sprint planning
1- Objectives of the sprint
● Sprint Goal
● User stories
2- Estimating the capacity of the team.

The team is also responsible for estimating how much time

each member has for Sprint-related work. Most team
member’s days will not be dedicated entirely to Sprint work.
Team capacity = 300 Hours
 Sprint Planning meeting
3- Identify and estimate tasks
the Product Owner and team to work together to break each
item down into individual tasks. Those tasks can then be
assigned an estimated time to complete.
- Tasks capacity can't exceed Team capacity, it's advisable
to leave 10% buffer for risks.
- The Product Owner will play a huge part in helping the
team fully understand each item so that they can break
things up to tasks.
Story takes about 2-3 calendar days (rule of thumb)
 Sprint Planning
4- Task Assignment
Once your team has finalized member availability as well as
the time needed for each task, the team then begins
determining who will complete each item by volunteering.
The final workload of each individual must be reasonable
and fair.
TFS Sprint Planning
Sprint Planning Sheet
Put tasks in KanBan board
 Stand Up meeting
● Select a casual location.
● Make time for appreciation
● Get update about progress
i. What have a recently accomplished?
ii.What are my in-progress tasks and/or plans?
iii.What obstacles are impeding my progress?
 Standup meeting cont

● When there is reported problem:

● Help or communication from PO to explain
feature
● Needed data from the client
● Technical help needed
● Error or a bug without a suspect (Back end /
Mobile) => Separate meeting
 Stand up meeting Cont
● Resource is later than estimate
– Re-assignment
– Negociate cutting stories from his scope
– Any resource idle
– Investigate Reason of the delay
● Some times it could be a good idea to invite
client or other stackholders to attend stand
up meeting, if they wont interrupt the
activities.
 Review Meeting
● Attendees include the Scrum Team and key
stakeholders invited by the Product Owner at the
end of each sprint.
● Goals:
● PO explains what Product Backlog items have
been “Done” and what has not been “Done”.
● Team demonestrates the new features.
● Adapt the Product Backlog, and re-evaluate
priorities on what to do next.
● PO review the timeline and projects delivery
dates based on progress to date (if needed).
 Retrosperct Meeting
● Within a week after a release. Could also held after
each sprint.
● Every retrospective should at a minimum result in a
list of “things that went well” and “things that could
use improvement.”
● Explore every aspect of the project, from locking
in the requirements to coding, Scheduling, resource
allocation, documentation, communication,
testing… they’re all viable topics for the discussion.
 Backlog grooming sessions
● One of the Product Owner’s key responsibilities is
grooming the Prioritized Product Backlog.
● The Product Owner should invite stakeholders
whose feedback is required.
● Goals of Groming sessions:
● Refine requirments into suitable User Stories.
● Reperioritze user stories to match customer
change of prioritues.
● Estimate/re-setimate user stories
– Till sprint planning meeting any item in the
backlog is open for restimate.
Burn down chart
 Agile Revision

Analysis

Epics, Features, User stories,

Technical user stories, spikes ,
Tasks and Sub tasks.
 Software Requirments
Specifications
● Summery ● Large document
● Product Description ● Extreamed detailed
● Functional upfront
Requirments ● Big upfront
● Non functional commitment
requirments
 Product Backlog
● Set of simple requirments (user stories)
● Periotitized
● Continous customer collaboration
Hirarchy of Backlog
 Theme
A theme is a goal or an
abjective that is
correspond to a group
of business value that
customers can
understand.
 Epic
● larger bodies of work (than tasks and stories),
which can be the building blocks of themes.
● is a collection of multiple tasks or user stories. It
is responsible for producing a major deliverable.
● A large user story that we need to break down
further.
 A User Story is ...
● Valuable
Reprisents one new feature.
● Deployable / Shipable
● Testable
● Estimatable
● Small
For a 2 week sprint, it's better if every story can be completed in 1 to 3
days.
● CCC
Card, Conversation, Confirmation.
Writing a good user story
Acceptance criteria
 Very simple User story
● As a User I want to see a newspage to read the latest
news.
● What could Go wrong :D
● Possible Design damage by missing images
● Possible security vulenrability by showing a maleware/malisious file
● Possible Null exception if no news yet
● Possible exception number of news less than number of items per
page.
● Possible Null exception if a news item is entered in approriatly (empty
title or empty summery)
● Possible random error that is totally not your fault yet annoy the user.
 Acceptance criteria example
● A user should see:
● Latest 10 (or less) saved news items (Order DEC by date)
● Each news item has : - A thumnail
- Type JPG, Exact dimension (50 x 50)
- Size 100 KB or less.
- a summery (max 150 characters)
● Edge Cases:
● If a news item dosn't have an image, a default image should be loaded.
● If saved image with incorrect size, mime type or dimension, the default
image should be loaded
● if no news in DB, Error Message M20 should appear
● If saved news items are less than 10 show them.
● if Message is more than 150 charactersTruncate summery.
● If summery is Null/empty don't show this news item.
● If unknown error appear, show message to refresh page and try again.
● If a news item dosn't have an image, a default image should be loaded.

Possible Design damage by missing images

● If saved image with incorrect size, mime type or dimension, the default
image should be loaded
Possible security vulenrability
● if no news in DB, Error Message M20 should appear
Possible Null exception
● If saved news items are less than 10 show them.
Possible exception
● If summery is Null/empty don't show this news item
Possible Null exception
● If unknown error appear, show message to refresh page and try again.
Possible random error that cause company to complain.
Splitting and Combining user stories.
 Splitting user stories
● To deploy faster and be able to delay some of the
work for later.
● For better analysis, focus, negociation, testing and
estimate
● How?
● At mixed priorites acceptance criteria
● At Cross cutting concern
● Separating needed performance optimizations
as separate user stories
 Are all acceptance criteria with
same priroity?
● If yes then all of them should be done
● If no, you have a mixed priorities in same user
story
● you can separate the lower priority
acceptance criteria to another user story in
a future release if you need time.
 Mixed Priorities example
● To simplify, If there is a need to show along with
the news a pagger to pagginate to old news it
could be a part of the same user story or split it to
a new user story
● As a user I need to pagginate the news to check
old news.
 Cross cutting concern separation
● An acceptance criteria that is needed in many user
stories. So it need to be separated as a user story
to decrease development time
● Examples :
● Rondom error handler
● Checking that a certain access being done by
authenticated access.
 Splitting user stories for
Performance optimization
● Behind the scene stories that require more
optimization.
● As A user I want to see the news
● As A user I want to see the news in less than 30
seconds.
 Spikes
● a spike is a story that cannot be estimated until a
development team runs a time-boxed
investigation. The output of a spike is an estimate
for the original story.
● Spikes represents risks, so it's good to do them
early on in the release and be resolved quickly.
Technical user stories what, when
and how?
● A Technical User Story is one focused on non-
functional support of a system.
● Dosn't add new behaviour
● Infrastructure stories
● For example, implementing back-end skilliton,
performance optimization or needed code refactor
for a module.
● No need a standerd formats, just write them in plain
english.
Technical user stories what, when
and how?
● Usually forgotten while planing or backlog
gromming sessions.
● Stack holders usually gravitate toward
functionality first
● No demo
 Combining user stories
● Work needed in same itration
● User stories very related
● Each are very easy to be implemented by the team
● Forgot password and reset password
combining
● Login and Logout
 Game with prizes
Guess The edge cases like a detective
 Round No 1

As a Manger I want recieve a daily sales report

by email to monitor my sales progress.
 Acceptance Criteria
● The report should be in PDF format
● The report should be sent to Manger's email
with subject M20 and Message M21
● The report should be sent from
● The report should include all sales done in
the sent date. Needed columns:
OrderId, Date, Package name, price,
Customer Country and Customer name
Guess Edge cases
 Edge cases
● If no sales this day no email should be sent.
● If email server error, an SMS should be sent to
admin.
● All sent email should be logged in daily log file
with sent date.
● If customer name or any other report field
contains latin characters it should be correctly
encoded in the pdf report.
 - Theme: Having HQ Movies Reviews
articles To increase user involvment
● Epic ● As a content owner I
should see all my drafts to
As a Marketing Lead, I edit or delete one of them
want to have a content ● As a Content Owner, I
management system so want to be able to create
that I can manage and content to provide
provide quality content information.
to users. ● As an Editor, I want to
review assigned content
.
before it is published so
that I can assure it is
optimized.
 Round 2

As a Content Owner, I want to be able to create content

to provide information..
 Acceptance Criteria
●Users should be logged in as Content owners
to post a new content
●User should be able to add title, summery and

body of the new content

●User should save draft for later.

●User should assign his content to an editor for

review.
●Each content should belong to one Content

owner and be assigned to a single one editor.

 Edge cases
● Only admins and content owners can create
content. If anaymous user or a logged in user with
different role tries to post a content he should get
403 messge M20
● If content owner posts an article with empty title,
summery or body he should recieve message M21
● If no editors in system the Assign drop down
menu should be disabled.
● When clicking assign without selecting an Auther
M22 should be recieved.
 Round 3
● As A user I want to reset my password to enter
my account if I forgot my password.
 Acceptance criteria
● User should click on a 'Forgot Password' link in the login
page.
● In the forgot screen user should enter his saved email address
correctly first to recieve a Message M10 on screen and a reset
password email should be sent to this saved email address.
● The reset password email should has subject M15 , and body
M16 and sent from email address ---------
● The email should contain a reset link with a secure token that
is valid for 60 minutes.
● The reset link should redirect the user to reset page to enter a
new strong password twice (containig at least one uppercase,
one digit and length between 8 and 16 chars)
● After reset user should be recieve a confirmation M11.
 Edge Cases
● If user enters wrong email address he should get
M12 message.
● If email server gets an error it should send SMS to
admin
● If token is expired or not correct user should get
error message M13.
● If new password is not strong user should get
M14
 Q & A about Scrum

Agile is not a set of practices; this is a frame of

mind.
What could go wrong when applying scrum?

Top 12 Problems
What could go wrong with SCRUM
1- Too little flexibility
Agile projects often fall down because of rigid
procurement practices. A large organization will
appoint a supplier to deliver an agile project, but
with a contract that ties them to fixed
deliverables.
● You have to have contracts allowing Agile.
 2- Lack of support from the top
“An urgent problem or request crops up and
everyone is forced to scatter like ants.”“Too often
management either doesn’t understand or doesn’t
care about the constraints required of agile.

● You have to make big efforts in conviencing Top

managment with Agile and get them included.
 3- Incomplete User stories
Often when teams sit down to complete estimates
for the upcoming sprints, user stories are
incomplete. This results in the inability to
properly estimate, the likelihood of scope creep,
and an inability to deliver what was originally
planned.
● Good PO is a must & Get them certified if
possible
● Missing Acceptance criteria or Edge cases is a
future bug.
 4- Agile ≠ Scrum

● Many people believe that Scrum equals Agile.

But Scrum is a framework for managing a project,
while Agile is a philosophy based on certain
principles. And Scrum is only one of many
methodologies built on agile principles.
 5- Forgetting about modelling and design
● One of the Agile principle says “favouring
working software over documentation”, so it
might be tempting to skip all modelling and
design activities and only write code. But because
you’re doing agile, it doesn’t mean you “can’t”
model or design. Just the other way round – when
you’re trying to solve a really hard problem, all
means are important to figure out the right
solution.
 6- No communication between technical and
business
The client needs to be able to communicate with
you and your teams on a constant basis.
● Agile depends on close, frequent interaction with
the customer.
7- No capacity / velocity planning.
Not measuring team velocity and estimating its
capacity may end up having burned or idle teams.
It's problematic in eaither ways.
 8- No risk control
Risk Controls – If you don’t employ some risk
management techniques within your agile
development, you will have problems.
● You need to identify and mitigate risks a head
with each sprint / release planning.
● Have planned spikes , use pear programming at
difficult tasks, consult experts
 What could goes wrong
9- No Product Roadmap
● RoadMap is a strategic tool which shows how the
product is expected to grow in phases (over time
and across a number of major releases).
● Scrum artifacts are Product backlog, sprint
backlog and Product Roadmap.
● Template for roadmap :
https://slideuplifts.medium.com/creative-ready-to-use-p
 What could goes wrong
10- Poor product back log
● Backlog is not dynamic.
● Back log is not a living refrence.
● No product backlog grooming / refinemnt
sessions.
● Product backlog is not orderd correctly.
Holding backlog refinement / grooming meetings
ensures it happens regularly and it provides
another opportunity for the entire Scrum Team to
discuss the issues.
 What could goes wrong
11- No retrospective meetings.
Feedback about the process remains hidden.
12- Micromanagment and lack of transperancy.
Self-Managed team that is shared responsability is
a core Agile proncipale. Doing Micromanagment
or not sharing necessary information about project
vison and growth plan with team prevents this
from happening.
Other Agile Methodologies
2- XP
 XP
● XP is Scrum with technical practices. It’s
mindset/behavior and a more prescriptive
approach with a strong feedback loop.
● The iterations are 1-2 weeks or less.
● You can combine Scrum + XP
Any Scrum team can make its work more
effective by implementing some XP practices.
 XP Engineering practices
● Code Refactoring
● Collective ownership of code
● TDD and automated testing
● Pair programming
● Small Releases with MVP first
● Simple design
● System Metaphor
 Scrum Vs XP
● The iteration is between 2 to 4 weeks. The
iterations are 1-2 weeks or less. For very
aggressive teams, it can go up to a day.
● In scrumChanges in the sprint are not allowed.
whileXP Teams are much more amenable to
change within their iterations, but change can
only be made if the team hasn’t started working
on a feature and at the same time the change is of
the equivalent of the swapped item.

●
 Scrum Vs XP
● In scrumThe testing of the software is completed
almost at the end of each sprint, (i.e. Sprint
Review) while in XP The software needs to be
validated at all times, to the extent that the tests
are written prior to the actual software. TDD
● Scrum doesn’t prescribe any engineering practices
while XP does.
● The Scrum Master is responsible for what is done
in the Sprint, including the code that is written A
developer can modify or refactor the parts of the
code as and when the need arises.
 Roles in XP
● A typical XP team includes six roles.
● The customer is the person who is responsible for
writing user stories, setting priorities and
formulating the product backlog.
● The programmer is an ordinary developer, who
writes the code and performs the entire amount of
project tasks.
● The coach is the person who watches the team’s
work, controls it, and teaches its members to
implement the most effective practices.
●
 Roles in XP
● The tracker is the person whose main task is to
monitor the progress of software development and
to detect all problems in it.
● The tester is the team member responsible for
product testing. The quality of the final product
strongly depends on his work.
● The doomsayer is the person who tracks the
project risks and warns the team about them.
Compirisons
Other Agile Methodologies

3- KanBan
 KanBan Improve Flexibility

Kanban respects your organization's current state,

and it doesn’t require revolutionary changes. On the
contrary, it suggests that you should pursue
incremental, evolutionary change and continuously
improve.
Comprison
KanBan Practices
1-Visualize work flow
 Visualize work flow
● Kanban reveals bottlenecks in your workflow
● Once you build a Kanban board and you fill it
with cards, you will see that some columns will
get overcrowded with tasks. This will help you
spotlight bottlenecks in your workflow and tackle
them properly.
 2- WIP Limit
- WIP is the number of task items that a team is
currently working on.

-Limiting WIP means implementing a pull

system on parts or the complete workflow.
Setting maximum items per stage ensures that
a card is only “pulled” into the next step when
there is available capacity.
 2- WIP
● WIP limits allows you to complete single work
items faster by helping your team focus only on
current tasks.
● In a team of two, installing a limit on work in
progress of one task per person would prevent
context-switching and immediately reveal the
difference in throughput rates
 2-WIP
● WIP limits should not be exceeded at any cost
unless there is an urgent task that needs to be
considered the highest priority.
Measuring cycle time
 3- Managing Flow
● One of the main goals when implementing a
Kanban system is to create a smooth, healthy
flow. Instead of micro-managing people and
trying to keep them busy all the time
 4. Feedback Loops
● An example of a feedback loop is the daily stand
up meeting for team synchronization. It takes
place in front of the Kanban board, and every
member tells the others what they did the
previous day and what they will be doing today.