1
00:00:01,015 --> 00:00:04,364
Now, let's go over some key concepts
and terms that are used in Agile.

2
00:00:04,881 --> 00:00:06,722
Let's start with user stories.

3
00:00:07,497 --> 00:00:11,540
User stories are basically product
features, requirements or tasks

4
00:00:11,616 --> 00:00:13,604
that add value to the end customer.

5
00:00:14,141 --> 00:00:16,792
And by adding value, I mean
that whatever it is

6
00:00:16,880 --> 00:00:19,912
it's something that the end
customer would actually pay for

7
00:00:20,225 --> 00:00:22,786
or they would find really
valuable and important.

8
00:00:23,490 --> 00:00:25,775
If something doesn't add
value to the customer

9
00:00:26,128 --> 00:00:29,143
then it can't be considered a
user story and should remain

10
00:00:29,219 --> 00:00:31,404
a task, sub-task or requirement.

11
00:00:32,149 --> 00:00:35,994
User stories are written in a specific
format which you can see on screen.

12
00:00:36,670 --> 00:00:39,099
For example, as a customer

13
00:00:39,381 --> 00:00:42,365
I want to be able to use my
Facebook login credentials

14
00:00:42,661 --> 00:00:44,559
to log in to the eCommerce website

15
00:00:44,883 --> 00:00:46,760
so that I don't have to
create a new account.

16
00:00:47,208 --> 00:00:50,713
As you can see, this user story
provides value to the customer

17
00:00:51,056 --> 00:00:54,033
since it helps him avoid creating
a new user and passwords

18
00:00:54,398 --> 00:00:56,268
hence, saving him time.

19
00:00:56,611 --> 00:01:01,611
So, in Agile, we create user stories for
all project requirements and features

20
00:01:02,012 --> 00:01:04,782
that add value to the
customer and then

21
00:01:04,949 --> 00:01:07,282
we add them to what we
call the product backlog.

22
00:01:07,843 --> 00:01:10,024
The product backlog
basically contains

23
00:01:10,100 --> 00:01:12,659
all the user stories that
will be part of the project

24
00:01:13,047 --> 00:01:16,253
but of course in Agile,
that can be a changing list

25
00:01:16,606 --> 00:01:20,228
since you might start with say
50 user stories and overtime

26
00:01:20,451 --> 00:01:24,586
add 50 more. How many you add
or remove will depend on

27
00:01:24,662 --> 00:01:27,412
what you and your team
define throughout execution

28
00:01:27,703 --> 00:01:30,729
and you have the flexibility
and autonomy to define that.

29
00:01:31,468 --> 00:01:33,571
Now, the sprint backlog
is just taking

30
00:01:33,647 --> 00:01:36,199
a couple of user stories
from your product backlog

31
00:01:36,434 --> 00:01:38,019
and adding them your sprint

32
00:01:38,505 --> 00:01:41,686
and committing to the delivery of
those user stories in that sprint.

33
00:01:42,638 --> 00:01:46,634
So basically, it's the amount of work
you will do in those two weeks.

34
00:01:47,314 --> 00:01:50,413
Remember that in Agile, sprints
generally last two weeks

35
00:01:50,741 --> 00:01:52,700
but you can make them
three or four weeks

36
00:01:52,871 --> 00:01:55,656
if you and your team define
that is what is best for you.

37
00:01:56,237 --> 00:01:58,294
From experience, I
recommend two weeks

38
00:01:58,500 --> 00:02:00,680
but like I said, that
is not mandatory.

39
00:02:01,255 --> 00:02:03,012
And finally, the story points.

40
00:02:03,576 --> 00:02:07,944
The story points simply denote the
level of complexity a user story has.

41
00:02:08,569 --> 00:02:11,902
So you assign story points to
each user story you create.

42
00:02:12,421 --> 00:02:15,421
Personally, I'm a big advocate
of keeping things simple.

43
00:02:15,979 --> 00:02:20,562
So generally, I would recommend using a
basic scale of one, three and five.

44
00:02:21,238 --> 00:02:22,692
One being low complexity

45
00:02:23,064 --> 00:02:26,846
three being medium complexity
and five being high complexity.

46
00:02:27,537 --> 00:02:29,400
Now, don't worry too
much about spending

47
00:02:29,476 --> 00:02:31,582
a lot of time estimating
your story points,

48
00:02:31,917 --> 00:02:34,086
keep it simple, follow your instinct

49
00:02:34,301 --> 00:02:35,975
experience and gut feeling.

50
00:02:36,685 --> 00:02:38,957
How many story points is
something you can add

51
00:02:39,033 --> 00:02:40,632
to each user story as a team

52
00:02:41,101 --> 00:02:44,550
or you can also ask the person
working on the user story

53
00:02:44,764 --> 00:02:47,669
what level of complexity
they consider it has.

54
00:02:48,361 --> 00:02:51,358
The scale I have just suggested
is just an example of course.

55
00:02:51,813 --> 00:02:56,132
You can create your own scale or use
existing scales such as fibonacci.

56
00:02:56,824 --> 00:02:59,843
Discuss with your team what scale
they want to use and use it

57
00:03:00,495 --> 00:03:03,094
and if it doesn't work well
after you finish the sprint

58
00:03:03,170 --> 00:03:04,929
you'll have the opportunity
to discuss that

59
00:03:05,068 --> 00:03:08,167
in your team's retrospective
or lessons learned session

60
00:03:08,646 --> 00:03:11,082
and you can then adjust as required.

61
00:03:11,315 --> 00:03:12,871
If you want to keep it simple

62
00:03:13,063 --> 00:03:16,140
then follow my recommendation
of one, three and five.

63
00:03:16,933 --> 00:03:19,099
Now, let's go over the
concept of velocity.

64
00:03:19,738 --> 00:03:23,127
Do you remember I said that velocity
relates to the speed of execution?

65
00:03:23,798 --> 00:03:26,433
Well, basically the velocity
of an Agile project

66
00:03:26,509 --> 00:03:29,936
is the number of story points the
team delivers over a sprint.

67
00:03:30,574 --> 00:03:31,574
I'll repeat that.

68
00:03:32,036 --> 00:03:35,873
The velocity of an Agile project
is the number of story points

69
00:03:35,981 --> 00:03:37,794
the team delivers over a sprint.

70
00:03:38,186 --> 00:03:40,595
And of course, you will see
variations of that

71
00:03:41,120 --> 00:03:43,390
especially at the beginning
when you are just learning

72
00:03:43,466 --> 00:03:47,009
how many user stories you are
actually able to deliver as a team.

73
00:03:47,544 --> 00:03:49,656
So at the beginning,
you are kind of guessing

74
00:03:49,827 --> 00:03:53,204
or estimating how many story
points you can deliver in a sprint

75
00:03:53,772 --> 00:03:55,841
but after a couple of sprints

76
00:03:55,917 --> 00:03:58,523
you will be able to average
the number of story points

77
00:03:58,722 --> 00:04:01,287
and then conclude for
example that on average

78
00:04:01,363 --> 00:04:04,969
your team is able to deliver
20 story points per sprint

79
00:04:05,528 --> 00:04:07,005
and that is your velocity.

80
00:04:07,638 --> 00:04:11,066
You will always be able to calculate
your velocity at the end of your sprint

81
00:04:11,608 --> 00:04:16,072
once you have reviewed what you
delivered versus what you had planned.

82
00:04:16,623 --> 00:04:19,487
Your velocity is not
what you had planned

83
00:04:19,563 --> 00:04:21,063
or what you thought
you would deliver.

84
00:04:21,634 --> 00:04:24,447
It's what you actually
delivered in story points.

85
00:04:25,527 --> 00:04:29,280
Swimlanes are a visual representation
of the status of stories

86
00:04:29,356 --> 00:04:30,938
on the Agile kanban board.

87
00:04:31,691 --> 00:04:33,721
But that is better
understood with an example

88
00:04:33,797 --> 00:04:36,399
and a visual than by me
explaining it with words.

89
00:04:36,863 --> 00:04:39,928
So don't worry, I'll add the link
in your lecture resources

90
00:04:40,004 --> 00:04:42,341
so you can check what
swimlanes look like

91
00:04:42,719 --> 00:04:43,907
and how you can use them.

92
00:04:44,623 --> 00:04:47,497
Now, let's switch to one of
my favorite concepts in Agile

93
00:04:47,818 --> 00:04:52,818
the MVP and no, this does not
stand for Most Valuable Player.

94
00:04:53,513 --> 00:04:57,691
In Agile, MVP stands for
Minimum Viable Product

95
00:04:58,586 --> 00:05:01,965
and basically, it means the
bare minimum you can deliver

96
00:05:02,041 --> 00:05:04,006
to meet your customers'
expectations.

97
00:05:04,923 --> 00:05:07,669
So if you think about the example
we saw earlier on the course,

98
00:05:08,006 --> 00:05:11,891
the MVP is the skateboard
not the Ferrari.

99
00:05:12,534 --> 00:05:15,342
And this is really powerful
because this will allow you

100
00:05:15,418 --> 00:05:17,187
to deliver quickly and often

101
00:05:17,776 --> 00:05:21,646
and iterate and build up and
enhance your solution over time.

102
00:05:22,291 --> 00:05:24,414
This is a key Agile principle.

103
00:05:25,504 --> 00:05:29,350
A release as the name implies is
when you move your user stories

104
00:05:29,426 --> 00:05:30,641
to a production environment

105
00:05:31,617 --> 00:05:32,834
so, when you make them live.

106
00:05:33,352 --> 00:05:37,065
Generally, Agile teams make
releases to production once a month

107
00:05:37,458 --> 00:05:38,629
so after two sprints

108
00:05:39,093 --> 00:05:42,840
but, you might find some Agile teams
making releases to production

109
00:05:42,916 --> 00:05:44,624
every four sprints and not two

110
00:05:44,959 --> 00:05:46,189
so, every two months.

111
00:05:46,871 --> 00:05:49,771
At the end of the day, that is
for the project team to decide

112
00:05:50,136 --> 00:05:54,053
but remember, Agile is about doing
things quickly and efficiently

113
00:05:54,307 --> 00:05:55,728
so the shorter, the better

114
00:05:56,270 --> 00:05:57,781
but don't push it too much.

115
00:05:57,988 --> 00:05:59,877
Be careful with exaggerating.

116
00:06:00,322 --> 00:06:03,760
Try to keep a good balance and releases
that keep the team comfortable.

117
00:06:04,486 --> 00:06:06,137
And finally, the sprint.

118
00:06:06,724 --> 00:06:09,471
By now, you're already familiar
with what a sprint means

119
00:06:10,090 --> 00:06:11,388
but let's recap anyway.

120
00:06:11,838 --> 00:06:14,703
A sprint is a period of
time over which a team

121
00:06:14,779 --> 00:06:16,657
will deliver a set of user stories.

122
00:06:17,307 --> 00:06:19,764
Generally, sprints last two weeks

123
00:06:20,088 --> 00:06:24,178
but some teams may have their
sprints set up for three or four weeks

124
00:06:24,535 --> 00:06:25,535
and that's okay.

125
00:06:26,086 --> 00:06:29,281
You need to define what works
best for you and your team

126
00:06:29,496 --> 00:06:32,400
given your specific context
and project dynamics

127
00:06:33,062 --> 00:06:36,008
but, if you aren't sure,
start with two weeks

128
00:06:36,084 --> 00:06:38,800
and then change that to
three or four if required.

129
00:06:39,480 --> 00:06:44,391
Remember in Agile, you're allowed to
experiment so that you can review

130
00:06:44,484 --> 00:06:48,357
adapt and adjust to whatever works
best for you and your team.