hi this is me my name is hameed Cho je
and I’ve been involved with a number of
software development projects over the
years at a number of different companies
and I’ve come to recognize scrum has one
of the best agile development practices
in use today in this fast-paced video I
want to show you why scrum is so great
and how you can get started with scrum
in under 10 minutes I’ll cover all the
core scrum concepts like product
backlogs team roles sprints pronoun
charts and more so get ready to be
bombarded with information let’s say
this is the product we want to build or
this product we get all kinds of feature
requests from customers executives or
even other team members in scrum
features are written from the
perspective of the end user
therefore features are known as user
stories the collection of all these user
stories is called the product backlog
another way to think of the product
backlog is to think of it as a wish list
of all the things that would make this
product great once we have our wish list
or the product backlog we need to start
planning which specific user stories
we’re going to be putting into a
particular release of our product but
we’re getting ahead of ourselves let’s
back up a bit to build this product we
need to have one or more people on our
team we’re going to play a variety of
roles first we need her she plays the
role of product owner and helps make
sure the right features make it into the
product backlog by presenting the users
and customers of the product
she helps set the direction of the
product then we need this guy he’s the
swamp master and his job is to make sure
the project is progressing smoothly and
that every member of the team has the
tools they need to get their job done he
sets up meetings monitors the work being
done and facilitates release planning
he’s a lot like a project manager but
that’s such a boring title so we’ll call
him a scrum master behind who knows some
jujitsu and the rest of the team has
similar roles to other development
processes these guys build the product
while these guys test it to make sure it
works right these guys use it and
hopefully pay for it and these guys they
generally get in the way but it turns
out you can’t build many products
without them but let’s get back to this
release planning to plan and release the
team starts with this the product
backlog and they identify the user
stories they want to put into this
release these user stories then become
part of the release backlog the team
then prioritizes the user stories and
estimates the amount of work involved
for
sometimes larger user stories are broken
down into smaller more manageable chunks
the collection of all the estimates
provides a rough idea of the total
amount of work involved complete the
entire release a quick side note about
estimates there are a lot of techniques
for creating good estimates some prefer
estimating in story points where
estimates are made relative to building
a small component with a known level of
difficulty
unfortunately story points don’t answer
the question of when will my project
ship I’ve found that the best technique
is to estimate work in hours but to use
some standards and how estimates are
done for example things that take less
than a day to complete will be estimated
as one hour two hours four hours for
eight hours every item will fall into
one of those buckets
there will be no three hour estimates
for example a three hour item would fall
into the four our bucket larger items
will be estimated as two days three days
five days or ten days again all
estimates in between will fall into the
next larger bucket extremely large items
are similarly estimated in months one
two three or six months but the reality
is that such items will need to be
broken down substantially before work
actually begins we’ll come back to these
estimates in just a minute but for now
let’s get back to this the release
backlog with a prioritized set of user
stories and the estimated amount of work
at hand we’re now ready to plan out
several sprints to get the work done
spreads are short duration milestones
that allow teams to tackle a manageable
chunk of the project and get it to a
ship ready state sprints generally range
from a couple of days to as much as 30
days in length depending on their
products release cycles the shorter the
release cycles the shorter each sprint
should be and you want to have at least
two – as many as a dozen sprints in a
given release so at this point we can
take our release backlog and split it up
into several these sprint backlogs one
of the most important things to remember
about sprints is that the goal of each
sprint is to get a subset of the release
backlog to a ship ready state so at the
end of each sprint you should have a
fully tested product with all the
features of the sprint 100% complete
since Sprint’s are very short but a
realistic representation of part of the
product a late finish of the sprint is a
great indicator that the project is not
on schedule and something needs to be
done therefore it’s extremely important
to monitor the progress
each sprint with this a burn down chart
the burn down chart is the number one
reason for swans popularity and one of
the best project visibility tools to
ensure a project is progressing smoothly
the burn down chart provides a
day-by-day measure of the amount of work
that remains in a given sprint or
release in this graph you can see that
the amount of work remaining bounces up
and down from day to day but is
generally trending towards zero because
historical information is provided in
the burn down chart it’s easy to see if
the team is on the right track using the
burn down chart the team can quickly
calculate this the slope of the graph
which is also called the burn down
velocity this is the average rate of
productivity for each day for example a
team’s rate of productivity might be
that on a typical day they finish
approximately 50 hours of work knowing
that it’s possible to calculate an
estimated completion date for the Sprint
or even for the entire release based on
the amount of work remaining what’s
great about the burn down chart is that
we can compare our actual velocity and
projected completion date to what the
team needs to do in order to finish on
time this is perhaps the most useful
piece of knowledge that any team member
product owner or product executive can
have about the project because knowing
whether or not the project is on track
early in the schedule can help teams
make the proper adjustments necessary to
get the project on track the burn down
chart provides empirical proof that the
project is on track or if it’s going to
be late so let’s talk a little about
where the data for this incredibly
useful burn down chart comes from as you
recall part of the release planning
process was to create an estimate for
each user story in the release backlog
the collection of these estimates for a
given sprint represents the total amount
of work that must be done to complete
that spring as each team member goes
through and makes progress on one or
more of the user stories they simply
update the amount of time remaining for
each of their own items so the total
amount of time remaining on the group of
user stories that make up a sprint
changes on a day-by-day basis hopefully
going downward until it hits zero when
the Sprint is complete the burn down
chart aggregates the remaining work data
and shows it visually it’s brilliant
because it communicates a massive amount
of information in just a few seconds and
that brings us to this the daily scrum
the daily scrum is an essential tool to
having communication flow freely between
team members the idea is to have fast
paced stand-up meetings where team
member
quickly list the work they have
completed since the last meeting and any
obstacles in their way by meeting daily
it ensures the team is always in sync
and any major issues are dealt with as
soon as they are known finally as each
sprint comes to a finish it’s important
to have a sprint retrospective meeting
where the team can reflect on what went
right and areas of improvement after all
scrum is a flexible agile development
method that means constant improving and
tweaking for every team so there you
have it
scrum in under 10 minutes you don’t know
all the essential concepts to start
implementing scrum inside of your
organization but wait a second what
about tools to help you implement scrum
well it just so happens that I’ve spent
the last 10 years building such a tool
with a lot of help from these guides a
group of genius coders and design
engines the tool is called on time and
it helps you manage your products your
backlogs your team your releases and
your sprints it gives you project
visibility with burndown charts and
always answers the question of who is
working on what you can get started with
it for free at access Ofcom of course
you could use a giant whiteboard some
note cards and a bunch of different
spreadsheets to track everything you
could also use an abacus instead of a
calculator to do math but we’re getting
a little off-topic so let’s quickly
review everything in scrum you work with
this a product backlog which is nothing
more than a list of features that we
call user stories you then break down
the product backlog into one or more
release backlogs and for a given release
you further break up the release backlog
into a number of sprint backlogs which
are essentially short duration
milestones throughout your project you
then monitor the progress of each sprint
using these or noun charts and have
daily scrum meetings to ensure
everything is on track after each sprint
you have a retrospective meeting to
fine-tune everything and if you want a
tool to implement scrum you can use on
time that will help you ship software on
time that’s all there is to it oh and
one last thing whether you loved or
hated this video I’d love to hear from
you you can reach me on twitter or via
email if you have any feedback now get
going create a great team collaborate
and ship software on time
you
and I’ve been involved with a number of
software development projects over the
years at a number of different companies
and I’ve come to recognize scrum has one
of the best agile development practices
in use today in this fast-paced video I
want to show you why scrum is so great
and how you can get started with scrum
in under 10 minutes I’ll cover all the
core scrum concepts like product
backlogs team roles sprints pronoun
charts and more so get ready to be
bombarded with information let’s say
this is the product we want to build or
this product we get all kinds of feature
requests from customers executives or
even other team members in scrum
features are written from the
perspective of the end user
therefore features are known as user
stories the collection of all these user
stories is called the product backlog
another way to think of the product
backlog is to think of it as a wish list
of all the things that would make this
product great once we have our wish list
or the product backlog we need to start
planning which specific user stories
we’re going to be putting into a
particular release of our product but
we’re getting ahead of ourselves let’s
back up a bit to build this product we
need to have one or more people on our
team we’re going to play a variety of
roles first we need her she plays the
role of product owner and helps make
sure the right features make it into the
product backlog by presenting the users
and customers of the product
she helps set the direction of the
product then we need this guy he’s the
swamp master and his job is to make sure
the project is progressing smoothly and
that every member of the team has the
tools they need to get their job done he
sets up meetings monitors the work being
done and facilitates release planning
he’s a lot like a project manager but
that’s such a boring title so we’ll call
him a scrum master behind who knows some
jujitsu and the rest of the team has
similar roles to other development
processes these guys build the product
while these guys test it to make sure it
works right these guys use it and
hopefully pay for it and these guys they
generally get in the way but it turns
out you can’t build many products
without them but let’s get back to this
release planning to plan and release the
team starts with this the product
backlog and they identify the user
stories they want to put into this
release these user stories then become
part of the release backlog the team
then prioritizes the user stories and
estimates the amount of work involved
for
sometimes larger user stories are broken
down into smaller more manageable chunks
the collection of all the estimates
provides a rough idea of the total
amount of work involved complete the
entire release a quick side note about
estimates there are a lot of techniques
for creating good estimates some prefer
estimating in story points where
estimates are made relative to building
a small component with a known level of
difficulty
unfortunately story points don’t answer
the question of when will my project
ship I’ve found that the best technique
is to estimate work in hours but to use
some standards and how estimates are
done for example things that take less
than a day to complete will be estimated
as one hour two hours four hours for
eight hours every item will fall into
one of those buckets
there will be no three hour estimates
for example a three hour item would fall
into the four our bucket larger items
will be estimated as two days three days
five days or ten days again all
estimates in between will fall into the
next larger bucket extremely large items
are similarly estimated in months one
two three or six months but the reality
is that such items will need to be
broken down substantially before work
actually begins we’ll come back to these
estimates in just a minute but for now
let’s get back to this the release
backlog with a prioritized set of user
stories and the estimated amount of work
at hand we’re now ready to plan out
several sprints to get the work done
spreads are short duration milestones
that allow teams to tackle a manageable
chunk of the project and get it to a
ship ready state sprints generally range
from a couple of days to as much as 30
days in length depending on their
products release cycles the shorter the
release cycles the shorter each sprint
should be and you want to have at least
two – as many as a dozen sprints in a
given release so at this point we can
take our release backlog and split it up
into several these sprint backlogs one
of the most important things to remember
about sprints is that the goal of each
sprint is to get a subset of the release
backlog to a ship ready state so at the
end of each sprint you should have a
fully tested product with all the
features of the sprint 100% complete
since Sprint’s are very short but a
realistic representation of part of the
product a late finish of the sprint is a
great indicator that the project is not
on schedule and something needs to be
done therefore it’s extremely important
to monitor the progress
each sprint with this a burn down chart
the burn down chart is the number one
reason for swans popularity and one of
the best project visibility tools to
ensure a project is progressing smoothly
the burn down chart provides a
day-by-day measure of the amount of work
that remains in a given sprint or
release in this graph you can see that
the amount of work remaining bounces up
and down from day to day but is
generally trending towards zero because
historical information is provided in
the burn down chart it’s easy to see if
the team is on the right track using the
burn down chart the team can quickly
calculate this the slope of the graph
which is also called the burn down
velocity this is the average rate of
productivity for each day for example a
team’s rate of productivity might be
that on a typical day they finish
approximately 50 hours of work knowing
that it’s possible to calculate an
estimated completion date for the Sprint
or even for the entire release based on
the amount of work remaining what’s
great about the burn down chart is that
we can compare our actual velocity and
projected completion date to what the
team needs to do in order to finish on
time this is perhaps the most useful
piece of knowledge that any team member
product owner or product executive can
have about the project because knowing
whether or not the project is on track
early in the schedule can help teams
make the proper adjustments necessary to
get the project on track the burn down
chart provides empirical proof that the
project is on track or if it’s going to
be late so let’s talk a little about
where the data for this incredibly
useful burn down chart comes from as you
recall part of the release planning
process was to create an estimate for
each user story in the release backlog
the collection of these estimates for a
given sprint represents the total amount
of work that must be done to complete
that spring as each team member goes
through and makes progress on one or
more of the user stories they simply
update the amount of time remaining for
each of their own items so the total
amount of time remaining on the group of
user stories that make up a sprint
changes on a day-by-day basis hopefully
going downward until it hits zero when
the Sprint is complete the burn down
chart aggregates the remaining work data
and shows it visually it’s brilliant
because it communicates a massive amount
of information in just a few seconds and
that brings us to this the daily scrum
the daily scrum is an essential tool to
having communication flow freely between
team members the idea is to have fast
paced stand-up meetings where team
member
quickly list the work they have
completed since the last meeting and any
obstacles in their way by meeting daily
it ensures the team is always in sync
and any major issues are dealt with as
soon as they are known finally as each
sprint comes to a finish it’s important
to have a sprint retrospective meeting
where the team can reflect on what went
right and areas of improvement after all
scrum is a flexible agile development
method that means constant improving and
tweaking for every team so there you
have it
scrum in under 10 minutes you don’t know
all the essential concepts to start
implementing scrum inside of your
organization but wait a second what
about tools to help you implement scrum
well it just so happens that I’ve spent
the last 10 years building such a tool
with a lot of help from these guides a
group of genius coders and design
engines the tool is called on time and
it helps you manage your products your
backlogs your team your releases and
your sprints it gives you project
visibility with burndown charts and
always answers the question of who is
working on what you can get started with
it for free at access Ofcom of course
you could use a giant whiteboard some
note cards and a bunch of different
spreadsheets to track everything you
could also use an abacus instead of a
calculator to do math but we’re getting
a little off-topic so let’s quickly
review everything in scrum you work with
this a product backlog which is nothing
more than a list of features that we
call user stories you then break down
the product backlog into one or more
release backlogs and for a given release
you further break up the release backlog
into a number of sprint backlogs which
are essentially short duration
milestones throughout your project you
then monitor the progress of each sprint
using these or noun charts and have
daily scrum meetings to ensure
everything is on track after each sprint
you have a retrospective meeting to
fine-tune everything and if you want a
tool to implement scrum you can use on
time that will help you ship software on
time that’s all there is to it oh and
one last thing whether you loved or
hated this video I’d love to hear from
you you can reach me on twitter or via
email if you have any feedback now get
going create a great team collaborate
and ship software on time
you
Please follow and like us:
Be First to Comment