Now, let's go over some key concepts and terms that are used in Agile.
Let's start with user stories.
User stories are basically product features, requirements or tasks
that add value to the end customer.
And by adding value, I mean that whatever it is
it's something that the end customer would actually pay for
or they would find really valuable and important.
If something doesn't add value to the customer
then it can't be considered a user story and should remain
a task, sub-task or requirement.
User stories are written in a specific format which you can see on screen.
For example, as a customer
I want to be able to use my Facebook login credentials
to log in to the eCommerce website
so that I don't have to create a new account.
As you can see, this user story provides value to the customer
since it helps him avoid creating a new user and passwords
hence, saving him time.
So, in Agile, we create user stories for all project requirements and features
that add value to the customer and then
we add them to what we call the product backlog.
The product backlog basically contains
all the user stories that will be part of the project
but of course in Agile, that can be a changing list
since you might start with say 50 user stories and overtime
add 50 more. How many you add or remove will depend on
what you and your team define throughout execution
and you have the flexibility and autonomy to define that.
Now, the sprint backlog is just taking
a couple of user stories from your product backlog
and adding them your sprint
and committing to the delivery of those user stories in that sprint.
So basically, it's the amount of work you will do in those two weeks.
Remember that in Agile, sprints generally last two weeks
but you can make them three or four weeks
if you and your team define that is what is best for you.
From experience, I recommend two weeks
but like I said, that is not mandatory.
And finally, the story points.
The story points simply denote the level of complexity a user story has.
So you assign story points to each user story you create.
Personally, I'm a big advocate of keeping things simple.
So generally, I would recommend using a basic scale of one, three and five.
One being low complexity
three being medium complexity and five being high complexity.
Now, don't worry too much about spending
a lot of time estimating your story points,
keep it simple, follow your instinct
experience and gut feeling.
How many story points is something you can add
to each user story as a team
or you can also ask the person working on the user story
what level of complexity they consider it has.
The scale I have just suggested is just an example of course.
You can create your own scale or use existing scales such as fibonacci.
Discuss with your team what scale they want to use and use it
and if it doesn't work well after you finish the sprint
you'll have the opportunity to discuss that
in your team's retrospective or lessons learned session
and you can then adjust as required.
If you want to keep it simple
then follow my recommendation of one, three and five.
Now, let's go over the concept of velocity.
Do you remember I said that velocity relates to the speed of execution?
Well, basically the velocity of an Agile project
is the number of story points the team delivers over a sprint.
I'll repeat that.
The velocity of an Agile project is the number of story points
the team delivers over a sprint.
And of course, you will see variations of that
especially at the beginning when you are just learning
how many user stories you are actually able to deliver as a team.
So at the beginning, you are kind of guessing
or estimating how many story points you can deliver in a sprint
but after a couple of sprints
you will be able to average the number of story points
and then conclude for example that on average
your team is able to deliver 20 story points per sprint
and that is your velocity.
You will always be able to calculate your velocity at the end of your sprint
once you have reviewed what you delivered versus what you had planned.
Your velocity is not what you had planned
or what you thought you would deliver.
It's what you actually delivered in story points.
Swimlanes are a visual representation of the status of stories
on the Agile kanban board.
But that is better understood with an example
and a visual than by me explaining it with words.
So don't worry, I'll add the link in your lecture resources
so you can check what swimlanes look like
and how you can use them.
Now, let's switch to one of my favorite concepts in Agile
the MVP and no, this does not stand for Most Valuable Player.
In Agile, MVP stands for Minimum Viable Product
and basically, it means the bare minimum you can deliver
to meet your customers' expectations.
So if you think about the example we saw earlier on the course,
the MVP is the skateboard not the Ferrari.
And this is really powerful because this will allow you
to deliver quickly and often
and iterate and build up and enhance your solution over time.
This is a key Agile principle.
A release as the name implies is when you move your user stories
to a production environment
so, when you make them live.
Generally, Agile teams make releases to production once a month
so after two sprints
but, you might find some Agile teams making releases to production
every four sprints and not two
so, every two months.
At the end of the day, that is for the project team to decide
but remember, Agile is about doing things quickly and efficiently
so the shorter, the better
but don't push it too much.
Be careful with exaggerating.
Try to keep a good balance and releases that keep the team comfortable.
And finally, the sprint.
By now, you're already familiar with what a sprint means
but let's recap anyway.
A sprint is a period of time over which a team
will deliver a set of user stories.
Generally, sprints last two weeks
but some teams may have their sprints set up for three or four weeks
and that's okay.
You need to define what works best for you and your team
given your specific context and project dynamics
but, if you aren't sure, start with two weeks
and then change that to three or four if required.
Remember in Agile, you're allowed to experiment so that you can review
adapt and adjust to whatever works best for you and your team.