The first three sessions of the Agile course. Covering Agile, scrum,

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

2. Agile Revision
Mainfesto, values and roles

3. Waterfall Model

4. Waterfall
● Requirements are very
well documented, clear
and fixed
● Product definition is
stable
● Works well for smaller
projects where
requirements are very
well understood
● Process and results are
well documented
● No working software is
produced until late
● Cannot accommodate
changing requirements.
● Not a good model for
complex projects

5. Project Constrain and why it's
important

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

7. Agile Manfesto Meeting

8. Agile Manfesto meeting

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

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

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

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

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

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

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

16. Agile methods differes on
● Roles
● Timeline, due dates
● Measurment of productivity
● Handling changes
● Type of projects fit for.

17. Agile Team Values

18. SCRUM Methodology

19. Principals
1. Empirical Process Control
2. Self-organization (Shared-Ownership)
3. Collaboration
4. Value-based Prioritization
5. Time-boxing
6. Iterative Development

23. Time Boxed Sprints

24. Scrum Aspects

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

26. Roles

27. PO Role

28. Scrum Master Role

29. 3- The Scrum Team
● Cross-functionality
● Self-organization
● Collaboration

30. Cross-Functional

31. Self-organizing

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

34. Tech vs Business
● Targets , sales, usability, Money
orianted
● Projects driven purely by
business people, impossible to
implement due to technology
problems.
● Code and quality orianted.
● Projects driven purely by
technical people don't make a
sustainable business.
Stop thinking about “us vs them”
and start building solutions together,
which fulfil the given requirements.

35. Confliect resolution
● Win Win
● Win Lose
● Lose Lose
●
Lose Win
● Listen, understand then
speak out
● Be imparcial
● Consider the other person's
constrain
●
Smooth and acomodate
● Explain in easy to
understand terms.
● Delay till you think
through.
● Get back to the team.

36. Scrum Meetings

37. All is time boxed

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

39. Sprint Activities

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

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

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

43. Team Capacity Calculation
The available hours of the Agile team for the upcoming Sprint.

44. Capacity TFS

45. 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%

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

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

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

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

50. TFS Sprint Planning

51. Sprint Planning Sheet

52. Put tasks in KanBan board

53. 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?

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

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

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

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

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

59. Burn down chart

60. Agile Revision
Analysis
Epics, Features, User stories,
Technical user stories, spikes ,
Tasks and Sub tasks.

61. Software Requirments
Specifications
● Summery
● Product Description
● Functional
Requirments
● Non functional
requirments
● Large document
● Extreamed detailed
upfront
● Big upfront
commitment

62. Product Backlog
● Set of simple requirments (user stories)
● Periotitized
● Continous customer collaboration

63. Hirarchy of Backlog

64. Theme
A theme is a goal or an
abjective that is
correspond to a group
of business value that
customers can
understand.

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

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

67. Writing a good user story

68. Acceptance criteria

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

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

71. ● 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.

72. Splitting and Combining user stories.

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

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

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

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

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

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

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

80. Technical user stories what, when
and how?
● Usually forgotten while planing or backlog
gromming sessions.
● Stack holders usually gravitate toward
functionality first
● No demo

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

82. What could goes wrong? And, How to fix?

83. Flexibility Vs Pushing back
● Both are very important skills
● When saying No:
● Don't be aggressive, and understand
● Search for possible alternatives
● Identify the risk and provide a logical explination
why not. Please focus on product interest and
what could goes wrong.
– Decrease quality
– Decrease security
– Less focused sprints therefore more time

84. Agile Project Managment