Detailed Notes
This is an overview from one of our Agile classes (https://school.develpreneur.com/p/software_development_life_cycle).
You can find out more through our online classes at https://school.develpreneur.com and register for free. Registration will add you to our email list and you will periodically receive coupons for courses as well as notifications of the latest releases.
Transcript Text
thank you [Music] well welcome back we are going to continue talking about some agile stuff in this episode in this little mini course as it were a little mini lesson we're going to talk about specifically the rituals involved in the scrum development process and there's four that we're going to talk about sometimes you'll see a fifth but these are really the ones that we want to focus on because these are key to scrum and they are for lack of a better term or to summarize scrum rituals these are the activities that are required for Success if you're doing scrum and you're not doing these you're not doing it right you're missing out on some of the key things particularly the agile agile Manifesto points that make agile what it is the value the way to do software in a way that says we're going to get the most value out of it if you're not doing these there may be other things you're doing but if you're not doing these you're not doing scrum right the first one the first ritual is probably what most people would expect even is planning the first thing you do before a Sprint within scrum and just to be clear Sprints are predefined periods of time that we're going to basically do work typically they run from two to maybe maybe six or seven weeks per Sprint and the way you do it is you do for example let's say it's a two-week Sprint you'll do two weeks at the end you will deploy software and you'll go turn around and do another two weeks and make some changes and deploy software and add features and deploy software so on and so forth we talk more deeply about it in some of our other lessons and some of the other things so you may want to like you know bounce out and check out maybe like our overview for scrum or something along those lines back to this topic they're really two backlogs that are key in scrum and it is the product backlog and then there's the Sprint backlog and during planning is when we move things for the most part from product to Sprint backlog now backlog is a list of things that we need to do these are code that needs to be written design that needs to be done testing that needs to be done things like that these are the tasks that when they all get done theoretically in your product backlog if all of those tasks get done then theoretically that means that your your product is done you have a complete solution now there is a ebb and flow essentially of of tasks that are in that product backlog so you may have a lot of stuff done and then suddenly there's some changes and then in future Sprints suddenly the product backlog gets really big again or it may get to the point which you have nothing left on your product backlog you may even start a Sprint with an almost empty product backlog but because of discussions and where you're going you may suddenly fill up your backlog so in planning the key really the the goal really the objective is to fill up your Sprint backlog to put enough tasks and this is in itself a bit of an art to put enough tasks into your Sprint backlog to keep the development team busy to make sure that they're making the most use best use of their time and really almost more importantly they are achieving an objective within this Sprint there is a a theme or a goal or set of goals or objectives that each Sprint should have because if you remember as I just said you will deploy at the end of a Sprint so you're going to spend x amount of time however long your Sprint is you're going to be doing some work and then you're going to end up deploying that to your customer so you want something that's useful and you want to have useful progress progress at the end of each Sprint in planning this is where we look at what's in our product backlog and we try to find either families or groupings or themes of tasks and say you know hey if we want this Sprint to be focused on this type of thing that we're going to pull certain tasks in we're going to pull the related tasks in to do something you know very simple example would be let's say our Sprint is going to do like user login and management so if you look through the tasks you may find us a task that says create a login screen create a forgot password create a change password log out create a user or register a user those kinds of things would all be tasks that maybe you pull into your Sprint assuming that you can get them done within a Sprint now there's a there's again an art to how you bring these in we're not going to cover those in this discussion we just want to sort of talk about the rituals as opposed to getting too deep into how to master them now the next in sort of chronological order that you're going to bump into is the daily stand-up daily stand-up is confusingly enough a daily meeting you're going to do this beginning of every day some places don't but or it's sometimes called a daily scrum some there's some places that try to do it every couple of days or something like that really it's better to just do it as a daily meeting and it's a stand-up it's called a stand-up because the meeting should be so quick it's not worth going in there and sitting down that by the time you would sit down and get settled in your the meeting's done so it's not a status this is not everybody walking through and talking about what they're doing and all that kind of stuff it should be quick and get out and the goal of this meeting is that we're going to come in we are going to talk really about it's really about where are we at in regards with regards to our Sprint what are we working on what did we get done essentially what are we working on today are there any blockers so you could see it as sort of a insta status or something like that like a you know it's more of like a a pulse check and really what it is is to make sure that we have people all of the team all the development team working towards our goal and if there's any obstacles which is what the scrum Master really that's their goal is to remove obstacles if there's any obstacles then those can be brought out and the scrum Master can help us move forward now once we get to the end of our Sprint there is the Sprint review this is effectively it's almost like a demo type of a meeting it can be you know any length it's it's going to be a set linked when you get to it and it could be as short as maybe 30 minutes but that's I think rare typically it's more like one to two hours and this is where as we've talked about as you're going through your Sprint you're completing tasks and working towards a deployment when you get to the end of the Sprint the Sprint review is where you go through those things that were completed and you'll have essentially like maybe a customer represent representative there or the product owner things like that and you're going to go through and say here's what we did and you're going to show it so it's not just a list of items and you say well we did this and we did that and we did this other thing it is this is what was done this is what this looks like within the application for example in a bug if there's a bug fix you may say here's what it did before here was the you know the actions and how you generate the bug and now with the code change you take those same actions and you get you know a successful completion or something along those lines so your split review is where you're it could be called like a dog and pony or something like that but it's really where you're showing off what got done in this Sprint what did we do and then how does that work within the the system that we're building so when you deploy something at the end of your Sprint the Sprint review is almost like the uh like the user Education meeting where it says okay this is what's out there this is what we're putting out in this release how it works how it fits together there's more to it than that but I think that gives you should give you a good idea of what a Sprint review is now the last thing you do is a retrospective and this is after your Sprint review you get to the end and of your your Sprint and all the stuff you've done and now we're going to look back at this Sprint we're going to say okay we're done let's take a look at how we did and what we do typically in a retrospective and they again vary a little bit but the gist of it is it's going to be typically 30 minutes uh probably more often an hour maybe an hour half meeting and you get everybody in the team everybody in the develop everybody in the scrum team so this is the product owner the scrum Master the development team and you talk a little bit about what did we do right in this Sprint in this Sprint what went right what is it yes this is that positive stuff how did we do what do we do well and then what are the things that we did wrong or that we need to stop doing or that we need to change and so you have a meeting that is usually you try to get it sort of you know half and half as far as the the retrospective part of it which is maybe the first half or so of the meeting is get some positive stuff get some negative stuff because the goal you have to have negative stuff there has to be something that you can improve nobody's perfect no Sprint is perfect so out of this retrospective the initial part of it is going to be things that we want to continue and then things that we want to change or start doing or stop doing so you know changes within those changes then what we're gonna do is look at them and say okay which of these because you're probably not going to be able to do all of them you're not going to go from here's a long list of of issues and then boom in the next Sprint you're done because what we're going to do in our next steps is say how are we going to change in the next Sprint what are we going to change essentially right away because we're going to go from our retrospective effectively Right End to our planning for our next Sprint and I don't mean like physically in the meeting that you just you immediately go into it but generally speaking there's nothing else in the Sprint and then the next thing that technically you do as a team is Sprint planning for the next Sprint so what we're going to do here in our retrospective is we're going to look back at what we did how we did and then as a group figure out what makes sense for us to focus on to improve in the next Sprint we want something that is uh bite-sized or doable something that is realistic as a goal that we can go into the next Sprint we can say this is what we're going to change and when we get to the next retrospective we should be able to check off that yes we did it or no we didn't and so that gives us a look back how did we do but with the the focus the intent of looking at what we did how can we be better in the next Sprint and that really is the key to scrum is that while you want to get there's a lot of little things that you want to get done but the way it is going to be most effective for you as a team is if you are utilizing these things to be better at it every time you cycle through your Sprint now we have lots of details underneath what we have discussed this is just a you know a summary so definitely check out some of our other videos check out school.developreneur.com there are other places that you can go to find more information about each of these but this should give you at least an idea if you're stepping into scrum or if you're scrum curious if you've wondered what this thing is how does it work this should give you a better idea of what are the key pieces of it and now you can go out there and make sure that your team assuming that you're using scrum is doing it right thanks a lot for your time
Transcript Segments
thank you
[Music]
well welcome back we are going to
continue talking about some agile stuff
in this episode in this little mini
course as it were a little mini lesson
we're going to talk about
specifically the rituals involved in the
scrum development process and there's
four that we're going to talk about
sometimes you'll see a fifth but these
are really the ones that we want to
focus on because these are key to scrum
and they are for lack of a better term
or to summarize scrum rituals these are
the activities that are required for
Success if you're doing scrum and you're
not doing these you're not doing it
right you're missing out on some of the
key things particularly the agile agile
Manifesto
points that make agile what it is the
value the way to do software in a way
that says we're going to get the most
value out of it if you're not doing
these there may be other things you're
doing but if you're not doing these
you're not doing scrum right
the first one the first ritual is
probably what most people would expect
even is planning
the first thing you do before a Sprint
within scrum and just to be clear
Sprints are predefined periods of time
that we're going to basically do work
typically they run from two to maybe
maybe six or seven weeks per Sprint and
the way you do it is you do for example
let's say it's a two-week Sprint you'll
do two weeks at the end you will deploy
software and you'll go turn around and
do another two weeks and make some
changes and deploy software and add
features and deploy software so on and
so forth we talk more deeply about it in
some of our other lessons and some of
the other things so you may want to like
you know bounce out and check out maybe
like our overview for scrum or something
along those lines back to this topic
they're really two backlogs that are key
in scrum and it is the product backlog
and then there's the Sprint backlog and
during planning is when we move things
for the most part from product to Sprint
backlog now backlog is a list of things
that we need to do these are code that
needs to be written design that needs to
be done testing that needs to be done
things like that these are the tasks
that when they all get done
theoretically in your product backlog
if all of those tasks get done then
theoretically that means that your your
product is done you have a complete
solution now there is a ebb and flow
essentially of of tasks that are in that
product backlog so you may have a lot of
stuff done and then suddenly there's
some changes and then in future Sprints
suddenly the product backlog gets really
big again or it may get to the point
which you have nothing left on your
product backlog
you may even start a Sprint with an
almost empty product backlog but because
of discussions and where you're going
you may suddenly fill up your backlog so
in planning the key really the the goal
really the objective is to fill up your
Sprint backlog to put enough tasks and
this is in itself a bit of an art to put
enough tasks into your Sprint backlog to
keep the development team busy to make
sure that they're making the most use
best use of their time and really almost
more importantly
they are achieving an objective within
this Sprint
there is a a theme or a goal or set of
goals or objectives that each Sprint
should have because if you remember as I
just said you will deploy at the end of
a Sprint so you're going to spend x
amount of time however long your Sprint
is you're going to be doing some work
and then you're going to end up
deploying that to your customer so you
want something that's useful and you
want to have useful progress progress at
the end of each Sprint
in planning this is where we look at
what's in our product backlog and we try
to find either families or groupings or
themes of tasks and say you know hey if
we want this Sprint to be focused on
this type of thing that we're going to
pull certain tasks in we're going to
pull the related tasks in to do
something you know very simple example
would be let's say our Sprint is going
to do like user login and management
so if you look through the tasks
you may find us a task that says create
a login screen create a forgot password
create a change password log out create
a user or register a user those kinds of
things would all be tasks that maybe you
pull into your Sprint assuming that you
can get them done within a Sprint
now there's a there's again an art to
how you bring these in we're not going
to cover those in this discussion we
just want to sort of talk about the
rituals as opposed to getting too deep
into how to master them
now the next
in sort of chronological order that
you're going to bump into is the daily
stand-up
daily stand-up is
confusingly enough a daily meeting
you're going to do this beginning of
every day some places don't but or it's
sometimes called a daily scrum some
there's some places that try to do it
every couple of days or something like
that really
it's better to just do it as a daily
meeting and it's a stand-up it's called
a stand-up because the meeting should be
so quick it's not worth going in there
and sitting down
that by the time you would sit down and
get settled in your the meeting's done
so it's not a status this is not
everybody walking through and talking
about what they're doing and all that
kind of stuff
it should be quick and get out
and the goal of this meeting is that
we're going to come in we are going to
talk really about it's really about
where are we at in regards with regards
to our Sprint
what are we working on what did we get
done essentially what are we working on
today are there any blockers so you
could see it as sort of a insta status
or something like that like a you know
it's more of like a a pulse check and
really what it is is to make sure that
we have people all of the team all the
development team working towards our
goal and if there's any obstacles which
is what the scrum Master really that's
their goal is to remove obstacles if
there's any obstacles then those can be
brought out and the scrum Master can
help us move forward
now once we get to the end of our Sprint
there is the Sprint review
this is
effectively it's almost like a demo type
of a meeting it can be you know any
length it's it's going to be a set
linked when you get to it and it could
be as short as maybe 30 minutes but
that's I think rare typically it's more
like one to two hours
and this is where as we've talked about
as you're going through your Sprint
you're completing tasks and working
towards a deployment
when you get to the end of the Sprint
the Sprint review is where you go
through those things that were completed
and you'll have essentially like maybe a
customer represent representative there
or the product owner things like that
and you're going to go through and say
here's what we did and you're going to
show it so it's not just a list of items
and you say well we did this and we did
that and we did this other thing it is
this is what was done this is what this
looks like within the application for
example in a bug if there's a bug fix
you may say here's what it did before
here was the you know the actions and
how you generate the bug and now with
the code change you take those same
actions and you get you know a
successful completion or something along
those lines
so your split review is where you're it
could be called like a dog and pony or
something like that but it's really
where you're showing off what got done
in this Sprint
what did we do and then how does that
work within the the system that we're
building
so when you deploy something at the end
of your Sprint
the Sprint review is almost like the uh
like the user Education meeting where it
says okay this is what's out there this
is what we're putting out in this
release how it works how it fits
together
there's more to it than that but
I think that gives you should give you a
good idea of what a Sprint review is
now the last thing you do is a
retrospective and this is after your
Sprint review
you get to the end and of your your
Sprint and all the stuff you've done and
now we're going to look back at this
Sprint we're going to say okay we're
done
let's take a look at how we did
and what we do typically in a
retrospective and they again vary a
little bit
but the gist of it is it's going to be
typically 30 minutes uh probably more
often an hour maybe an hour half meeting
and you get everybody in the team
everybody in the develop everybody in
the scrum team so this is the product
owner the scrum Master the development
team and you talk a little bit about
what did we do right in this Sprint in
this Sprint what went right
what is it yes this is that positive
stuff how did we do what do we do well
and then what are the things that we did
wrong or that we need to stop doing or
that we need to change
and so you have a meeting that is
usually you try to get it sort of you
know half and half as far as the the
retrospective part of it
which is maybe the first half or so of
the meeting is get some positive stuff
get some negative stuff
because the goal you have to have
negative stuff there has to be something
that you can improve nobody's perfect no
Sprint is perfect so out of this
retrospective the initial part of it is
going to be things that we want to
continue and then things that we want to
change or start doing or stop doing so
you know changes
within those changes
then what we're gonna do is look at them
and say okay which of these because
you're probably not going to be able to
do all of them you're not going to go
from
here's a long list of of issues and then
boom in the next Sprint you're done
because what we're going to do in our
next steps is say how are we going to
change in the next Sprint
what are we going to change essentially
right away because we're going to go
from our retrospective effectively Right
End to our planning for our next Sprint
and I don't mean like physically in the
meeting that you just you immediately go
into it but generally speaking there's
nothing else in the Sprint and then the
next thing that technically you do as a
team is Sprint planning for the next
Sprint
so what we're going to do here in our
retrospective is we're going to look
back at what we did how we did and then
as a group figure out what makes sense
for us to focus on to improve in the
next Sprint
we want something that is uh bite-sized
or doable something that is realistic as
a goal that we can go into the next
Sprint we can say this is what we're
going to change and when we get to the
next retrospective we should be able to
check off that yes we did it or no we
didn't
and so that gives us a look back how did
we do
but with the the focus the intent of
looking at what we did how can we be
better in the next Sprint and that
really is the key to scrum
is that while you want to get there's a
lot of little things that you want to
get done but the way it is going to be
most effective for you as a team is if
you are utilizing these things to be
better at it every time you cycle
through your Sprint
now we have lots of details underneath
what we have discussed this is just a
you know a summary so definitely check
out some of our other videos check out
school.developreneur.com there are other
places that you can go to find more
information about each of these but this
should give you at least an idea if
you're stepping into scrum or if you're
scrum curious if you've wondered what
this thing is how does it work this
should give you a better idea of what
are the key pieces of it and now you can
go out there and make sure that your
team assuming that you're using scrum is
doing it right
thanks a lot for your time