This content explains the Product Backlog as the central, evolving artifact in Scrum, detailing its components, best practices for management, and how it fuels sprint planning and execution. It also covers key Scrum events and tools that support transparency and efficient workflow.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
in this program we've introduced you to
lots of project management artifacts
such as project plans statements of work
racy charts and more
now we'll review an important artifact
of the scrum framework the product
backlog in an earlier video we defined
the product backlog as the single
authoritative source for things that a
team works on
it contains all of the features
requirements and activities associated
with deliverables to achieve the goal of
the project
the traditional non-agile project
management equivalent would be the set
of project requirements
there are three key features of a
product backlog first the product
backlog is a living artifact meaning
that items are added to the backlog at
any time the product backlog evolves
throughout the whole lifecycle of the
project and serves as a central guide
for the team to know what to work on
next second the product backlog is owned
and adjusted by the product owner
and finally the product backlog is
always a prioritized list of features
so when there's new information or new
features those are added to the backlog
in order of importance
the items at the very top of the list
are very specific and well defined
leaving the more vague items for the
bottom of the list remember the product
backlog is the guide and roadmap of your
product it's the central artifact in
scrum where all possible ideas
deliverables features or tasks are
captured for the team to work on
because the backlog is so central there
are a few best practices and pieces of
data to capture when working with
product backlogs there's the description
the value the order and the estimate
let's go through how to build a sample
backlog with these best practices in mind
mind
first there's the item description
the item description is exactly what it
sounds like it describes an item
when you're writing an item description
it's a good idea to be really clear when
adding product backlog items so the
details are encouraged for instance on
officegreen's new project virtual verde
here's an example of an item description
as a virtual verde client i plan to grow
my choice of vegetables while i work
from home in my new york city apartment
this item description includes essential
details such as an action and a location
from the perspective of the customer
this ensures that the development team
has enough information to meet the
user's needs
next up we have the value field this is
the field that tells us how much
business value the item delivers to the
customers to the team or to the users
how to indicate value is a choice the
scrum team should make together
i like to set value by using dollar
signs ranging from one dollar sign for
low value all the way up to four dollar
signs for high added business value
next we have to add in an estimate an
estimate is how much effort the scrum
team thinks an item will take to
complete we'll explore how to do
relative effort estimation coming up but
for now it's important to know that the
relative effort estimate is captured in
each backlog item this field in the
backlog is owned by the development team
the next attribute of each backlog item
is the order as we mentioned the backlog
should always be prioritized both the
estimate and value fields we just
discussed help the product owner figure
out where to place an item in the
backlog's order of hierarchy
a product owner may ask themselves how
important is this backlog item compared
to all the other items product backlogs
order items from highest to lowest priority
priority
this is called a stacked rank
ordering items this way allows teams to
operate more efficiently for example our
virtual verde market research team
learned that people who work from home
would much rather have plants that are
easy to take care of versus a more high
maintenance plant like orchids
then the team prioritizes the simple and
easy plants on the backlog like
succulents higher than the orchids so
their product backlog lists one
succulents two orchids but say for
example support gets an email from a
user who says they'd love to have bonsai
trees which are also hard to take care of
of
where do we put it in the order
before orchids or after
the product owner does some research and
decides that the team will do orchids
first because they find that many more
users have requested orchids versus
bonsai trees the product owner gives
orchids a two dollar sign value rating
bonsai trees a one dollar sign value
rating and puts bonsai trees last on
their list
awesome let's move on when creating
backlog items the goal is to include as
much as you can while not stressing
about the unknowns too much for example
the product owner in virtual verde
doesn't know yet how much bonsai trees
cost compared to succulents so they
don't know if they serve a high end
market or a low end market
they document an assumption in the
bonsai tree description and move on they
can study that in more detail when it is
higher on the priority list
so now you know a bit more about
defining the product backlog and who
owns it we also discussed how the
various roles work with a product
backlog and we can identify and describe
now that you know about the various
fields associated with each item in your
backlog let's discuss a popular way to
capture and manage those backlog items
user stories user stories are short
simple descriptions of a feature told
from the perspective of the user
this helps the team create a solution
that's always centered around the user
and the user experience
user stories might start off large and
broad or may be broken down to be as
small or specific as possible
in this lesson we're going to give you
some ideas on how to write user stories
and how to break them down
user stories are made up of three
different elements the user the action
they will take and the benefit to them
these elements might have a few
different formats but the most common is
as a user role i want this action so
that i can get this value
when writing effective user stories the
team must have a user in mind
imagine that the user will interact with
the product in order to achieve a
specific outcome
what i really like to do at this stage
is create personas or detailed
descriptions of my different users
sometimes i even give them names
so in virtual verde we could give our
users some names and some information
about them
here are some user persona ideas leo is
my plant vendor who manages acquiring
the plants the supply chain and delivery logistics
logistics
felicity is my gardening expert who
helps my support team give our customers
really excellent advice on how to take
care of their plants
zach is my amateur vegetable gardener
who wants to use the plants they
purchase to make dinner
nia is my management consultant who
works from home and wants to set up a
professional backdrop for video
conferences in their home office
rena is my flower aficionado who wants
to have a different flower arrangement
each week to brighten up their home
by giving these users a name and a
backstory we can imagine them in our
minds and we will design better products
for them as a result
i really enjoy writing user stories
because it puts me in the shoes of my users
users
each user story should meet six
different criteria represented by the
acronym i n v e s t or invest
i for independent the story should be
able to be started and finished by itself
itself
it's not dependent on another story to
finish it
the n stands for negotiable there's room
for negotiation and discussion about
this item the v is for valuable this
means that completing the user story has
to deliver value
e is for estimable our definition of
done must be clear so that the team can
give each user story an estimate
the s is for small each user story needs
to be able to fit within a planned
sprint if that user story is too big it
should be broken down into smaller
stories stories that are low priority on
the backlog can stay big until they
become a priority for an upcoming sprint
and finally the t is testable a test can
be written to check and make sure that
it meets the acceptance criteria
while the product owner is the main
person responsible for writing user
stories the team has a responsibility to
give feedback on whether the user story
is clear and fits the invest criteria
before they invest any time into it in
addition to user stories you need to
know the term epic which simply
represents a group or collection of user stories
stories
some epics for virtual verdi might be
live plant delivery office plant advice
service vendor management or client data management
management
let's come up with a sample user story
for our virtual verity clients in the
live plant delivery epic as a virtual
verde client i would like to acquire a
bonsai tree so that i can have a
beautiful plant and i can meditate as i
trim the branches
i thought of this one because i bought a
bonsai tree for my 12 year old nephew
last year and he did some research and
learned that in japan pruning bonsai
trees is a meditative practice so he's
learning how to do that with that sample
user story the product owner creates
something called the acceptance criteria
which is essentially the checklist you
will use to decide whether the user
story is done
to have a completed user story you must
meet the acceptance criteria checklist
here's an example of acceptance criteria
for the bonsai tree user story
user can browse for three different
types of bonsai trees to purchase
compare the three trees to know which is
easiest and hardest to grow in their
home maybe each plant has a beginner
intermediate and advanced gardener
notation next to it
can purchase specific bonsai tree care
packages like fertilizer trimming shears etc
etc
access online to a bonsai booklet sheet
as well as having a care booklet
packaged with the tree
can find a troubleshooting bonsai tree
issues page on virtual verde's faq page
sounds like an amazing story doesn't it
it feels like a real thing that a user
can interact with and get excited about
each user story in the backlog should be
written this way
it's natural for items higher in the
priority list to have more detail and
fewer gray areas
by leaving these low priority items
vague this saves the team time from
working on items that may end up getting
we've been exploring everything there is
to know about a product backlog
although the product owner owns or is in
charge of the data in the backlog the
team must work together to keep the
living document up to date
in this video we'll discuss how to do
that through a process called backlog
refinement backlog refinement refers to
the act of keeping the backlog described
estimated and prioritized so that the
scrum team can operate effectively
after the product owner has added the
backlog items with a description and a
value statement they do backlog refinement
refinement
backlog refinement is when the product
owner and some or all of the scrum team
review the backlog to ensure it contains
the appropriate items and that nothing
new is needed or nothing needs to be
removed that the items are prioritized
by the product owner this is also called
setting the order field
that the items at the top of the backlog
are ready for delivery with clear
acceptance criteria and that the backlog
items include estimates or an informed
assessment about how much work a
particular backlog item will be
let's discuss estimates since they're
crucial in backlog refinement we add
estimates to backlog items to inform our
planning practices about how much effort
it will be to finish each item or user
story through estimation we can find out
how much work we have ahead of us
it can be difficult to estimate the
amount of time it takes to complete a task
task
more often than not we human beings tend
to underestimate the time until
completion when it comes to big projects
this effect can be multiplied many times
and can be the root cause of projects
being late and over budget
so in scrum we try to overcome this
problem by practicing relative
estimation instead of absolute
estimation absolute estimation is also
called time and effort estimation in
traditional project management relative
estimation means that instead of trying
to determine exactly how long a task
will take we compare the effort of that
task to the effort for another task and
that becomes the estimate that
estimation is not done in traditional
units of hours days or weeks instead we
assign each backlog item a value that is
a relative unit for size
there are two common relative estimation
methods that i find most useful when
estimating user stories these are
t-shirt sizes and story points let's
start with the simpler of the two
t-shirt sizes
to get started the team simply picks one
item on the backlog that seems to be
about a medium-sized workload and simply
calls that a medium in the estimate field
field
after that they take another item on the
backlog and compare it to the medium
item they just identified and answer the
question if that first item was a medium
what size would i give this one
the team will repeat this process on
each additional item or user story on
the backlog until they're all addressed
and done
for example let's take four items from
virtual verde's product backlog
adding bonsai trees to the catalog
creating a mobile app launching a new
logo creating the new account page the
team decides that launching a new logo
is their medium
the team together compares the other
three items to that medium item
which gives them their relative effort estimate
estimate
then there's my favorite method for
estimating user stories tasks and
backlog items known as story points
story points are a bit more advanced
than t-shirt sizes but the concept is
similar the first step is the same the
team picks an item as their anchor item
and they'll conduct their estimations
relative to that item
instead of using t-shirt sizes this
process uses what are called story points
points
most teams use a famous mathematical
sequence of numbers called the fibonacci
sequence the fibonacci sequence is 1 2 3
5 8 13 21 and continues on to infinity
these numbers are special in that they
start out close to one another but as
the numbers get higher they spread
farther and farther out
this is helpful because as the estimate
gets higher the uncertainty and risk
also gets higher
this number combines both effort and
risk into one number
in other words there's not much use in
debating estimation values between 21
and 25 points but choosing between 21
and 34 is a real conversation this
concept can be tricky at first and
practice is the best way to learn it to
explain this concept in the classes that
i teach at google we use this example
let's say you want to measure the effort
to completely consume different kinds of fruit
fruit
you have in front of you an orange a
strawberry a banana a mango a pineapple
and a cherry what are the factors that
go into that estimate are there seeds to
deal with do i need to eat it with a
napkin can i eat it in one bite do i
have to peel it or do i need any tools
to prepare it
okay let's try it
if i choose a mango as our starting
fruit at five points
i would rate them this way orange
orange three
three
because the peel is easier than cutting
a mango
strawberry one because i don't mind
eating stems low effort
banana three because i have to peel it
similar to oranges
pineapple 13. it's giant i can't eat it
in one sitting and cherry two
stems seeds you know what i mean
it's really fun to learn how differently
people have learned how to cut up a pineapple
pineapple
but more importantly what estimation
exercises do for a team is uncover great
ideas on how to get something done
as well as surfacing where the riskiest
parts of the project are
why do i like story points better than
t-shirt sizes let's apply them to our
virtual verde backlog
now we can see that adding a new user
and adding bonsai trees to our catalog
aren't quite the same size which the
t-shirt sizes might have implied
story points a new user is 8 points and
the bonsai trees are 13. why would i
mark them this way well
well
implementing a new user page is a simple
software update adding bonsai trees is
more than just software it includes
finding vendors building a supply chain
and more
i mentioned earlier that backlog
refinement which includes adding
estimates and updating the order field
should take place regularly
just as it's up to the team to choose
which estimation method they select it's
up to the team to decide when and how
often to conduct backlog refinement
some teams prefer to set up special
meetings just to refine the backlog
others will simply refine the backlog
continuously in conversations or emails
and finally some teams will conduct
backlog refinement as part of a
scheduled event like their sprint
planning meeting now you know how to
define backlog refinement and you can
explain relative effort estimation
t-shirt sizes and story points
in the next video we're going to learn
more about sprint planning meet you there
as you learned earlier sprints which we
also called iterations provide the whole
rhythm for the team and is one of the
five scrum events
they allow us to get feedback quicker
encourage team collaboration
and provide more focus for scrum teams
within a sprint the amount of work is
planned based on the historical capacity
of the team and is made ready for the
sprint planning event
it might help to think of each sprint as
a mini project with planning execution
delivery closing and a retrospective all
wrapped into this bite size package
sprints are so important to scrum that
the other four scrum events revolve
around the sprint the scrum guide
technically defines
five events the sprint itself
sprint planning daily scrum
sprint review and the sprint retrospective
retrospective
throughout this section of videos i'll
share what the recommended duration or
time box is for each of these events
time boxes are an important concept in
scrum some examples of benefits are that
they create a sense of urgency which
will drive prioritization provide a
window of focus which improves
productivity and they help the team
develop a predictable rhythm to their work
work
a sprint's time box can range anywhere
from one to four weeks
how do you choose
well there are three considerations
first think about what you expect the
frequency of changes to be how often do
you think your requirements might change
if you expect your project to have new
requests popping up each week you may
want to make your sprint length one week
so that you can adapt more often if the
needs are more stable perhaps longer
will be just fine
second think about how much focused time
your solution developers might need to
build a backlog item if the baseline
effort for most of your activities
requires at least a week to create
something valuable then your sprint
length should be at least two weeks to
give the team room to execute without
feeling the crunch mode third
third
think about how much overhead goes into
a delivery of your product if your
deliverable or solution requires a large
review with many stakeholders or goes
through a rigorous testing and quality
assurance process that takes several days
days
you should factor that into your sprint
length and choose a longer sprint such
as three or four weeks instead
like most things in scrum there's no one
size fits all
and if you set a sprint length and
decide it's too long or too short after
a few sprints you can always change it
for example my current team has sprints
that are one week long because we expect
a lot of change and new requests coming
into our backlog every week
but often our work takes longer than a
week to complete we're currently
reflecting on that contradiction and
considering changing our sprint length
to two weeks great now you know more
for sprint planning the entire scrum
team comes together and meets to confirm
how much capacity meaning time and
people are available during this sprint
and then they identify what items from
the backlog will be done during the
sprint this becomes the sprint backlog
and ultimately the sprint goal
this is a time for the scrum master to
facilitate team communication and answer
the following questions throughout the event
event
who is available during this sprint
are there any vacations or conflicts
that we should know about
what has been our average velocity
meaning how many points or backlog items
have we been able to complete in a
single sprint in the past
what can and should be accomplished by
the team in this upcoming sprint
what is the ultimate sprint goal
how will the work get done
throughout the sprint who is responsible
for what tasks we've discussed sprint
lengths and story sizes so let's explore
the meaning of definition of done
definition of done refers to an
agreed-upon set of items that must be
completed before a user story or backlog
item can be considered complete
some things that may be within your
definition of done are the code or
solution itself is reviewed by an
independent peer group the product or
unit passes all testing requirements
which could include security or
performance testing
documentation is completed
all user story acceptance criteria
specified by the product owner is met
and finally the product owner accepts
the user story
this list isn't comprehensive and the
team should determine what should be on
this list and improve it as needed a key
deliverable of the sprint planning event
is the sprint backlog
the sprint backlog is the set of product
backlog items that are identified for
completion during the upcoming sprint
in other words the sprint backlog is a
subset of items from the product backlog
that you'll aim to finish during that
particular sprint
for example virtual verde's product
backlog might have 50 backlog items and
virtual verde has created four week
sprints that are named by month
may sprint june sprint july sprint and
so on for the may sprint the team has
determined that they can complete the
top five of those items based on the
capacity of the team for may and the
size of the effort of those items
those five items now make up the sprint
backlog the sprint goal is the
overarching objective that the team aims
to achieve and helps the team understand
the why of the sprint
this should be taken from a big picture
view of the items on the sprint backlog
the benefit of having a bigger sprint
goal identified is that it helps the
team focus on a broader team objective
rather than putting them into separate
work streams
for example let's say virtual verde has
identified these five items as the
sprint backlog for may
virtual verde users can purchase bonsai trees
trees
virtual verde users can access an online
discussion forum about home office decor
virtual verde vendor management team can
add audit results for vendors
virtual verde users can use a coupon to
purchase home office accessories virtual
verde customer support can connect
products to support tickets so the
sprint goal is to provide a
comprehensive experience to the user who
wishes to install a bonsai tree in their
home office
all of these backlog items can be
connected to this sprint goal in some
way for example there is a new coupon
for bond size the vendors are audited
as a refresher one of the principles
from the agile manifesto states
the most efficient and effective method
of conveying information to and within a
development team is face-to-face conversation
conversation
so in this video we'll discuss
communicating with the team through two
kinds of face-to-face events that occur
during and after the sprint the daily
scrum and the sprint review
first the daily scrum which is sometimes
referred to as stand-up is a time for
the scrum team to synchronize and
prioritize activities for the day
in 15 minutes and at the same time and
place every day
each team member answers the following questions
questions
what did i do yesterday that helped the
development team meet the sprint goal
what will i do today to help the
development team meet the sprint goal
do i notice any impediment that prevents
me or the development team from meeting
our goals
daily stand-ups should provide the scrum
master with the opportunity to quickly
unblock the team with little delay and
daily stand-ups are an opportunity to
reinforce focus on the sprint backlog
and sprint goal
the official scrum guide says that daily
stand-ups must happen every single day
though i will say i have had successful
scrum teams who meet less frequently
than that my current scrum team has a
one week sprint and we have stand-ups
two days during the week
we found that this works really well for us
us
try it out and see what works best for
your team
at the closing of a sprint the team will
complete another event known as the
sprint review
this sprint event is crucial to the
scrum pillars of inspection and
adaptation and demonstrate the values of
openness courage and respect let's
discuss what i mean by that
the sprint review is a meeting with the
entire scrum team where the product is
demonstrated in order to determine which
aspects are finished and which aren't
during a sprint review the development
team and product owner will play a heavy
role in this inspection and discussion
they'll also cover an exploration of
which items should be considered done in
the product backlog
and they'll demonstrate and inspect the product
product
sprint reviews should be really fun and
uplifting the sprint review is when the
team gets to impress each other with the
cool things they've accomplished over
the last one to four weeks
these time boxed meetings should not
exceed four hours
and they're a good opportunity for the
team to practice the scrum values of
openness and respect as they give
feedback about the completed work
often some of the greatest product ideas
come out of the sprint review
let's look at an example with the new
service the virtual verde team needs to
launch their new website page featuring
home office plants
let's imagine that the scrum team has a
marketing specialist on the team
remember scrum teams are cross-functional
cross-functional
during the august sprint review meeting
one of the sprint backlog items was to
create a launch email to send out to
their existing plant pals corporate
customers about their brand new adventure
adventure
during the sprint review meeting the
team gets a demo of the email they pull
up the email onto the shared screen and
give the specialist feedback right there
in the meeting such as
love that opening line really draws them in
in
let's make the opening image bigger can
we make it easier for the recipient to
forward this to their friends can we
make this text shorter it's a bit long
this group inspection of a work product
from the team has many benefits that go
way beyond just a better marketing email
first it makes the feedback as immediate
as possible
no need to wait for people to review on
their own and send in their feedback
later on
feedback and adjustments might be made
right there in the meeting
second everyone has a voice leading to a
shared sense of ownership of every
aspect of their product launch
last but not least the team learns more
about how their marketing teammate does
their job leading to greater trust and
understanding between team members
the sprint review is a time for the team
to demonstrate what they've accomplished
the sprint review is also where team
members unveil what is called the
product increment
the product increment is what's produced
after a given sprint and is considered releasable
releasable
a product is releasable when the team
has developed a minimum viable product
which has a set of implemented features
or requirements
a minimum viable product is a version of
a product with just enough features to
satisfy early customers
at the end of each sprint only items
that have met the definition of done are
considered part of the product increment
anything that is not done goes back to
the product backlog
great work we've now covered the
activities that happen during a sprint
to ensure that the team is focused and
the sprint retrospective is an essential
meeting of up to three hours for the
scrum team to take a step back reflect
and identify improvements about how to
work together as a team
in a sprint retrospective the scrum team
will reflect on what's working or not
working for the team regarding the
people the processes and the tools
what improvements are worth exploring in
the next sprint
and what improvements were put in place
for the last sprint were they helpful or
not and why in my experience there are
some key measures to take to ensure
sprint retrospectives are a success
first it's important to demonstrate the
scrum value of respect and always allow
the team to remain blameless
if any team member is worried there may
be negative consequences for providing
feedback your outcome won't be as
beneficial you'll need to create a safe
space for candor by acknowledging
potential awkwardness and if needed
create a space for anonymous or private feedback
feedback
participation is key because
retrospectives only work if participants
feel like their input matters
if you notice folks aren't volunteering
their perspectives search for ways to
generate new ideas such as asking them
what is one thing we could try in the
next sprint
what slowed us down
what happened that we didn't expect
the answers to these questions can help
you understand how to improve
for example just recently my team
discovered that having dependencies on
stakeholders outside of our scrum team
was slowing us down
in our retrospective we decided to
increase awareness of our priorities
with these external stakeholders through
some new communication channels
next balance the negative with the
positive don't just ask where you can
improve but also ask things like where
did we notice success
you want your team to feel like they
were successful and you also want to
recreate these successful outcomes
and finally make sure to act on it teams
can get discouraged from participating
in future retrospectives if it feels
like their feedback won't inspire change
search for improvements or simply
convert the things that worked best into
your team's habits and norms
facilitating conversation among the
scrum team both during retrospectives
and in everyday workflows is an
incredibly important aspect of being the
in this video we'll explore two very
important concepts that allow a scrum
team to manage their work as they
progress through a sprint and the entire
product backlog
these two concepts are burn down charts
and velocity
let's start with what a burndown chart's
purpose is and how a scrum team uses it
a burn down chart measures time against
the amount of work done and the amount
of work remaining
the goal of using a burn down chart is
to keep the team aware of how they're
doing against their overall goals
in a scrum team burn down charts reflect
how the team is doing with completing
user stories during the sprint
the scrum master will review the burn
down chart sometimes daily to examine if
the team will hit their goals or not
and there's some simple math and numbers
here so now is a good time to mention
what to do if your team is using t-shirt
sizes rather than story points
in that case simply map the sizes to a
number and use that number for the burn
down and velocity calculations
for example maybe an extra small is one
point a small is two points a medium is
five a large is eight and so on
here's an example
let's imagine our virtual verde team
sprints are four weeks long which will
count as 20 business days
in their july sprint the sprint backlog
had stories that added up to a total of
200 points to be completed
if you assumed an even burn of points
over the business days you'd expect 10
points to be burned each day
by day 5 in their sprint 22 points had
been burned or completed hmm okay
it's only 25 percent of their sprint so
maybe things are on track
by day 10 45 points had been completed
uh oh we should have been approximately
halfway done by now which would be a
hundred points
according to the burn down chart we're
running late
according to our sprint goal
now this isn't the time to panic and
stress out the team
at this point as scrum master you should
already be discussing with your team to
find out how you can help and unblock them
them
by day 15 the burn down is 140 points
few the team is back to humming along by
day 20 the burn down is 188 points
completed great job let's discuss what
happened in the retrospective
in scrum there's a term for how many
points a team burns down in a sprint on
average that term is velocity in other
words velocity is a measure of how many
points a team burns down during a single
sprint on average
when the team is conducting sprint
planning they're using their average
velocity over at least three sprints to
determine how many items they can safely
add to their sprint backlog
there are a few things worth noting when
it comes to calculating velocity
first there's no such thing as a good
velocity or bad velocity velocity is
simply what the team has historically
been able to achieve in a predetermined
time box
the next thing is that each team will
have a different velocity especially
since each team decides their own point
system calibration
it's impossible to compare your team's
velocity to another team's
for example i'm currently on a team of
three people and we're burning down 70
points in a one-week sprint so our
velocity is 70.
but on a previous five-person team our
velocity for a two-week sprint was only
120 points was one team better or worse
than the other nope just different
once you have a stable velocity and a
refined backlog with prioritization and
estimates this unlocks an incredibly
valuable superpower
you can now tell your stakeholders and
sponsors two important things
you can tell them approximately how long
it will take to complete the entire
product backlog
and how much of your backlog will be
completed by a particular time
this ability to confidently predict when
things can get done is one of the most
powerful tools in agilent's scrum in my opinion
opinion
let's imagine that our virtual verde
team has averaged 200 points in each
monthly sprint for the last three months
the team knows they have 1500 points
left in their product backlog
they now can say that it will take them
approximately seven or eight sprints to
complete the entire product backlog
what if it's july and the team wants to
know what will be available by january 1st
1st
no problem that's five months away just
go down the backlog from the top and
draw a line when you hit a thousand
points that's pretty confident estimate
based on the past performance of the team
team
pretty powerful right
if you want to pull in the dates you can
use this information to decide to add
people to the team and increase velocity
rearrange the priorities or make other
key project decisions
on any given team it can take multiple
sprints to reach a stable velocity and
that's perfectly normal
as the team gets used to estimating and
working together the velocity should
begin to stabilize
now you know how to define velocity
velocity trends and burn down charts you
also learned a bit about how an agile
team reaches a stable velocity and what
that entails
using these tools is essential to any
high performing scrum team there are
powerful means to achieve execution predictability
predictability
i'll demonstrate another useful
visualization tool in the next video
we learned about the importance of
visualizing progress using burndown
charts in the last video and good news
there are other visual tools that can
also help a team progress throughout
their sprint
the tool we cover in this video may be
familiar to you since we briefly covered
it in a previous video it's the kanban board
board
some teams refer to this as the scrum
board rather than the kanban board
while the two do have minor differences
they're referring to the same basic tool
the scrum guide doesn't specify exactly
what a scrum board is but some scrum
tools available in the market provide a
board that adds some features to a
kanban board
these features make it suitable
specifically for scrum
both boards have three main features
that make it a great sprint tracking
tool for scrum teams
there's visualization work in progress
limits also known as whip limits and
flow of work
visualization can be an important
strategy for learning and tracking
this kanban board communicates
everything we need to know at a glance
we can point at specific work items on
the board we want to discuss
use images with variation in colors and
sizes as we check in on work items and
we can notice where the challenges are
in our team
without this visualization it's not as
easy to find out where we can make improvements
improvements
these boards make it easy to notice
where whip limits break
we learned earlier in this course that
kanban whip limits are constraints on
how many work items the team actively
works on at any given time
this provides focus for the team which
is one of our scrum values
have you heard the idea that there's no
such thing as multitasking in scrum it
can be very true and the more work you
have the less efficient you can become
when you use a kanban or scrum board
each team may set a whip limit based on
their configuration and context this way
it's really obvious to notice when the
team is going beyond the whip limit
and finally using a kanban board can
give you a better sense of the flow of
work through the team's execution processes
processes
physical post-it notes or even virtual
versions of kanban or scrum boards
allows the team to experience the
movement of work from one phase to another
another
using a kanban or scrum board the team
will move the items through the
following stages to do
doing and done
this action often takes place during the
daily scrum but the team can move items
at any time
for example with our virtual verde team
let's say that leo our plant vendor has
finished the item to finalize contracts
with the three top plant vendors we plan
to use for our initial launch
leo will go to the kanban board and move
his item from doing to done and find out
what's next to work on
if for some reason that was the last
thing for him in the sprint he may reach
out to his team to see where he can help
a teammate with their work
so to recap kanban and scrum boards are
really useful because they help you
visualize your progress set and maintain
your team's workload and whip limits and
give you a sense of the flow of work
throughout the team's execution process
awesome i'll see you in the next video
where we'll review a few software
products that help a scrum team manage
we've covered a lot of ground in this
section we've learned all about the
various scrum events and what each of
them does to ensure a scrum team's success
success
to wrap up this section we'll review the
tools available to implement and
facilitate the scrum and agile workflows
these can help improve collaboration and
keep your workflow transparent
as a refresher one of scrum's pillars is
transparency so a scrum team's success
is very dependent on transparency within
the team and tools encourage everyone to
be fully aware of progress and updates
these tools will be used to store the
product backlog sprint backlog and any
other essential documentation
using scrum tools will help your team
keep all of your progress organized and
in one centralized place
we've already heard about scheduling and
work management collaboration and
productivity tools
let's revisit those tools now from the
perspective of a scrum team
let's talk about scheduling and work
management tools
in traditional project management
applications like microsoft project
provide you with very powerful schedule
and resource management capabilities
in a scrum team though the most critical
tool you'll need is something to manage
your backlog and your sprints
jira by atlassian is a popular agile
team project management tool and it
supports all aspects of team and backlog
management it can be customized for your
team and will provide you with a central
place to find all things related to your
scrum team
your product backlog your sprint
definitions your velocity your burn down
charts and much more
after jira there are other tools on the
market that your team can purchase that
provides similar capabilities some teams
build their own agile tooling inside of
spreadsheets too when it comes time to
choose a tool most of these tools will
let you have a free trial period before
you make a permanent choice
if you're searching for something simple
and fun to try i recently started using
trello's kanban capabilities just for my
own personal projects it's helped me
plan a move and organize a big birthday
party for my dad
asana is another tool we've referenced
in this program that works great for
sprint planning and backlog management
asana helps teams plan and coordinate
their work from daily tasks to strategic
initiatives with asana everyone can view
discuss and manage team priorities this
allows teams to understand who is doing
what and their time frame for each task
it's great for assigning tasks
automating workflows tracking progress
and communicating with stakeholders
these applications are built
specifically to help a team manage a
backlog and their sprints but there are
many activities that these products
can't perform this is where additional
tools for documentation collaboration
and productivity come in
you'll want to use some form of
documentation or word processing tool
this ensures that you capture key
information about your project in a long format
format
many products in this space feature both
the documentation and the collaboration
all in one tool google docs is a great
example of this but it's not the only one
one
spreadsheets such as microsoft excel or
google sheets are useful for most teams
you can use spreadsheets to capture
backlogs and backlog item information or
any number of other pieces of
information for your project
you may also want a tool to create
presentations either using google slides
or the microsoft equivalent these
presentation tools are used all the time
two you guessed it present information
to the team
and finally since it's agile we value
individuals and interactions so it's
essential that we have excellent tools
for collaboration and communication
the types of collaboration you'll
experience on a scrum team are video
conferencing team and one-on-one online
chats and emails
these tools will result in huge
productivity improvements for your team
they allow teammates to communicate more
effectively get quicker answers and
unblock themselves long before the next
day's daily scrum there are so many
useful applications out there to help
scrum teams maintain the desired
transparency between team members and in
scrum they decide what to use together
congratulations on finishing this video
in the google project management
certificate access the full learning
experience including job search help and
start to earn your official certificate
by clicking on the icon to view the next
course in this video click here and
subscribe to our channel to learn more
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
