[Music] hey guys welcome to scrum master full course
video by simplilearn in this video we'll cover some of the most important concepts related
to scrum we'll talk about what exactly scrum is the components of scrum process the role
of a scrum master the scrum methodology how scrum meetings work how scrum and kanban are
different from one another and finally we'll cover some important interview questions that
will help you aco interview our instructors jeff and chandra will help you understand
the topics with ease before we begin don't forget to subscribe and click that bell icon
to never miss an update from us now let's jump right in hi welcome to scrum tutorial
from simply learn i am cmr chandra mr a professional consultant and coach who is certified scrum
master pmp prince2 practitioner itl for managing professional devops and kobit 5. as part of
this tutorial we are going to understand the basic understanding requirements of scrum
the agile methodology so let us look at a problem scenario what was there in the absence
of adoption of agile in any given environment so in the given scenario there is a problem
expressed so we have a problem our consumer doesn't like our product we will have to make
changes immediately so now as usual any manager would respond the manager says make the changes
so because it's always the changes or anything what we deliver is in the consumer's interest
so keeping consumers interest in mind the value which needs to be created for customers
any changes required to be done in any of our projects involving that consumers and
customer we may require to do the change so but what is the problem here to do the change
so we can't we already have started work on last batch the waterfall model we follow doesn't
let changes to be made midway through the process so is it mean the waterfall model
never allows the changes to happen that is not true hundred percent waterfall model allows
us to make changes but it doesn't allows us to make the changes quickly so whenever there
is a change it requires lot of effort it requires changes in documentation it asks for the changes
in various different implementations which has already done which is executed already
and then a lot of efforts are involved which is time consuming and also it involves more
cost now how do we make the change which is required to the customer and at the same time
we don't have any specific additional effort which are required so these efforts whatever
is being put is acceptable to both the parties both the stakeholders that is the project
organization as well as the customer so how do you make it happen quickly as well that
is very important for us so we should have used the agile methodologies so meaning agile
methodology helps us to do this so one of the agile methodologies which we are going
to look at as part of this tutorial is scrum so let us see how scrum is going to help the
scenario so scenario of changes which are coming up more frequently right right before
that let us understand what is the meaning of agile what is the meaning of agile what
it means and why should we adopt agile so agile means moving faster being flexible responding
to the changes now agile is a set of methods and practices that focuses on iterative development
why iterative in each iterations agile methodologies helps us to create a working piece of the
software product which will help us to make quick corrections to those software piece
this is not a whole product it is part of that bigger product so requirements and solutions
are obtained thanks to self-organizing cross-functional teams collaborating so when we say cross-functional
team self-organizing team so these are the teams which are seven plus or minus two the
size of the team what i'm speaking about who basically have various different skills each
of the team members will have various different skills and they complement to it i think today
the devops is speaking about this cross-functional team owning everything as a single team some
of the organizations has already demonstrated their devops capabilities by having this approach
like having self-organizing and cross-functional team having an accountability for the entire
product the particular piece of the product module what they have created so this helps
in improving accountability and also ensures better visibility of the product what is being
created and delivered so further let us look at the advantages of using agile so what it
gives to us how it helps so now the organization who follows the gel methodologies so we can
see that projects follow a predefined schedule and have a predictable cause so schedules
are seen but wherever there is a changes required wherever these directions need to be changed
in terms of making necessary changes to adopt to the required scenario the change scenario
agile helps us it gives that flexibility so clients have visibility of each phase of project
so it is very essential whosoever adopts the agile methodology the active involvement of
customer has to be ensured so they are actively involved so customers or clients actively
involved in the sense they know it what is happening what they are getting they know
they are acknowledging it by giving the feedbacks every now and then so that there is no surprise
to them at the end which used to happen during waterfall approaches then greater interaction
between project team and the project means there needs to be collaboration agile emphasizes
on having the collaboration so scrum in specific have something called daily scrum where 15
minutes meeting where entire scrum team should come in sit together self-organizing team
as well as all that agile team has to come together express what they have completed
before the last daily scrum meeting and what is spending why is it pending and what is
that they are going to do before the next meeting so all these are expressed this will
help the team as well as the scrum master as well as the product owner the visibility
into what is complete what needs to be completed and this will help project manager or scrum
master to provide the necessary inputs better visibility to the customers and stakeholders
as well product output is predictable and can sometimes happen earlier than expected
so now initially as we know so the visibility of anything what we do will be very less so
now as we discuss more and more as we brainstorm more and more the visibility into it will
become more then what would happen in future the ability to predict will also become easier
and if this doesn't happen only with the project team it also happens with customers and every
stakeholders who are involved in the project so next high quality development testing and
collaboration is ensured since the project is broken down so now each iterations each
module each piece of software which is being created are tested regularly feedbacks are
obtained from the user as well active involvement of user are ensured so that they are acknowledging
it so the what customer needs are given so it is not that i discover something which
i did not need i i'm seeing it i told something i'm getting something that scenario is eliminated
then the product backlog can be refined and reprioritized so since we move iteration wise
depending on the change scenario depending on the directions changes we can keep reordering
or re-prioritizing our product backlog what needs to be created first if i have one two
three four five item i can make it as three four one two five so depending on the change
scenario whenever it needs to be executed it is bit flexible and easy to do then teams
can maximize project value since clients can provide project priority so as we know the
visibility also increases to the consumer as well as all the stakeholders they will
also express what is that value they have seen from this and this will also help in
making a decision should we continue with this project or should we not so better visibility
better decision making better value realization the needs of the customer can be focused on
increasing the value delivered so as customer gives the feedback as that visibility increases
then a customer is getting that value and then expressing what is the changes what is
that additionally they may required here how can make it better so these interactions can
happen so customer can be focused on increasing the value delivery so in fact i think earlier
we used to speak about time to market today we're speaking about time to value which means
how quickly the consumers the users or customers realizes the value is that benefit realized
so that's what the more and more discussion which is happening which requires closer collaboration
with consumers and their feedbacks their experiences with the products or services which are being
used by them it is very essential to understand so then various different methodologies what
we have in agile we can speak about scrum kanban extreme programming that is xp lean
methodologies the crystal so now in this video tutorial we are actually focusing on scrum
so let us understand what is this scrum is all about right so before we go and understand
what is the scrum itself so let us look at the history of scrum where it started how
it started so right down the line during 1986 the name scrum is first introduced by the
management experts yukujiro nanaka and hirotaka kuchi so japanese so now this terminology
introduced but later in 1995 jeff sutherland and ken schubert creates the early version
of what would become the agile methodologies so now earlier 1995 so need for agile was
sensed and it was spoken about i mean why do we need a gel methodologies in future what
would be the future organization which would look like so that would trigger in terms of
what kind of approaches we may require to have so further 2001 the agile alliance is
founded and first look on scrum the agile software development with scrum is published
so then further down the line 2002 the scrum alliance is founded by weber and certifications
are added then later 2006 the scrum link is created the certified scrum courses are taught
so people started getting certified on scrum then later 2009 scrum.org is created which
offers the professionals scrum series of certifications then 2010 the first scrum guide is published
so which made available to everyone so from then i think the more and more people start
adopting scrum methodologies now interesting part is the journey started from 1980s till
2010 various changes which has happened to this particular methodology but one thing
we should keep in mind is same 20 years back or 15 20 years back if we go the need for
a jail was not seen so it was spoken but need for a gel was not spoken much but today we
are speaking about it more and more the reason is i think the change in the market condition
the increase in the competition the need of responding to the change which is asked by
the consumers of the market variations has become more and more important for organizations
and service providers if they don't respond to the change they may lose out in the competition
so their survival is at stake so it is very essential for them to understand this dynamics
and respond to those scenarios quickly so that's where the adoption of agile the benefit
of adopting a jail were realized and scrum become popular so what is scrum so let us
look at that so now scrum is a framework that enables teams to work together means collaboration
is very important while we become agile so with scrum team one can look i mean see and
experience so learning from experiences happens so those are captured self-organized working
on problems so they work together they discuss brainstorm reflect on their victories means
any achievements has to be celebrated acknowledged quick queens recognized and their losses to
improve so wherever the things doesn't go good necessary corrections has to be done
i think scrum approach would help in terms of doing it quicker better then some of the
benefits using scrum would look like steam can provide project deliverables and in an
efficient manner so in time we are completing all the features and functionality so the
entire model the methodology what is there which helps in accomplishing those then further
time and money are used efficiently so time is very important giving results in the mentioned
schedule is very important ensuring results are coming up effectively is important efficiently
the performance of that products now since we are creating those small piece working
piece in every iterations so that experience of using that would also be there and quick
feedbacks will come back so that time and money is saved and we are doing in time so
projects are divided into smaller units called sprint so the iterations what are speaking
about the quick iterations of activities which happens uh during the adoption of scrum when
organization adopt describe methodology so it is called a sprint it's a time box iterations
which will have a set of subset of product backlog taken as a sprint backlog and those
users stories and epics are delivered as part of that sprint and then those are reviewed
on a daily basis as part of daily scrum meeting and also we have other meetings which will
happen when we go and look at methodology how this happens i think we'll get better
visibility work best for fast moving projects now whenever we need to respond quickly whenever
we want to move faster now remember when we say moving faster means it doesn't mean that
we can allow any defects to happen we can ignore something we cannot do that we need
to ensure everything is taken care at the same time all those results what are created
has to be acknowledged right confirmed yes it is defect free so all those which is supposed
to be addressed are taken care and things are moving faster and better and the results
are according to what was actually expressed as a requirement it is fulfilling those then
scrum meetings provide the team great visibility since there is a daily scrum meeting which
keeps happening people speaks about what they have done from the previous daily scam what
is that they have accepted they will complete and what is complete is everything is complete
or something is pending if it is pending why is that pending and what is that you are going
to do further before the next daily scrum meeting so these are discussed understood
so that there's a quick 15 minutes meeting which gives the insight and further wherever
there is a dependency deviations which occurs further maybe scrum masters sit with them
separately to understand that in detail so daily scrum meetings give the quick insights
so that it increases the visibility what is happening on ground constantly involves feedback
from clients and customers as i mentioned earlier while discussing about agile active
involvement of a customer is very essential so customers should give the feedbacks whenever
that working piece of the application or a product is given so only then whether the
product or that module what is created is having that features and functionality which
helps in providing necessary requirement fulfillment is that happening or not then making changes
based on feedback are very easy because everyone is informed and they are aware of what is
being changed and what needs to be changed then individual efforts of the team members
are given focus yes individual efforts is essential at the same time each team member
cross skills we call it a self-organizing team as i was mentioning earlier so each team
member will have different different skills different different capabilities and also
cross-skilling within the team is encouraged so that the ownership on individuals deliverables
and team as a whole working together to deliver some features functionality can also be accomplished
right then scrum team involves product owner scrum master and then scrum team so each of
these are different roles having their own objectives to accomplish with the specific
directions and each of this cannot be merged like for example the roles and responsibilities
of product owner cannot be given to single individual who is a scrum master so both the
roles cannot be given a single individual because it conflicts the objectives of both
the rules so thinking about putting this one of the team member becoming scrum master product
owner thinking in that angle is also something which is which will not work which will not
give the required results so now what are these roles what are the responsibilities
where is the focus of each of the roles so let us discuss on that now when it comes to
product owner so the product owner is primarily responsible for maximizing the roi by determining
the product features prioritizing it into a list what needs to be focused on for the
next print and constantly reprioritizing and refining it so the key points what we need
to see here is so one is determining the product features maximizing the roi the second one
and then re-prioritizing and refining the product backlog now why is that needs to be
done so maximizing roi in the sense obviously product owner should closely work with the
business and have an insight towards what is that business require what is that customer
require how it helps customer to accomplish that result so that it helps the justifying
that investment what they're doing with the products features and functionalities then
speaking about reprioritizing and refining it it depends on what features needs to be
delivered in what order so there is already an order which is defined so based on the
change scenario you can reorder it and product owner has that ownership and responsibility
so the entire focus is on ensuring the right product backlog prioritizing it and also adding
that user stories and epics into product backlog depending on what makes sense to the business
so the scrum master the next role helps teams learn and apply scrum to obtain business value
means scrum master closely works with the team so he or she helps remove impediments
what is impediments something which stops to move forward something which doesn't allow
to deliver things the way it is required something which stops right so that needs to be eliminated
that needs to be understood what are the impediments so when we say impediments what are the impediments
we can think of the skills and capabilities of the team that is one thing maybe the testing
environment may be a process so anything comes as a bottleneck or impediments which stops
things to move smoothly forward so scrub master should work on it identify that and support
team or guide team to overcome those so protects them from interfaces that helps the team to
adopt agile practices so encouraging team to adopt agile practices and ensuring they
demonstrate it and provides the required value as its move forwards so since scrum master
focuses one side in terms of making scrum team to work whereas product owner is looking
at the entire product backlog and working more closely with the business so they need
to have a good handshake to ensure things go well but these two roles cannot be merged
because since it has a two different angles and two different dynamics so spending time
accomplishing both the things may become very challenging and conflicting and the prioritizing
will also be difficult then scrum team is a collection of all the individuals who work
together to deliver the requirements of the stakeholders so self-organizing team what
i was mentioning what we were discussing earlier so these teams comes together each of the
team member will have various different capabilities so they contribute at the individual level
and as a team has a whole complement or contribute towards ultimate output and outcome and value
what they need to create and this team should have a clear understanding about the deliverable
what is being done so is that deliverable what features and functionality what they're
thinking is that going to create that value ultimately what is need to be achieved the
requirements fulfillment which is which needs to be happen to the customers so they need
to have that understanding the direction should be clear to the team so there are certain
artifacts to look at when it comes to scrum so let us look at that so now we speak about
the artifacts which are the components of this crumb process that can improve transparency
and understanding of the work so there are three artifacts mainly which we call it as
a product backlog sprint backlog then product increment so let us see what is this one by
one so when i say product backlog so it consists of list of new features changes to be made
to existing features the bug fixes changes to the infrastructure and several other activities
that the team needs to deliver to ensure a particular outcome so this list show product
backlogs becomes with required features and functionalities what needs to be delivered
so the prioritization of this has to happen in what order what needs to be delivered so
the product backlog is the full list which needs to be delivered as part of this project
and as the project progresses a lot of new backlog item will be added to the product
backlog as the dynamics of the particular scenarios keeps changing so keeps adding reprioritizing
additional items to the backlogs are added depending on what are those dynamics so further
looking at a sprint backlog so sprint refers to that short period of iterations right so
which team aims to get a given amount of work done so it helps teams deliver working software
in a frequent manner so sprint could be between one to four weeks long depending on what is
that deliverable is so sprint backlog is a subset of product backlogs so that prioritized
item what is taken into sprint which is a time boxed iterations the sprint backlog contains
the task the team aims to complete to satisfy the sprint goal so what is that sprint goal
so each of those iterations the time box iterations will have a specific objective to accomplish
so the sprint goal is the objective decided for the sprint as an outcome of negotiation
between the product owner and the team so what can be delivered how long it takes to
deliver so when it has to be delivered the target may be given by product owner but is
it possible feasible to complete it there is some negotiation which happens there so
they decide they agree yes we can do it we cannot do it if at all we can do it what is
that it takes in terms of effort time and cost everything is decided discussed so that
objective of that particular iterations is agreed upon so once it is agreed i think team
should first identify the tasks from the product backlog that need to be delivered to achieve
the goal so these stars are then added to spread backlog so there should be an agreement
between both and once it is added once it is agreed as part of that print the deliverable
the output of the sprint would be the one which needs to be completed as part of it
the objectives the goal the results which is specific working software then product
increment so this refers to the combination of all product backlog tasks completed in
the sprint and the value of the increment of previous sprints now when we speak about
lean lean speaks about elimination of waste it speaks about value streams now in each
of these prints as we have a working software being delivered now each of these piece should
keep complementing to the what is the one which is already delivered and what is being
delivered in future so keeping that in mind every deliverable will be implemented or configured
in such a way that there is no specific bottlenecks there is no specific constraints which arises
so this needs to be kept in mind which requires the entire visibility into what is that ultimate
objective we are going to accomplish so in this product increment all those combination
of the product backlogs task which is being done should keep this in mind team should
be very clear about it so i in the first sprint i delivered something in the sprint two i
delivered something but i cannot integrate them they cannot work together it will lead
into the further issues and then complications that should not happen so when we say agile
it's about moving faster fine so responding to change fine but that should not lead towards
further complexity it should make things simpler smoother so scrum is stressing on that part
so an increment refers to inspectable usable work done at the end of the sprint it represents
a step towards overall goal or vision of the project as i was mentioning then the outcome
should be in usable condition even if the product owner doesn't decide to release it
so it should be in usable condition so two things we speak about so one is uh release
other one is deployment now people usually get confused between release and deployment
so release about this part what we're speaking about product is usable so it is released
product is usable but only after deployment user will have an access to use it so that
is the difference release makes that product usable whereas deployment makes it available
to the user to use so this difference people should know so release doesn't mean that it
is already available for user to use so this understanding of the difference should also
be there so that one can understand what it means by release as well and what it means
by deployment that's why when we speak about devos we keep speaking about uh cicd in cicd
we speak about continuous integration continuous uh delivery and continuous deployment so in
continuous delivery speaking about release basically so once it is released it becomes
usable so once it is deployed it is available for user to use and that's about the scrum
artifacts now let us look at scrum framework how that scrum framework looks like in entirety
so what are the components comes into picture already we spoke about the scrum approach
itself what it is now we spoke about understanding artifacts then we spoke about roles in scrum
the activities for each of the roles we understood now where do we see all of this when we look
at a scrum framework so that picture let us see so when we say scrum framework already
we spoke about the product backlog we can see that it is in the left side in the beginning
we have a sprint planning so we spoke about sprint the time box iterations and from the
product backlog the items which is moving towards sprint to a specific sprint what needs
to be delivered which become sprint backlog now the backlog items are taken and scrum
team work on it and does this daily scrum meeting and once the deliverables of that
particular sprint happens then there is a review on it then the increment is delivered
and at the same time that retrospective what was planned versus what is delivered that
is checked if you look at from sprint review so you have a retrospective to check what
is planned versus what is being delivered at the same time the review points will come
and get updated to product backlog as well to the product owner so product owner should
be aware what is delivered what is pending to be delivered and that increment is further
delivered so these increments what is delivered to production what is deployed in the production
should have values that integration which happens both all the increments coming together
to provide that fulfillment of the requirement as well as creating that value what is required
so product backlog is the first step of scrum framework is a set of list of tasks to have
successfully achieved the goals of the stakeholders we discussed that while discussing on product
backlog so further sprint planning happens where the team determines the tasks from the
product catalog they will work on and aim to deliver during the sprint now this is negotiated
understood agreed and then most towards spring to get delivered then sprint backlog are the
tasks discussed during the sprint planning means the previous step and also do the script
planning and then add it to the sprint backlog once it goes to the sprint backlog as part
of the time box iteration sprint the deliverables should happen now scrum team the scrum team
which is actually self-organizing team as we mentioned maybe five to ten nine members
of team working on the task in the sprint backlog and they will also have a daily scrums
where the team also discusses for 15 minutes on the events where the team member synchronizes
activities and plan what they aim to achieve in next 24 hours what is accomplished against
what is discussed in previous daily scrum and then if at all any further discussions
need to be done in the correction of those that can be taken as a separate meeting not
as part of the daily scrum so generally daily scrub meeting would be 15 minutes it should
not go more than that it's an indicative time so quicker updates to understand what is happening
then the sprint review happens where once the sprint is complete so sprint review happens
which involves the team the scrum master and product owner and stakeholders to understand
what is being agreed upon and what is being delivered or reviewed is that fulfilled in
the entirety that is discussed and then during this meeting the team shows what they accomplish
during the sprint it allows time to ask questions make observations give feedback and provide
suggestions right then the product owner also presents the product backlogs talk to the
stakeholders to get feedback for upcoming sprints and about things related to the backlog
now this one sprint is complete for the next print what should be the prioritization so
the product owner has to speak with the stakeholders so that there is a good understanding good
handshake that what needs to be delivered and what is the priority in the given list
then sprint retrospective happens so after this print review sprint retrospective happens
so during this meeting what went well like past mistakes potential issues what are the
new ways to handle them which are required to be done correctly in the next iterations
or next prints needs to be identified data from found from here are incorporated when
planning the new sprint so it works like a lessons learnt what went well what did not
go well what is that we did for those what did not go well so what is that learning we
have in these iterations so how can we ensure that in the upcoming iterations the same mistakes
are will not repeat so those can be uh discussed documented and then consider while moving
to the next spring then the increment is a workable output which is given to the stakeholders
so this is where the user actually sees the workable piece working item and then they
give necessary feedback as well on the particular application piece or software piece then there
is something called scrum board which is used during this flow of scrum right from product
backlash to the creation of that increment so let us look at what is a scrum board which
is used during the scrum practice so scrum board is a physical or virtual tool that helps
team to visualize items in the sprint backlog so it helps in tracking what is being delivered
what is in progress and what needs to be delivered further so it shows all action items during
the daily scrum helping keeping the team focused on tasks that need to be completion and the
priorities of those the scrum board is usually present in a place that's accessible to all
team members it is a visual board right and can be physical white board and stickers or
virtual software tools which can be used and displayed on the screen so the scrum board
is divided into different slots like to do in progress and done so when new sprints are
started the existing board is reset and new scrum board is created so since it is visual
system i think it is taking the thought from kanban so visual system always works effective
because the moment i know i see something is put against my name that i need to complete
this it's quite obvious to me that i will put efforts to complete it so it's a conscious
effort what i will put it works on my consciousness so something which is not visible to me it
is that out of sight is out of mind so i will not work on it so i may there is a tendency
to forget first slide here has to do with user stories
and epics and what i want to do team is i want to before we get into the user stories
i want to go to the whiteboard and i want to just give you a little bit more information that might help us in organizing our discussion
that we're about to embark on here so a word that is not in our slides is themes themes
are epics and user stories grouped together you know similar epics and user stories grouped
together for planning purposes so an epic is big um you would never do an epic or pardon
me a theme in a sprint it's too big so it's used for planning purposes below that i would
put epics epics are low priority large user stories meaning that an epic will eventually
have to be disaggregated into multiple user stories the reason it would be low priority
is because if it if an epic was higher up on the product backlog it would have to be
more detailed that's when you would break it down so epics are usually going to live
at the lower uh priority levels of a product backlog and as user stories are completed
and the epic rises in priority it will eventually be broken down into more manageable user stories
so great big low priority user stories then we have user stories themselves user stories
are functions or features that the product owner wants to have developed a user story
turns into working software that provides value to the customer and um and the product
owner is the customer voice the product the owner is the one who would accept or reject
completed user stories and then there are tasks and a reminder when we were talking
about the sprint planning meeting we said the sprint planning meeting is got two parts
to it the first part is selecting all of the user stories that are going to be included
in the sprint and then disaggregating each of those user stories into tasks that's done
in the sprint planning meeting and then those tasks are the things that are actually then
done when the work of the sprint begins user stories can be estimated in story points or
ideal days most teams favor story points they might start with ideal days but they will
then usually end up going to story points tasks are estimated in i ideal time which
is usually hours okay so now back to our slides so at the top left a use case could be an
example of a user story so it's something that the user wants to do and how the system
should support it like a use case could be um select and pay for items in a catalog now
that could actually be an epic or maybe a theme because maybe it would get disaggregated
into log on screen catalog shopping cart and checkout but so the use case could either
be a standalone user story or it could actually be a number of user stories that would result
from it below that requirement it could be a functional requirement a technical task
or even a bug fix so i'm going to go back to the whiteboard and a product backlog is
going to have a lot of user stories that come from the customer right whatever the customer
wants then but the team may know that it has to do some development work in order for the
user stories to even be able to work you know there's some system level non-functional requirements
that need to be done and so there could be tech user stories and then can you see this
low i can't see your chats but then there could also be defect user stories there could
even be risk user stories now what could happen is that um the product owner ranks these in
priorities so this one first and that one and that one and the team says well the only
thing is is that we have to do some development work before we can actually do user story
2 and so what we really need to do is insert that before the the second priority user story
and so the priority of the user stories in the product backlog while it might start with
just being you know simple functional user stories coming from the uh product owner it
will evolve until it includes some other things that are also considerations when it comes
to priorities because of you know successor predecessor relationships dependencies and
things like that are considerations a user story be uh back to the the screen
bottom left now the user story can use a fictitious user or a persona to help uh the team or the
the team and the product owner to get an idea of okay who's going to be doing this function
what are they going to need in order to be able to complete the function etc so you try
and come up with an actual well a fictitious but a person who's actually doing it to kind
of get out of the realm of you know listing requirements and you know specs and things
like that and say okay what's the user experience need to look like top right template a portion
of a user story is um let me back up so a user story card is usually going to contain
a brief description of the user story using some kind of a meta language format like we're
suggesting right here as a user or persona i want this feature so that i can so not unlike
our estimating session here as a frequent traveler i want to eat grapes so i can be
healthier in the one that we didn't do the inventory system as a customer okay there's
a user i want to get cash back so i don't have to wait in line at the bank okay here's
another user story as a consumer i want the shopping cart functionality to easily purchase
items online and maybe that could be customer as well as an executive right as a suit i
want to generate a sales report so i know which departments need to improve their productivity
as a buyer so you can see i tried to come up with these different roles right here executive
buyer sales rep etc and that's the format as a type of user i
want some kind of goal um or feature and uh so that's some kind of a reason um the below
that connect connect the dots by writing all of the user stories necessary to uncover the
entire use case so like we were talking about right here if you want to be able to purchase
items online from a catalog that might be a multiple user stories in order to support
that use case and so of course we would want to be able to connect the dots and see where
all the user stories fit in into the overall goal of the project or release and the stories excuse me are grouped to form an epic or higher
level story so epic or theme stories can then be split into child stories or tasks and so
that's what we were covering before right you see you have um themes up at the top that's
the biggest grouping if you will used primarily for um you know high level planning purposes
so you have your themes then you have your epics which are large user stories low priority
and they're going to have to be broken down into smaller user stories like in the question
that we had at the end of the the last section where the product owner needed something done
and the team said well based on the size of this user story it's going to take three sprints
to do well a user story has to be small enough to be completed within a single sprint so
a sprint can contain more than one user story but a user story cannot span sprints so that
feature or function that was in the question was probably more like an epic it was something
that would need to be disaggregated into smaller user stories or perhaps it was more of a use
case that would need more than one user story in order to actually deliver the overall use
case let's see as a product supervisor i want to see an unfinished part list at the end
of the day so that i can reallocate work the next day great user story description well
done viraj did you hear that team as a product supervisor i want to see an unfinished part
list at the end of day so i can reallocate work the next day that is a well-crafted description
of a user story now here are some things that i want you to
memorize you were hoping i was done with the memorization part so i want you to um remember
that we have to invest in our user stories and i was going over to the white board and
i didn't change cameras so let me do that i recommend um you know figuring out how you
memorize best so that you can if um well not if you wanted to what i recommend is being
able to write out all of this stuff on plain white scrap paper in about 14 minutes because
that's the amount of free time you have in the tutorial when you're at the uh or when
you're taking the test um exin does a little bit different you maybe won't have a tutorial
the only time you have a tutorial is if you were at a center taking a test exam has other
options like you can do a paper-based test um where you get a third party you know a
buddy or somebody who will agree to sort of proctor the test for you or you can do it
on your laptop all by yourself and they have software that watches you while you're taking
the test and they require you to take the laptop and do like a 360 so that they can
verify that you don't have any cheat sheets up on the wall or anything like that but the
point is is you got to have this memorized whether you're going to dump it out on the
paper or not when i took the test i actually did the paper-based option and that was because
of some kind time constraints and it was the quickest way to get me into the test and so
i didn't write out any of the stuff i'd memorized but i had it memorized and i had it memorized
well enough that i could kind of recall it in my mind's eye okay so we're talking about
user stories and you have to invest in your user stories you know i like memorizing things
by creating these charts that have the first letter of the word or phrase that you're memorizing
in a separate column and then i make up a story you know that reminds me that i've got
to have i-n-v-e-s-t this one is pretty easy probably just invest works but so let's go over that i stands for independent
independent meaning that each user story stands on its own you don't have when we're doing
scrum you don't do a user story that won't result in working software we just talked
about the description of user stories right so it's a user that needs some kind of functionality
for some kind of a reason and they're all independent will they work together of course
they'll work together if that's the necessity but if you developed a logon screen you could
demonstrate working software for the login screen there might be another user story that
is you know has to do with displaying the catalog and being able to flag or select items
that you want to purchase but there'd be working software for that would they work together
yes but each user story would complete or result in some kind of working software and
they have to be independent negotiable negotiable in the way the user story is going to be implemented
the product owner doesn't dictate to the team the team doesn't say it it's only this way
and we don't want to hear anything from you so there are discussions about the size and
implementation for each user's user story so the product owner can't make it so detailed
that there's no room for discussion and the possibility of you know the team coming up
with solutions other than what the product owner was attempting to dictate v stands for
valuable meaning each user story has to create value for the customer or the end user e it
has to be estimable as an estimatable except estimatable is not really a word it's estimable
um and s is for small has to be small enough to be done in a single sprint if we're doing
two week sprints it has to be able to be done in two weeks or less if we're doing four-week
sprints it could be a larger user story but it would still have to be done in four weeks
or less and then the last one the t is testable every user story needs to be testable and
it needs to be testable at two levels remember our triangle needs to be testable at the intrinsic
quality level unit tests etc and also testable at the extrinsic level which is the customer
point of view which is acceptance so every user story uh has to be testable okay so that's invest and so let's add that
to our list of things to memorize invest and then the next one we have here is the three
c's of a user story so the first c team is card so user stories should be able to be
written on a four by six inch index card or some media similar to that card the the second c is conversation the user
story card is the item that is used for the team and the product owner to talk and discuss
in order to make sure that the product owner and the team are on the same page when it
comes to what is actually supposed to be developed and what you know so what it's supposed to look
like at the end which leads us to the third one which is confirmation each user story
essentially has to have acceptance tests in it itself so card 4x6 conversation that's
the starting point that's where the team and the product owner discuss and then eventually
there will be acceptance tests included on the user story card in order to be used during
the sprint review to assure that it's acceptable that there's confirmation okay so oh let's
add that to the memorization list so three c's all right now i've got an example
here of a user story card so we're looking right here and if you were to go out on the
internet and search um user story cards um they would be similar there would be some
differences of course but typically what you're going to have is
you're going to have a title or a name for the user story and then there's going to be
some kind of unique identifier like user story 321 then there will be the description like
we just talked about as a librarian i want to have the facility of searching a book by
different criteria so that i will save time while serving a customer then there might
be some other descriptive words or links to other information that might be necessary
and then there would be acceptance criteria or tests sometimes these get included on the
back of the card but the point is is that they are on the court on the card rather then
there will be an estimate of size it could be ideal days or story points as i mentioned
most teams do story points that's more likely what you'll be tested on as opposed to ideal
days but you know we'll cover both so you understand the difference is there is probably it's not listed here but
there's probably going to be a value point assignment this is where the product owner
kind of determines in a relative way the value of the stories just like we were doing in
planning poker the product owner might say well this story is twice as valuable as uh
this other one comparing them together and this is what um these value points are what's
used to prioritize the user stories that's supposed to be a v as in value points and
then typically there's also going to be a indication sometimes it's just by colors it
could be words that has to do with you know where the story came from did it come from
the customer that would be considered a functional requirement if it came from the team that
would be from the technical domain i'm trying to write where from you know it's not me team it's the mouse clearly
it's hard to do that that's from where from um here it's got customer tech you could also
have defect you could maybe have risk and then there's also going to be an x factor
which would be some kind of word probably like stable erratic incomplete something like that
to so the team is designating the user story in respect to the amount of uncertainty or
risk that's associated with that user story and because all of that's a part of the story
right the story is going to be turned into working software there may need to be some
efforts to actually figure out how to actually do that user story so that's the x factor
over to the right here on the same chart we have some comments about if you are using
a software package excuse me like trello or jira or something like that excuse me the
user story cards will generally be able to contain more information using you know dynamic
links and things like that could even include things like responsible team member or depending
on how you're doing it you would break the user story down into tasks and you might have
team members assigned to various tasks for the user story um okay so that's typically what a user story
card is like sometimes they're cards sometimes they're like on sticky notes and they're put
up on a kanban board if you're using kanban to track the project if you have a story that is too large to be
completed in a sprint it's going to have to be subdivided or we call it disaggregation
into smaller user stories and there's uh three ways that we're proposing here that you could
go about doing that you could split it based on operational boundaries for example as an
operator one needs to manage reservations which could be split for example there could
be one portion that is uh that has to do with making a reservation another one that has
to do with modifying it and yet another one that has to do with canceling it so that could
be split into in this construct here three separate user stories you could also separate
based on exceptions or cross-cutting concerns for example in the beginning develop only
one main path like accept repayment for a loan then address exceptions like what if
a person overpays then come up with a user story that recognizes that and processes a
refund and or gives the option of allocating the overpayment to a future payment or something
like that and then also um ads on other concerns like the check access restrictions or record
name of operator so maybe you know when you're working on accepting payments or processing
refunds it's going to check on um who the operator is or track that so that if at a
later time you know who was it that gave this uh refund here well you could look and see
you know okay the the operator's name was recorded or maybe you put some restrictions
so that maybe not everybody um is allowed to do a refund and so you would have levels
of users that have different privileges okay and then down at the bottom split based on
data boundaries for an example you know as an accountant one needs to enter balance sheet
information which could then be split into summary information and separately um uh receivable
details or you know maybe you could have ap you know so you could have different portions
of the overall balance sheet activities that need to be done
so enter ar enter ap etc makes sense so just to kind of prompt you give you some ideas
about what to do [Music] in a scrum project if you have the scenario arise where a user
story is being estimated by the team and it won't fit into a sprint it's too big now when
it comes to determining value for user stories this is primarily owned by the product owner
right and it always comes back to money but money you know the value can be looked at
from different points of view so new revenue obviously you know getting new customers and
having them buy stuff well below that there's another consideration incremental revenue
uh so somebody's in the process of placing an order um maybe there are some premium features
that could be add-ons at that point in time or maybe added later on so you have an existing
customer who actually buys more of or enhanced parts of the existing thing they already purchased
or are in the process of purchasing retained value so this is um you know retaining customers
so that they don't go to a competitor and then the bottom one is operational efficiency
you know how could things be done to speed up the process of whatever it is so that the
cost of delivering the product is reduced so this then leads us to a discussion about
priorities recognizing that there are some priority concerns that come from both the
customer domain as well as the technical domain and there are some prioritization models if
we look right here there is value-based prioritization and the hierarchy of that would be high value
followed by high risk followed by high value and then low risk followed by low value and
then low risk so you know we might have written this a little bit differently but that's value
based prioritization and this is primarily the product owner with maybe some input from
the team just simply deciding what he or she wants them most listening to the team say
well you know there's some you know greater risks with this user story than that and so
you'd probably want to uh persuade the product owner to take care of high-risk stuff first
because that would have a uh excuse me sorry an impact on the future
things that need to be done there's the kaya the cattle model which looks at each of the
user stories and classifies them as being mandatory linear or exciters and the mandatory
items are those user stories that are musts and they'll never move beyond move the customer
or the end user beyond neutral it's if they're not there it creates dissatisfaction if the
the you the product owner and the team has done a good job in identifying what are the
mandatory or threshold items you would see that it just gets it to neutral that's what's expected
for the product linear items user stories are those user stories that as they are implemented
progressively throughout the project and added to the feature set it will linear increase
customer satisfaction and it can be you know in their absence dissatisfaction all the way
up to high implementation creating a great deal of satisfaction for the customer and
then the third category is exciters and delighters and those are features or functions those
are user stories that are not mandatory and the absence of them will never result in satisfaction
going below neutral but by adding them you could create excitement and delight for the
customer these would typically be things that are features that would be included in a premium
version of the product or maybe add-ons that are promoted you know at the point of sale
you know if you thought about this because it'll really help you or whatever so that's
the canon model and then there's uyghur's relative weighting method and this is all
using numbers so each feature is given a value for its benefit and it's penalty given a value
for penalty meaning what's the pain if that feature or function is not included and then
there is um the cost side and the risk side and then those
are all calculated together and that results in excuse me a ranking or a hierarchy which gives
you the priority for the user stories we also talked about moscow didn't we did
we talk about moscow moscow is another prioritization model must could i said that differently must
should could won't moscow mscw must should could won't and we talked about that one thank
you for that confirmation does it seem like a long time ago or is it just me i know it
was just last weekend but it's like last year okay so now let's talk about velocity um uh
priyanka that is exactly right um so velocity is the capacity of the team to complete work
in a single iteration so the team has estimated the user stories
uh for size or ideal days and um the sprints are going to be three week weeks in duration
obviously not all user stories can be completed in a single sprint and be done with the project
well i guess maybe i shouldn't say obviously while i'm saying that i'm thinking well maybe
you had a very small short duration project so you could but the point is is that it's
the team's capacity to complete work in a given sprint and it is an observation it's not a prediction so if
we're working on sprint five and we're working on determining what our velocity is then it would be the average of the previous
four sprints if there were any outliers you you would disregard
those and so it's an observation if we look over
to question or uh box number two here velocity is used to deal with um determining how many
user stories we're going to include in a given sprint and also how many sprints are we going
to need to create a release or a set of user stories and here's an example in box number three a team completed five
user stories that were sized five three eight thirteen and two two user stories each size
five were left half complete what is the velocity of the team and the answer is either going to be 31 or
36 31 is the sum of the completed user stories um if you were 36 you were claiming half of
the two that were five so that would be a total of 10 so you claim half of it which
would be 5 would take you to 36. but it's not going to be 36 because the only thing
that counts towards progress is working software so even if the team had finished 9 out of
10 story points for a user story meaning it's almost done and then the sprint ends that
doesn't get counted towards velocity and you don't mess around with velocity um
you can mess around with your estimating and you can mess around with um you know what
user stories are going to be completed in a sprint but you don't the the velocity is
not variable it is what it is based on past performance when it comes to levels of planning we have
what's called the planning onion and let me walk you through this here up at the the broadest
area is the vision level so the vision level that's the suits right they're the ones that
have the strategy and objectives for the company and where it's going and so they have that
overall big vision for the company which is likely going to include products and each
product should have a roadmap my example of that website that i'm working on has uh three
versions which make up the product roadmap version one is the free site version two is
the membership site and version three is the um the pay referral commission's version of
the site and the product roadmap is then supported by releases so for my project i have three
releases so all of the user stories needed for the free version are in release one all
of the additional user stories that are needed for the paid version the subscriber version uh and
then also for version three those are all releases three releases and then for each
sprint we will be pulling user stories from the release that we're working on a release
is likely going to take multiple sprints and and then the sprints are populated by the
individual user stories which are then just aggregated into tasks and we do the excuse
me the daily scrum which is the daily level of planning and coordination so we call that
the planning onion we already kind of talked about the release
and road map concept here so let's just review this quickly predatory's high level ethics
and determine goals and releases so we'll use epics and themes in order to group things
together you know what should be included in what's released so what are the goals for
the releases then the first bullet point established goals of release based on market demand regulatory
needs or customer expectations for each release you want to estimate the target stories repeat
until the target stories are assigned an iteration length i should that's it's blending some things
here um be able to estimate velocity and then assign stories to the sprints so we keep estimating
the user stories and we keep organizing uh that until we can do that we can come up with
an iteration length or sprint length and then figure out what our velocity for each sprint
is and then uh assign stories to the uh the sprints uh the the next bullet down iterate
until the user stories and release date meets conditions of satisfaction so that's a definition
of done or acceptance for the release and try not to pack too much into a release backlog
so just like you would not want to pack too many
user stories into a sprint you want to have the timelines appropriate and what are included
in the events make sense okay so here's a bit more about release planning on this slide
here you've got the product backlog here on the left and then we might come up with the
release plan which could be flipped and could be looked at horizontally and you probably
plan um about three releases in advance or at least you're doing more of the detailed
planning on that because things are going to emerge when we do you know sprint one that's
going to help in sprint two and things that happen in sprints one and two that are going
to help release three and then you've got um you know your subsequent releases where
we're just doing very high level planning it's called rolling wave planning where we
do detailed planning for things in the future in canada with doing high level planning for
things in uh the future did i say that right detail planning for things in the near term
and tandem with high level planning for things in the future and we talked about deciding
as late as possible i believe meaning that it's better to actually plan the later releases for purposes of making sure we have more information
the most information available okay so estimation let's start at the top left the principles
behind estimation understand the cone of uncertainty which is an estimate or best guess to begin
with and then progressively becomes more accurate in fact let's just take a break and look at
the cone of uncertainty so at the very beginning of a project there's going to be a high level
of uncertainty if i were to draw this chart i would make it a little bit more like this so clearly you're going to de-risk the
project as early as you can and then eventually all
risk disappears when the project is done risk is uncertainty okay below that the only estimate that matters
is the one given by the team supported by this uh comment here nothing
is impossible for the one who doesn't have to do it so the product owner is like keem
come on you can do this the team's like no we know what our velocity is no the product
owner says i'm telling you there's no way that that can't be done i know you can do
it i trust you i believe in you but the product owner doesn't have to have to do the work
okay copyright overestimation and underestimation is always going to be an issue that we deal
with it's more likely that we will underestimate than overestimate and by looking at our velocity
from iteration or sprint to sprint there could be some information that is showing us that
we're underestimating for example meaning we're thinking we you know the user stories
are smaller than they are and that we can get you know a certain number done in a sprint
and then there's a fail well that would mean then that would be discussed during the retrospective
and then we would do something different going forward which might include doing some re-estimating scrum estimating is not necessarily more difficult
however scrum exposes bad estimates sooner which is a good thing when we were doing our
um planning poker you could see that um the first time as a team you know we didn't know
each other we didn't know everybody's thoughts and concerns and those kinds of things you
know get shared and absorbed as a project goes on and so there's a higher awareness
of that so what we would say is that using estimation techniques scrum estimation techniques
might be more inaccurate at the beginning of a project but they will quickly become
very accurate as the project advances forward which is their question here can velocity
be increased over a period of time for the project yes it can now it's not that it can't
it will increase if the team is learning how to work together better and better you would
expect that if i can just use my mouse here if we were tracking velocity so this would
be points completed over here let me just do pts for points and down here is time and we go from sprint to sprint right you
would expect that maybe you know the first couple of sprints the team would be learning
how to work together and there would be a steep curve and then it would kind of flatten
out and maybe have you know a slow rise going forward as the team emerges as a high performing
team they get better at their cross functional behavior you know somebody's shake the team
just keeps chugging along um other things you know just um oh sorry there i bumped a
thing on my screen there um um so the team you know learns how to work
better together and you know their estimates become more accurate etc and you would expect
a high for a high performing team to have a a result like this for velocity where there's
quick improvement and then it kind of stabilizes and then begins to kick upwards okay we talked
about the cone of uncertainty let's talk about ideal time when we do estimating for user
stories we do it in ideal days when we do estimating for tasks we do it in ideal time
which means hours i think that's on the whiteboard or it was on the whiteboard oh it was on it
um so ideal time is the amount of time it takes to complete a piece of work but that's based on the notion that the team
member or members are available to do just the work with no distractions or anything
at all so assuming that um priyanta could sit down at a keyboard and code for eight
hours without taking a break for lunch no phone calls no discussions no meetings of
any kind just work eight hours how much could be done in that eight hours by priyanka that's
what ideal time is but the thing of it is is that there is no such thing as somebody
being able to spend every minute of every day only doing work there will be distractions
so it has to be converted into elapsed time now we don't convert it to elapsed time at
the user story level but we do convert it to elapsed time when we are dealing at the
task level and what that looks like is you know for each team member you're going to
have to do it separately because some team members have more distractions than others
some might have other duties that pull them away whatever the case may be you determine
how much time in a given day a team member is available to do work so say it's five hours
out of eight for one maybe it's six hours out of eight for another maybe it's four out
of eight but you figure out what it is and then you take the average and that average
availability is used then to convert ideal time into elapsed time i should have circled this box here because
we talked about this as well and then i already mentioned this here only considers actual
work time not the distractions so that's the concept of ideal time when it comes to story
points it's different than that they are a measure of size relative to each other so
we were doing planning poker this morning where we were looking at grapes versus apples
and then we were looking at oranges and and what else we have watermelons and coconuts
and we weren't trying to figure out how much time it would take to eat grapes as opposed
to how much time it would take to eat a coconut it's clear that it's going to take longer
to eat a coconut because there's more effort involved so we have a sense that it's going
to take more time but comparing the coconut to our baseline of two right we came up with
a baseline of two for the smallest user story we compare eating coconuts to that baseline
and we say okay you know what it's going to take more effort to eat the coconut than it
is to eat grapes or apples so you can do it like we did you can also
triangulate for example when we did our planning project this morning or this morning for me
rather at the beginning um oh that's not it that is the daily stand-up
here it is if i had said team i want you to pick a small user story a medium user story
and a large user story and then we would then compare other stories to those three and so
we would kind of triangulate on it let's say that we did you know two was small i'm sorry
i'm saying that wrong grapes was small apples were medium and coconuts were large well if
we then looked at orange and we said well you know orange is um smaller than apples
but bigger than grapes so we would know this would fit in between grapes and apples and so let's say you know we had apples at
five and grapes at two then we would say an orange is probably going to be three and the values you know now i used in our
example the modified fibonacci series uh what we do in scrum and agile if we're using story
points we're going to use a non-linear scale for the values so down at the bottom here
there's the modified fibonacci sequence the way the fibonacci sequence works by the way it's the the value is the sum of the two on
the right so let me break this right here because this is a modified fibonacci so 13
is five plus eight eight is three plus five five is two plus three and three is one plus
two if we were doing the real fibonacci series this wouldn't be twenty it would be thirteen
plus 8 which would be 21. um i i don't know why some use modified fibonacci and others
not but that's just kind of a common thing to do if you're doing planning poker you give
everybody seven cards two three five eight thirteen and twenty um another non-linear
scale is doubling one two four eight sixteen um you typically don't go too far to the left
with the values because that either means that you're being too granular or you've got
stories that are probably too big and they need to be disaggregated now somebody just
chatted here should some buffer time be included in the actual estimates let me answer that question first by going
back to ideal time and then i'm going to come back to story points and answer the question
when we're estimating in ideal time we don't add a special amount of time that we would
call a buffer we just allow for the distractions and the interruptions which could look like
a buffer right you're saying you know you know priyante if um based on your duties in
the organization and our uh work day of eight hours you're typically available to be doing
your project work five out of those eight hours so when we are converting ideal time
to elapsed time um you know we will be building in extra time based on distractions and interruptions
we would not call it a buffer but that's essentially what we're doing now when it comes to user
stories that we're using story points it is different the points are for the entire amount
of the work and why might we need to have some extra time for a user story well it's
likely going to be driven by uncertainty there might be other things that impact it but that's
the main thing sorry team so when the team is estimating
the size of the user story they will be including in their discussion and estimates any extra
time or buffer time that would be needed for that user story to be completed so do we accommodate
uncertainty when we're using story points yes we're looking at the the x factor and
if we've got an unstable user story then we're probably going to say you know this is going
to be a bigger user story than one that's similar but has a much lesser level of uncertainty
um so that's the story points let's compare the two um ideal time uses things like hours and days
which is easier to explain outside the team right the suit's like things in days and hours
everybody's estimate may be different not a bad thing it's easier to do at the beginning
because we're oriented to think about time and it does kind of shine a light on wasted
time story points are harder to explain outside the team you know the suit says well how long
is it going to take to do user story and our answer is um well that's a 10 user story point
user story and the suit's saying what does that mean tell me how long it's going to take
so the suits have to be converted to uh story points now here's the thing it's a lot easier
to get consensus when we're estimating in story points and once we get good at it it's
going to be much faster we have to remember it's not comparable across teams so you know
18 working together will have its own kind of system for sizing the stories and another
team that might even be working on the same project will have a whole different uh scheme
and so if the velocity of one team is 25 and the velocity of another is 50 it doesn't mean
that the team with the velocity of 50 is able to do more work than the teams whose velocity
is 25. and we did when we got our day going we started
with a planning poker exercise and so you know we used all of the team members so we
selected the team the product owner was there to answer any questions um the team discussed
each of the story cards and then decided what their vote was going to be and then everybody
voted at once if there were outliers they were discussed and the reasons for that uh
those variances those outliers were then part of the discussion and then we did another
round of voting and we would keep doing that until we had our estimates converge or we
reached consensus on them okay so advantages of planning poker it's
fun it's quick it gets the whole team involved the the team understands um a little bit about
all of the stories everybody contributes his or her expertise and the discussion during
the estimation provides clarity in the direction approach and even a bit of design if we were
in the same room team and we were doing a planning poker activity like we did at the
beginning of our day together we would be able to you know model it a little bit better
or if we tried to unmute everybody but you could hear the background noise i've tried
doing and it doesn't really work but you get the idea that if the team's discussing and
things like that you would actually get to the point where your estimates would converge
and the team would say okay this user story size is you know whatever it is okay so we
need to wrap things up for the day so we are ending right here and that means tomorrow
when we get together we're going to be doing slide 20. you're starting with that which
is affinity estimating and let's see affinity estimating we go through that we're going
to talk about tracking progress using information radiators and then we're going
to talk about what we do when we find variances between the plan and the actual results and
then we'll have our quiz now let's talk about the values of scrum now this is different
than pillars this is values so there are five values for that and this is something that
i want you to memorize i'm going to switch my cameras here and go to the whiteboard and
we're going to add to our list oh wrong color you can tell i'm a project
manager because that would bother me so the five values of scrum and there's an acronym you
can see that on the screen right see force okay so five values of scrum and c f o r c and you kind of know my style
here you don't have to do it this way you know whatever works for you but have some
kind of a strategy for memorizing things will probably serve you well so the um the first c is commitment the next one there are four four f is focus o is openness set two ends or one i don't know openness
we'll blame it on the marker if it's not right um r is for respect and the last c is courage and so there's your
little chart right there and let me just briefly go over these none of these will be a big surprise here
we've talked about some of them already in one context or another so the for commitment that means the commit
the team is going to commit to deliver value to the customer um they're on board there's
the buy-in all of that's there focus the team is going to focus on the few important things at a time so we're going to do time boxing
we're not going to do things broadly specifically focus on a few things at a time o is openness
that's analogous to the t transparency and the pillars meaning we're going to be completely
open in sharing information about the project our own opinions our fears our concerns etc
r stands for respect and that's kind of a 360 view we respect ourselves we respect others
we respect the concepts that we are using as part of scrum and um um and and we respect the other stakeholders
as well 360. and the last c stands for courage and that's the courage to make commitments
uh even when we're in an uncertain environment um courage to deal with fear that comes from
a failure courage to share disagreements openly yet respectfully courage to participate in
debating technical approaches etc okay so now let's go to the scrum lifecycle chart
and what i want to do is i want to elaborate on this just a little bit and i'm going to
try and use my mouse to do some some additions to this first of all we have the product backlog the
product backlog has to be kept current and we call that grooming grooming is adding user
stories and removing user stories from the product backlog product backlog is the scope
of the project the product owner owns that the team assists in that effort related to
grooming is pruning pruning the backlog is prioritizing and re-prioritizing so the product
backlog is pruned and groomed regularly throughout the course of the project now there is a meeting
that takes place right here which is called the sprint planning meeting can i just do p s p here
sprint planning meeting okay that is one of the ceremonies or events that takes place in scrum in the um the sprint
planning meeting it is a time boxed event and it is time boxed to two hours for each
week of the sprint so in our example here we have a 30-day sprint so if we have a four-week
sprint then our sprint planning meeting will be eight hours in duration and two things
happen during the sprint planning meeting the user stories that are going to be included
in the sprint are selected right they're put into the sprint backlog which is a subset
of the product backlog containing the user stories that are going to be completed during
the sprint and the second thing that happens during the sprint planning meeting is the
selected user stories are then disaggregated into tasks and estimated once that's done then the work of the sprint
begins there will be a daily scrum like we did at the beginning of our work day together
as our team and then at the end of the work of the sprint there will be the sprint review
the sprint review meeting or ceremony is also time boxed and it is time boxed to one hour
for each week of the sprint so for doing a four week sprint the sprint review meeting
would be four hours in length the primary purpose of the review is to showcase and demo
the software and get feedback from relevant stakeholders and allow the product owner to
say i accept or i reject the work that has been done then after that is the sprint retrospective
now this is where the team asks and answers three questions what went well what did not
go well and what are we going to do different going forward regarding the previous sprint
that was just completed and the ones that is is just coming up um and then the uh the
sprint itself will result in working software or value for the customer and then of course
everything goes back and repeats for as many sprints as necessary to complete the scope
of the project um let's see i see a chat here how similar or different is the product backlog
to srs software requirement specs document which is widely used in projects um it's different
and if you will hang on to that question we're going to have a discussion later on about
user stories and that will help you understand uh the differences and we'll get into the
user stories that come from the customer and user stories that come from the text domain
and that will help answer your question so you okay hang on to that okay great thanks
okay so a little bit more detailed view of the scrum project life cycle now let's talk
about a couple other things here when it comes to um a sprint there are some things that
affect the duration of the sprint so the team is going to have to decide how long each of
the sprints are going to be and things that are a factor include the stability of the
product backlog if the product backlog is changing a great deal um then that's going
to argue for shorter durations um because there's uh a high level of uncertainty and
so you have a greater amount of control on your project if you have shorter sprints now
on the other hand another factor is the cost of iterating every time we do a sprint there
are costs associated with the sprint planning meeting the sprint review the sprint retrospective
right people show up to those meetings you got to pay them and um excuse me so there
there is an overhead cost to actually doing sprints the goal of the sprint is working
software at the end the end product should be near releasable or potentially shippable
now there might be working software that the product owner isn't going to want to release
maybe because it as a standalone component of working software for the system doesn't
create any value or any usability for end users and maybe you wait till the end of a
release before you release everything but the idea is it's working software and it could
be released if the customer wanted to do that um sorry just dropped something i see a question there i will circle back
to your question in just a sec the sprint duration and deliverables do not change once
the team has committed this is another one of those things that has to be viewed as absolute
when we're doing scrum so if we say that we're going to do a two-week sprint and we select
five user stories based on our velocity or capacity once that decision has been made
the duration of the sprint does not change and we do not add or remove any user stories
now it could be possible for the product owner to cancel a sprint but that would be extreme
that would be because there is such a major change to the product backlog that the work
of the current sprint is going to be completely irrelevant you don't change the sprint you
cancel the sprint and then the bottom one here the sprint begins with planning and ends
with review and a retrospective and there was a question here are there any issues with
combining the retrospective and the planning ceremonies and the answer to that is yes now
could they be combined depending on the environment the answer is yes and the way we would arrive
at whether or not it would make sense is who's going to be participating but they would be
separate agendas so the agenda for the retrospective is what went well what did not go well what
are we going to do different and the mandatory participants for that meeting are the the
team the scrum team is the scrum master going to be there likely as a facilitator is the
product owner going to be there maybe maybe not if the product owner is there you know
the product owner could maybe answer questions and help clarify but the product owner does
not weigh in on what went well what did not go well and what are we going to do differently
that is all owned by the team in the planning meeting the product owner has to be there
and the product owner is the main driver of that meeting the product owner is talking
about or dealing with the priority of the user stories the team's weighing in maybe
there's some dependencies that need to be considered but the product owner has to make
the hard decisions with regards to what's going to be done in the next sprint based
on the constraints from the team like velocity and technology and sequencing and things like
that so i kind of answered that from a real world point of view yes it could be it's not
desirable on the test they are completely separate did i get you there i'll keep my eye on the
chat box make sure i got that answered well enough for you and let's move ahead okay the
sprint planning meeting this is looking right down here this is conducted at the beginning
of a new sprint it's attended by the team the product owner and the scrum master and
there are two approaches to deciding what's going to be included in the sprint it can
be based on commitment and it can also be based on velocity and the goal here is to get team buy-in make
sure that there is um clarity between the team and the product owner as to what the
definition of done looks like for the user stories that are going to be included in the
sprint and of course it should be realistic and achievable and you know there can be a
little bit of of an issue where you've got you know a well-meaning product owner that's
driving really hard and the team says you know we can do these sprints and the product
owner is saying no come on you got to do at least one more i got to have this one in this
sprint you could get a question like that and it might be what would the scrum master
do if you had a dominant product owner that's trying to persuade the team to do more than
the team thinks it can do and that's where the scrum master comes in
the scrum master plays the role of the mentor the coach and uh you know assisting in the
resolution of those kinds of issues without deciding the scrum master is not a decider
the team decides uh when it comes to how and the product owner decides when it comes to
what okay the scrum meeting daily scrum we've talked about it right the entire team attends
the meeting could the product owner be there yes does the product owner need to be there
no sometimes the product owner can be uh you know an impediment to the meeting but would
be welcome but if the product owner started asking questions or became the focus of questions
being asked the scrum master would have to help facilitate a change because that would
not be effective for the daily scrum duration 15 minutes we talked about that and the agenda
what did i do yesterday what am i going to do today and what are my impediments the sprint review now who attends it's going
to be the team the product owner the scrum master and potentially others so optionally
others you know that we would want to get feedback from would be end users operations
folks pursuits all of those would be welcome depending on the relevance of the software
that's being demoed and being subject to the acceptance testing and the
product owner you know giving the thumbs up or the thumbs down when it comes to acceptance
the duration for this we mentioned this before it's not just a flat two hours it's one hour
per week so if you did a four week sprint you would plan on the review being a maximum
of four hours in duration the agenda is to demo the completed software get feedback and
then see where we are when it comes to the the release plan the retrospective who is
there is attended by the team and i would modify this slightly and i would say this
is the the mandatory group that needs to be there optionally the scrum master would be
there potentially you could have an external facilitator the role of the scrum master would
be the facilitator now um a good scrub master being a facilitator in a retrospective would
have some knowledge of control charts the five why's ishikawa diagrams things like that and although
the scrum master would not be participating in the actual use of the tools the scrum master
would be facilitating the effective use of those tools when it comes to duration the
rule is 45 minutes for each week ooh that was a good four that was kind of a lousy five
so if you had a uh two week um uh sprint then you would have an hour and a half retrospective
max and what's the purpose there's the agenda for the retrospective three questions what
worked well what did not go well what are we going to do different and it's not just
a chat session well that would be part of it you will use tools and techniques um like
some that i mentioned control charts um ishikawa diagrams um five why's there's a number of
things that you might use in order to surface uh assignable causes for issues so that we
could then come up with a resolution to those this is where continuous improvement um is
uh going to happen um you know continuous improvements the result of other things but
this is the main thing and if you were getting a question about the relevance or the necessity
of retrospectives there is no equivocation you do a retrospective after every sprint
if you don't do a retro if you don't then there's no improvement you know things just
stay static okay so we talked about the four main ceremonies right in a scrum project sprint
planning you with me daily stand up the sprint review and then the sprint retrospective all considered mandatory for effectively doing
scrum and not doing them or one of them would be considered a sale okay artifacts that we use when it comes to
scrum we've talked about the product backlog we talked about the sprint backlog there's
also a release backlog depending on the size of the project it might be advisable to group
user stories into releases if you have a product road map your releases would line up for that
for example i've got a a real life project that i'm working on and my product road map
is um got three versions it's a website the first version is free the second version includes
a membership component and the third uh version includes a referral commission uh portion
to it and so i will then do three releases i'll have all the user stories that were resolved
in version one all the the user stories that really result in version two so that's what
the release backlog is and so if you look at it in sequence the product backlog is the
overall scope of the project the release backlog is a subset of the product backlog and then
the sprint backlog would be a subset of the release backlog the product backlog might
look something like this it's a list of user stories that are written by the product owner
and are going to be developed by the team members and didn't we have we had a product
backlog for the thing that we did this morning right so here's another example of a product
backlog this is more of a list and just has the title
there would be a user story card for each of the items in the product backlog but the
idea would be it would be prioritized there could be user stories that are added or removed
depending on what the product owner wants product owner owns the product backlog that's
a given does the product owner create all the user stories for the product backlog in
isolation no absolutely not because there are technical considerations that the product
back or the product owner might not um even consider the product owner's perspective is
more the customer side the end user side and so the product owner might not even think
of things like security or architecture related things and there might even be user stories
that come from the technical domain that need to be developed before some of the products
owner's user stories another artifact is the definition of done the definition of done
is primarily a checklist and this is what forms the agreement between the product owner
and the team as to when we consider something completely done and if we look down here it's
um uh where's my i'm looking for my cursor it says here it's usually prepared by the
scrum master in consultation with the team that is i would modify this slightly the definition
of done is really driven by the team the see the scrum master is never a decision maker
if you have a scrub master that's saying we have to have this in the definition of done
then that's an infringement on the empowerment of the team i agree that the scrum master
is a part of the effort to develop the definition of done but i would kind of flip that the
scrub master is the facilitator it's the team that still owns that so now is the product
owner involved in this absolutely because the product owner is involved in defining
the story and what a fully implemented story looks like so here's a list a short list of
what a definition of done could look like the story has been fully implemented or the
code completed as described automated unit tests have been developed with at least eighty
percent code coverage um it could be more than that um this is just an example automated
unit tests and acceptance tests of the story are passing no severity has one or two defects and then high priority test cases have been
automated and added to the regression suite the definition of done we point out is likely
to evolve as the team's maturity increases as the project advances there are three distinct roles in scrum the
scrum master the product owner and the development team the scrum master assists both the development
team and the product owner the scrum master works with the product owner to maximize return
on investment the scrum master empowers the development team by fostering creativity removing
impediments and coaching and mentoring as appropriate the product owner is responsible
for project success by defining the project vision requirements and priorities the product
owner has to resist the temptation to manage the team or add more important work after
a sprint has begun the product owner has to be willing to make the hard choices during
sprint planning the development team is comprised of five to nine members with a mix of roles
and has the autonomy to self-organize and choose how best to meet the goals of the product
owner and is responsible for the same a scrum master is a skilled servant leader a scrum
master has very little formal authority however he or she is expected to assist the team achieve
the intended outcomes without interfering with the team's autonomy the scrum master
facilitates the scrum ceremony such as sprint planning daily stand up sprint review and
sprint retrospective the scrum master removes obstacles or impediments faced by the team
the scrum master is also a process coach and mentor the scrum master must not be a line
manager of the team the scrum master is not to be a task master either the scrum master
is not a technical or design authority nor is he or she a decision maker for the team
throughout the course of the project the scrum master must not do anything to rob the team
of its empowerment and ability to self-organize let's talk about the attributes of a scrum
master scrum masters need to exhibit responsibility even though they are not solely accountable
for the team's output they will consider it their responsibility to remove anything that
impacts the team's productivity they will try to enable the team to do the best that
it can they are humble they will work in the background and let the
team take all the glory they will use we statements and seldom use any i statements they are able
to set aside their ego and shower all their attention on the team they are by nature collaborative
they will encourage the team to have conversations among each other and with other stakeholders
outside the team they will nudge all the right people into getting involved and work together
and trying to solve problems they are committed to the team cause even if being a scrum master
is a part-time task for them they will give the highest priority to the team's needs hence
the scrum master's work allocation especially if they are part-time needs to take this into
consideration they are able to influence they are naturally good communicators and able
to convince others to adopt different approaches they apply various techniques to mobilize
organizational resources when required walk the political tight rope when required and
in general do whatever it takes to get the team the assistance it needs they are knowledgeable
it is clear that as process coaches for the team scrum masters need to be experts in the
method they may not be the technical or domain experts however they are knowledgeable enough
to be able to have productive conversations about the project being done by the team tasks
for the scrum master the scrum master is a crucial role and it is important for you to
be able to be clear about exactly how the scrum master serves the team scrum masters
are servant leaders this means that they put the team before themselves and assist the
team for example they set up ensure that the scrum ceremonies are effectively carried out
they ensure that there is smooth flow of information within and outside the team and that there
is a spirit of collaboration in decision making and problem solving scrum masters must make
it their mission to resolve issues that hinder team progress it doesn't matter what the nature
of the issue is a scrum master needs to mobilize the right resources within the organization
to resolve those issues in a timely manner and escalate promptly if that does not happen
we need to understand that in the short duration of a sprint even a few hours of being stuck
can make the difference between a successful and unsuccessful sprint scrum masters protect
the team they ensure that the team is not disturbed or asked to deviate from their commitments
if pressure mounts due to unreasonable expectations they will step in and push back on the team's
behalf they will also play the role of peacemaker when conflict arises by encouraging the parties
to focus on the issue discuss the issue with an open mind and resolve the conflict finally
scrum masters are the process coaches of the team they use their understanding of agile
methods and scrum in particular to guide the team through the do's and don'ts of scrum
they ensure that the team stays true to the principles of agile development scrum master
roles scrum teams before we discuss the role of a developer on a scrum team let's talk
about the desirable characteristics of scrum teams they should be small and nimble team
size should be no less than three and no more than nine so that would be six plus or minus
three exceptions are possible but uncommon the small attribute makes the team nimble
and improves productivity it avoids the phenomenon mike cohn calls social loafing and instead
produces focus on work the team size should be just large enough that the team members
are able to produce and showcase a significant increment of work at the end of each sprint
sprint after sprint self-sufficient and cross-functional for example if a team needs user interface
development skills database expertise and service expertise all of those skills must
be present on the team ideally team members are generalizing specialists team members
should not only be an expert or a specialist at one aspect of the development effort but
should also have enough skills and knowledge to fill in in other roles as necessary for
example if you are a ui developer you should be able to don the hat of a services developer
if needed if a large team is to be split up into smaller scrum teams scrum favors feature
teams over component teams autonomous and self-organizing teams choose for themselves
how they are going to organize and meet the goals of the product owner no one gets to
dictate to the team how to get their work done the team decides in collaboration with
the product owner the project direction and the pros and cons of different approaches
let's talk about some key decision points or factors to consider when assembling scrum
teams feature teams over component teams the first issue is whether it's best to align
team members based on features or components scrum favors feature teams over component
teams for example it's best to avoid putting all of the ui developers together and all
of the api or services developers together why because each feature or user story will
require both the ui and services or api organizing based on components will reduce the incentive
to collaborate the only reason component teams may be justified would be if the components
are likely to be used by multiple other teams assemble the right people it's important to
get the right mix of people together for the team the right level of technical and domain
expertise teams will naturally have both senior and junior level developers this works perfectly
as there will be stuff that is more appropriate for the junior developers and stuff that is
not also one of the risks of a small team is that the team may miss out on broader perspective
and dissenting views one way to work around this is to deliberately favor diversity in
all aspects gender ethnicity personality traits etc it may take some time for the team to
advance through the storming stage of team development and develop the trust necessary
to work effectively together but it can be done once a team has been formed it's best
to preserve and assign whole teams rather than individuals to projects it's best to
avoid assigning team members to multiple projects at the same time distributive team a distributed
team may be unavoidable those based at the same geographical location should be co-located
in the same team room and technology processes and ground rules should be put in place to
overcome the disadvantages of all team members not being co-located plotting team size and
productivity will likely result in an s curve you can see here that a team can actually
be too small or too large remember the sweet spot is 6 plus or minus 3. think of scrum as a lightweight framework
that utilizes principles and practices that assist teams in delivering working software
in short cycles to the customer enabling rapid feedback continuous improvement and quick
response to change it promotes delivering value as in working software to the customer
in an incremental and iterative way it is not a process or technique for developing
software rather it is a framework within which various processes techniques and practices
are employed in scrum the iterations that deliver working software to the customer are
called sprints in each iteration or sprint results in potentially shippable software this slide is a graphical representation of
an agile project using scrum starting at the left you can see that the product owner owns
the product backlog and in collaboration with the team develops the user stories or requirements
for the project the product backlog is prioritized with the higher priority items occupying the
top of the product backlog in collaboration with the product owner the team decides how
to group the user stories into releases based on the product roadmap once the release planning
has been completed the user stories are then selected for a sprint the duration of the
sprint is going to be two to four weeks once the sprint backlog has been determined the
team then disaggregates each user story into tasks during each sprint the user stories
are developed as the code is written it is integrated into the system and daily scrums
are held at the end of a sprint there is a sprint review where the working software is
demonstrated and presented to the customer for acceptance the team then conducts a sprint
retrospective during the retrospective the team looks at primarily three things what
went well what did not go well and what should be done differently going forward the team's
velocity is then updated as are the information radiators which transparently display the
status and progress of the project and then the cycle repeats itself until the project
is complete a sprint is an iteration in scrum at the beginning of a project the scrum team
determines the duration of sprints for the project most sprints are going to be two to
four weeks in duration factors affecting sprint duration include the stability of the product
backlog once a sprint has begun the duration is never changed nor are any user stories
added or removed therefore if many changes are expected a shorter sprint duration would
be best however if the product backlog is relatively stable a longer sprint duration
may be appropriate overhead there are overhead costs associated with each sprint for example
every spent is going to have a sprint planning meeting a sprint review and a sprint retrospective
if a team has been able to lower these overhead costs by automated testing continuous integration
etc these costs can be absorbed more easily making shorter sprints more desirable however
if these overhead costs remain high the team may need to use longer duration sprints a
team may be tempted to extend the duration of sprints in an effort to hide their inefficiencies
remember agile projects favor shorter duration sprints and it is the scrum master's responsibility
to coach and mentor the team so it can reduce waste irregularities and overuse and make
the sprint shorter the goal of a sprint is to deliver working software at the conclusion
of each sprint the team should be able to deliver near releasable or potentially shippable
software this is not easy especially for an existing product with a lot of legacy features
but it can be done with the right technical practices and mature development processes
once the sprint duration has been determined and the user stories for the sprint have been
selected the duration of the sprint cannot be altered nor can any user stories be added
or removed the sprint will end at the appointed time irrespective of whether the team has
met the sprint goals or not this allows for effective continuous improvement if the team
is unable to deliver the working software as planned the team will have to figure out
why that happened and then make changes to improve going forward the product owner may
choose to cancel or terminate a sprint in specific situations for example a significant
change in priorities or a mid-course correction may render the current sprint backlog invalid
given that we are only talking about a couple of weeks of work the cancellation of a sprint
would be an extremely rare event a sprint will begin with a sprint planning meeting
and end with a sprint review in retrospective there are three backlogs used in scrum the
product backlog the release backlog and the sprint backlog the product backlog is the
master container of all the user stories for the project the product backlog is continually
pruned or prioritized so that maximum value is delivered to the customer the release backlog
is a subset of the product backlog releases support the product roadmap and each release
is populated with user stories necessary for that release the sprint backlog is a subset
of the release backlog and contains the user stories to be developed in the sprint as we
said the product backlog contains the user stories for the entire project and it is the
responsibility of the product owner user stories are features functions or requirements that
deliver value to the customer however the product backlog will also have to contain
technical or non-functional user stories necessary for the system to work properly the product
backlog may also include risk or defect related user stories the product owner is responsible
for keeping the product backlog current and up to date this is accomplished by pruning
the backlog which is prioritizing and reprioritizing the product backlog must also be continually
groomed this is the process of adding and removing user stories based on the needs and
desires of the customer there are four scrum ceremonies the sprint planning meeting the
daily scrum the sprint review and the sprint retrospective let's take a detailed look at
each of these ceremonies the sprint planning meeting is time boxed at two hours for each
week of the sprint if the sprint is going to be two weeks in duration then the time
box will be four hours if the sprint is going to be four weeks in duration then the time
box for the sprint planning meeting will be eight hours it should be attended by the complete
scrum team including all roles the most important aspects of this meeting are the team's capacity
and the definition of done there are two approaches to selecting user stories for a sprint one
is based on the velocity of the team the other is commitment driven team buy-in is critical
and the goals of the sprint should be clearly understood and the desired outcome should
be clearly articulated with the definition of done then there's the daily scrum the time
box for the daily scrum is 15 minutes regardless of the duration of the sprint length the entire
scrum team including all roles should attend the daily scrum each development team member
individually answers three questions what did i do yesterday what am i going to do today
and what are my impediments this is how the team members coordinate their work and the
scrum master learns of the impediments he or she should be taking care of the sprint
review takes place at the end of the sprint and is time boxed at one hour for each week
of the sprint so if the sprint were four weeks in duration the sprint review meeting would
be four hours it should be attended by the complete scrum team including all roles plus
any other stakeholders who are interested in project success the purpose of the review
is to demonstrate working software and obtain and assess feedback feedback may range from
full acceptance of the completed software to complete rejection the sprint retrospective
takes place after the conclusion of the sprint review and is time boxed at 45 minutes for
each week of the sprint so if the sprint has two weeks in duration then the retrospective
would be one and a half hours in length it should be attended by the complete scrum team
including all roles however the product owner's attendance is considered optional during the
retrospective the team answers four questions what worked well what did not work well what
should be done differently and what still puzzles us one or several problem detection
techniques may be used in the retrospectives and this ceremony is a vital part of continuous
improvement at the conclusion of the retrospective the teams velocity and the project's information
radiators are updated then the next sprint's planning meeting takes place and this cycle
continues until the project is complete the definition of done is an important artifact
for a scrum team it is the primary reporting mechanism for team members and there may be
a different definition of done at various levels definition of done for a feature or
user story the definition of done for a sprint and the definition of done for a release it's
really just a checklist of activities that add verifiable and demonstrable value to the
product it's created by the scrum master in consultation with the team a sample list of
the items for the definition of done criteria is given here the story is fully implemented
or code completed as described automated unit tests have been developed with at least 80
percent code coverage automated unit tests and acceptance tests in the story are passing
high priority test cases have been automated and added to the regression suite note this
is only meant to be an example each team's definition of done will vary slightly depending
on the maturity of the team and the specific situation of the team the product team has taken up a new project
called weather master the team is planning to move to scrum methodology and this is an
outline of its first scrum meeting time box to 15 minutes rick is the scrum master of
this meeting where the team members discuss what they did yesterday their plans for today
and the impediments they faced all team members are standing up including todd who's joined
the meeting via video chat rick holds the meeting near a scrum board angela the product
owner is absent rick reiterates that all discussions would be parked until after the scrum meeting
and encourages this team to keep the meeting short people can chime in to resolve obstacles
hi team welcome to the daily stand-up meeting for the product team on project weather master
we are in sprint one and today is the second day as we are planning to transition to scrum
methodology i hope you will find this daily stand-up meeting helpful in this meeting you
will provide information about what you did yesterday what you plan to do today and what
challenges you faced i think everyone's here let's start i don't see angela shouldn't she
be here i did add angela as an optional attendee to this meeting and since she hasn't showed
up we don't have to wait for her susan scrum doesn't provide a specific yes or no
about the product owner's participation in the daily scrum the po's primary role is to
provide direction and clarify requirements and priorities since we don't always discuss
those in detail at this meeting the po is not required to be here if the pos want to
attend they are generally in listen only mode for the duration of the meeting they can use
the information gathered during the meeting for separate offline conversations [Music] [Music] what about todd he works from his home office
right todd will be a part of the meeting through video chat it is important that we include
every team member in the meeting hi todd how are you i'm fine thanks am i audible
yes todd team let's all stand up for the meeting [Music] [Music] why don't you go first erin yesterday
i was working on creating the mock objects to mask the database calls from the unit tests
the difficulty with this approach is that our server side logic is so dependent on the
metadata that writing a true mock is a mammoth exercise there are decisions that are taken
during run time based on the data some of the stored procedure calls are also made based
on the values returned through inline queries that are also embedded in the code i was debugging
the code until about 9 pm but for the life of me i couldn't figure this out aaron could
we request you to be concise when you provide an update if you think some of the details
you described might be interesting to others why don't you write a wiki page on it and
share the link so getting back to your update did you finish the task yesterday no it turned
out to be much more complex than i had imagined i'll continue to work on it today and see
if i can figure out an xml structure to mock the schema and hard code some return values
but i am really stuck as far as the inline queries are concerned i know what you're talking about there is
a reason why the inline queries are there in the code this is mainly for performance
reasons when the overheads of making a procedure called based on a metadata value and then
processing the sorry for the interruption again guys this is a really great conversation
may i suggest we write this issue in the parking lot i'm not sure what you mean by that rick
let me explain what aaron just brought up is a blocking issue team members should bring
these up during the daily scrum so that everybody knows that one of the team members is stuck
however the daily scrum is not necessarily the meeting where solutions to every obstacle
can or should be found it looks like mary knows a thing or two about the issue that
erin has brought up let's jot this down as a parking lot topic this means the team can
have offline conversations after the daily scrum to track it down i'm also going to make a note that will track
the impediment erin faced daily until it is removed you should let me know if i can help
in any way right erin is there anything else you would like to say no i am done thanks yesterday i worked on developing the wizards
for bulk order creation i'm almost done today i need to write code to handle some of the
exception scenarios before i can get them over to susan for testing that's it for me
i guess did you forget to mention any impediments not really an impediment at present but i
would like to mention that my computer probably needs to be upgraded with more ram it has
been slow for the past few weeks okay i wrote up some scenarios to test the
bulk order wizard i'm looking to get my hands on the code as soon as mary is done today
i'm also hoping to complete the company order testing that has been pending for a while
i'm okay for the moment but i do have one question shouldn't we all be updating the
task board as we speak we could it is up to you guys if you think you want to do this
during the meeting if you ask my opinion we should update the board as soon as we are
ready to move the tasks and not wait for the meeting this will ensure that the board is
always up to date and also that we use the meeting time to focus on the conversations
that's a great point rick i can't see the board very well from here anyway so maybe
we should find a way to create an electronic version of it too at some point great point todd why don't you go next with
your updates all right hey rick would you like to know about my work on the advertising
module first or the integration server whatever the team decides is fine with me remember
this is really your meeting and i'm only here to facilitate and ensure we get the most out
of this meeting [Music] [Music] all right then i guess i'll start
with the integration server i would like to inform everybody that i managed to set up
the integration server that we can use as a sandbox to test the code before checking
it in source control i'll send everybody a link with some instructions and credentials
i have also started looking at the stories for the advertising module it looks like there
are a lot of open statements in the stores that i don't really understand i guess i should
have been paying more attention during the sprint planning i really need to have a conversation
with angela about this that is my main impediment right now i sent her an email but haven't
received a response yet i don't have anything new to add today i'm
almost through with setting up our project on the freeware tool that i downloaded yesterday
i'll show you guys a demo in the meeting i set up later today i'll try to chase down
some of these parking lot items anything else before we close the meeting all right that's it for today have a great
day do you have a moment to chat about the inline queries real quick the purpose of a
scrum meeting is to keep the team members updated and resolve any impediments it's an
ideal way to kick start the day on a positive note the scrum master reinforces the sense
of the self-managing team facilitates communication between team members brings the team's focus
back to what's important and supports improvement so before we dive into the differences between
scrum and kanban let's have a look at what exactly scrum is scrum is a simple agile project
management framework that is used by organizations to help teams collaborate handle unpredictability
and complex projects or products while ensuring the products delivered are of the highest
value it describes a set of meetings tools and roles that enable teams to work in sync
and help them structure themselves and manage their work scrum is one of those things that's
really easy to understand but very difficult to master and although scrum is seen to be
used generally by software development teams its principles and themes are pretty universal
and can be used with just about all kinds of teamwork with scrum teams are able to learn
from their experiences what worked out what didn't and things like that they're also able
to organize themselves to handle their problems effectively and basically improve themselves
by reflecting on them so how does scrum work here we have the first
component the product backlog the product backlog consists of a list of tasks that need
to be completed so that the goals of the stakeholders are achieved then the team decides what tasks from the
product backlog they want to take up and deliver in a two to four week period called sprint
hence the name sprint planning next the tasks that were discussed in the
previous phase are added to the sprint backlog this is a set of tasks which will be focused
on in the ongoing sprint following this the scrum team which is usually
5 to 9 members strong will work on these tasks now they also have regular scrum meetings
where they talk about their victories the issues they face and what they plan to do
in the next 24 hours and then they have the sprint review the sprint
review is a meeting during which the team shows what they accomplished during the sprint
now during this time questions are asked observations feedback and suggestions are made the product
owner also gets feedback for upcoming sprints from stakeholders they also have a sprint
retrospective now during this session past mistakes potential issues and new ways to
handle them are identified data from here is incorporated into the new sprint plan the
final step is increment here a workable and usable output is provided to the stakeholders
so now that we know how scrum works let's have a look at kanban kanban comes from the japanese word kanbam
which literally means signboard like scrum kanban is a popular agile framework that is
a visual system by which the work can be managed with ease as it progresses kanban uses something
known as the kanban board to make these things possible with this you can easily identify
bottlenecks and then fix them cost effectively at optimal speeds the main focus with kanban
is transparency since everything related to the tasks are on the board everyone can keep
themselves updated it also ensures the teams focus on their current tasks until they're
done this limits the amount of work that's in progress so on the kanban board work is divided into
smaller more manageable pieces the work that's needed to be done is written on a note or
card and placed on a board columns on the board help represent where each item is with
respect to the workflow now let's have a look at what these are in detail let's find out
how kanban works now the board consists of three major components
there's the to-do list which represents items that need to be completed the ongoing column
which represents items that are being currently worked on and the completed or the done column
now these represent tasks or items that have already been completed now although this is
a physical representation of the board several organizations use software versions of the
board that replaces the sticky notes with cards that can be moved from one column to
another as work progresses now an example of such a software is trello so if you want
to learn more about trello you can check out the link i'll be adding to the live chat in
a moment at this point you guys must have realized
how similar these two frameworks sound so let's run through some more of their similarities
let's find out how they are similar firstly they both have principles of lean
and agile which means reduction of waste and both of them are time-boxed and iterative
approaches that enable product delivery in an incremental manner both these frameworks
aim to reduce the amount of work in progress this forces the teams to ensure that they
focus on a smaller set of tasks this also makes blockers and bottlenecks a little more
visible in both cases the work is divided into smaller
more manageable units both of these frameworks use pull scheduling
now this means the products are only built based on demand rather than forecasts transparency plays a major role in both these
frameworks by helping them drive process improvement and in both cases the release plan is continuously
optimized and finally both these methods aim to deliver releasable software often and earlier
than expected so now that we've reached midway let me ask you guys a question do you guys
use scrum or kanban in your workplace or do you use these software for personal reasons
what exactly do you use these for let me know in the live chat now let's have a look at how these two frameworks
are different from one another firstly let's have a look at cadence cadence
refers to the amount of time in a sprint or before a release so when it comes to scrum
the entire project is divided into time constrained iterations that is into smaller manageable
units but when it comes to kanban it's even driven the next criteria we're going to have
a look at is release methodology in scrum releases take place after each sprint
which usually takes two to four weeks to complete for kanban releases take place in the form
of continuous delivery they happen in such a way that changes like new features configuration
changes bug fixes and experiments get to the users in a safe quick and sustainable manner next up let's have a look at how changes are
addressed in both these frameworks in scrum no change can be made while the sprint is
in progress once it's complete changes can be considered in the sprint plan and then
added to the sprint backlog with kanban changes can be made at any time
and incorporated into the workflow now let's consider the metric that's being measured
in scrum for planning and process improvement velocity which is the measure of the work
that can be completed by a team in a sprint is the key metric in kanban lead time is the
key metric this represents the period of time between a new task's appearance in your workflow
and its final departure from the system next let's have a look at how teams work in
these frameworks in scrum you need a cross-functional team to achieve your goals in a sprint in
kanban cross-functional teams are optional but specialized teams that focus on particular
aspects of the workflow are required now let's talk about new additions in scrum
just like handling changes you can't add any items between a sprint or nitration in kanban
new items can be added to the board as long as there is capacity available for it now
let's have a look at the job roles within these frameworks scrum has three major job
roles product owner scrum master and scrum team with kanban you don't have any specific
job roles now let's talk about representation or moreover let's talk about how data can
be represented with scrum the board needs to be reset once a particular sprint is complete with kanban the board stays persistent throughout
the entirety of the project and finally let's have a look at project link with scrum it's
better suited for longer projects and with kanban projects that can be completed
in a shorter period of time are better so which one should you choose now selecting from these two methods is mainly
based on the requirements of the team do you expect your project to be shorter do you want
to make changes at any time you don't want to set up job specific roles then kanban is
the framework for you or do you want a long-running project with different job roles and involving
cross-functional teams scrum is the answer for you based on the differences we discussed
on the last topic you can make an informed decision now let's have a look at some of
the popular companies around the world that employ both these frameworks some of the companies that have successfully
implemented scrum are facebook general electronics and adobe companies that have implemented
kanban are siemens bbc and sap if getting your learning started is half the battle what
if you could do that for free visit skill up by simply learn click on the link in the
description to know more so as part of this tutorial we are going to understand the typical
interview questions which would come across when someone faces the interview for any of
the roles in the scrum so question number one what is chrome so scrum is a framework
that enables team to work together so with scrum teams can learn from experiences self-organize
working on problems to reflect on their victories and their losses to improve so this is a simple
framework which will provide a better ability and methodology one can able to handle it
better so scrum is very well defined articulated and this provides a better insights and capabilities
building access is very easier and roles are well defined so define the roles in scrum
so what are the typical roles we come across in scrum so one of the roles we come across
is product owner so product owner is primarily responsible for maximizing the roi by determining
the product features prioritizing it into a list what needs to be focused on for the
next print and constantly reprioritizing and refining it so what happens is whenever we
may require to deliver it is very important for us to have the requirements clear what
requirements needs to be fulfilled to fulfill the requirements the products what is produced
should have specific features and functionalities so product owner will have the list of features
and functionalities which needs to be created when product comes out as a result of a project
so product owner owns this primary responsible to ensure these list of features are identified
and those are prioritized as required so next role we can think of a scrum master who helps
teams learn and apply scrum to obtain business value so scrum master helps removing impediments
impediment is anything which can stop things to flow smoothly so protects them from interface
and helps the team to adopt agile practices now scrum is one of the methodologies for
agile approaches and practices now remember the term agile itself is not a practice it
it refers to indicate that move faster become flexible respond to change be flexible now
scrum methodology especially scrub master should understand this dynamics and ensure
the team understands this and scrum master should guide the team to adopt these methodologies
and ensure the results are accomplished accordingly so next role is scrum team so scrum team is
a group of individuals who work together to deliver the requirements of the stakeholders
so scrum team is generally of the size like 5 plus or minus 2 who are self organizing
so various different capabilities the scrum team members would have so each of their capabilities
complement to accomplish the results required so question number three what are the responsibilities
of this chrome team so scrum team is self-organizing as i mentioned earlier so it is a self-organizing
team that has five to seven members and the responsibilities would include the development
and delivery of working products during each sprint now we are seeing the new terminology
sprint so what is the meaning of this print now sprint refers to an iteration a time box
iteration which will have a specific deliverables to be accomplished as part of it so self-organizing
team takes that specific working piece what needs to be delivered so that is a sprint
backlog we call it as so from the product backlog the features functionalities which
needs to be delivered as part of this specific iteration called sprint time box iteration
and those sprint backlog items are delivered the output of the sprint would be the features
what has been taken is a working piece working product so to demonstrate ownership and transparency
for work assigned to them so they own it the entire thing assigned to them there is there
should be ownership so ensuring the success of daily scrum meeting by providing crisp
and correct information so scrum has one event there are five events basically so one of
the events which happens daily is daily scrum meeting where the team comes with scrum master
so they would speak about what is that they have accomplished from the previous stand
up to till now is there anything which is stopping them to move forward so giving the
crisp updates specific summary updates so that scrum master understands the status so
any specific uh changes or any specific support which are required scrum master would discuss
separately with those individuals and get it done so it should be minimum 15 minutes
meeting when we say daily stand-up meeting so scrum team collaborate with each of the
team members they work together and they self-organize so next question differentiate between a jail
and scrum now it is very essential to understand the terminology's differences so if we just
end up with looking at a wrong understanding of each of the terminologies then explaining
will become difficult so what does it mean by agile and what it is when it comes to the
terminology called scrum the term agile refers to ability to move quickly and easily by becoming
more flexible and adaptable this is what the meaning which gets associated with the term
agile so many times i have seen people answering agile is a methodology ager is a iterative
and increment methodology and also i think when you search through the popular search
engines you may come across that which is wrong so agile is the terminology which is
used to state to move quickly and easily by becoming more flexible and adaptable this
we should keep in mind so if the question may be like what are agile methodologies then
you can come across like one of the agile methodologies scrum and you can go on on various
different methodologies what we have so scrum is an agile methodology right the term scrum
is the name given to the agile material methodology which enables organization to become a child
right so to become agile obviously there are various methodologies scrum is very popular
so that is the main difference so further if you look at agile manifesto on 12 principles
which acts as guidelines to become a child so there is something called agile manifesto
four points clearly articulates what needs to be focused on to become a child and that
support that is supported through the 12 principles which guides so scrum is used in projects
where requirements are constantly changing means i want to become agile so i adopt scrum
so this definitely has to align to agile manifesto and take the guidelines whatever is mentioned
in 12 principles of a gel manifesto then looking at leadership perspective roles perspective
so manifesto mentions the required collaboration interactions to become a child whereas crumb
defines the roles like the scrum master the product owner the self-organizing teams which
is cross-functional self-organizing team so these are the main three roles which scrum
defines now generally when we say projects we come across the role like project manager
so do we see such project managers in scrum answer is no because the scrum master who
engages with team regularly more than management they focus on doing facilitating role to the
scrum teams so that things can be delivered the way it is required and more flexibility
is given to the team to take the calls to accomplish the results so scrum master facilitates
whereas the product owner as i mentioned earlier looks at the product backlog and prioritizes
and provides what are the features functionalities needs to be created in the next iterations
so speaking about flexibility definitely agile manifesto mentions the required focus on working
software and focusing on changes so that's the focus the direction what it provides so
scrum approaches enables teams to react to changes quickly the scrum methodology is made
such a way the team understanding that can able to react and those changes and modifications
are made visible to the team so delivery perspective manifesto provides necessary guidelines on
frequent delivery of product or software so scrum with time-boxed iterations called sprints
builds delivers to the users regularly and half held agile principles that is very important
so delivery here is as per the user's requirement as per the customer requirements because customer
when we want to become a child customer has to involve very closely stakeholder has to
collaborate without that you cannot become a jail so next point is about collaboration
agile manifesto stresses on individual interactions and customer collaborations so based on this
if you look at in the scrum how are they demonstrating this so there are various events which happens
in scrum so as i mentioned earlier we have daily stand-up meetings and other scrum events
like sprinters retrospective sprint reviews daily stand-up meetings which happens experiment
planning which happens regularly so it it becomes a reason for collaboration and everyone
to discuss and take the call so question number five what are the main artifacts of this chrome
process now product backlog so which consists of list of new features changes which are
looking organization is looking for to bring into the existing features changes to the
existing features bug fixes changes to the infrastructure and several other activities
to ensure a particular outcome so product backlog so then we can speak about sprint
backlog a subset of product backlog so the sprint backlog contains tasks that the team
aims to complete to satisfy the sprint's goals so set off product backlog things are taken
put into spin backlog and those are the features which are supposed to be produced as a result
as part of that particular sprint the team first identifies tasks from the product backlog
that need to be delivered to achieve a goal so these tasks are then added to the sprint
backlog so the team first identifies tasks from product backlog as per the priorities
the list which is prioritized in the product backlog that is taken put into sprint backlog
and then those are delivered so next you can think about product increment the product
increment is the combination of all product backlog tasks completed in the sprint and
the value of the increments of previous sprints the outcome should be in the usable condition
even if the product owner doesn't decide to release it it is very important each of the
increments which comes out so needs to fulfill this now question number six how are the product
and sprint backlog different from one another product backlog versus sprint backlog let
us see a few differences so product backlog is the list of items that needs to be completed
for developing the product which is the list of all the features functionality consolidated
one whereas print backlog is the list of items to be completed during each sprint which are
taken from product backlog the backlog when it comes to product backlog the backlog is
collected from the customer by product owner and assigned to the team whereas in sprint
backlog the teams collects the backlog from the product owner and sets up the time frame
for the sprint so product backlog is specific to end goal ultimate objective whereas print
backlog is spread specific to that sprint specific iteration called sprint in scrum
what is that we are going to produce as part of it product backlog is based on customer
vision whereas print backlog will vary based on the product vision defined by product owner
so pre-orders list you take from the product backlog so product backlog is independent
of sprint backlog whereas sprint backlog is dependent on product backlog reason we know
already i explained so this is the prioritized list of backlogs we take from product backlog
and create this uh per specific product as part of sprint which become sprint backdrop
so product backlog refers to until the project is complete the product owner maintains the
product backlog for a sprint backlog when it comes to sprint backlog each news prints
as backlogs added by the team as each sprints are initiated so next question who is the
scrum master and what does he or she do so a scrum master promotes and supports the adoption
of scrum in the team scrum master helps everyone to understand the theory practices rules and
values in the scrum so scrum master is playing the role of facilitation enablement right
so scum master ensures the team follows chrome values principles and practices removes blockages
that may hamper the progress of the project protects the team from being distracted ensuring
the team delivers value during every sprint so next question what happens in daily stand
stand-up sessions so daily stand-up sessions are the discussion which are done daily that
takes place under usually 15 minutes in duration the objective is to understand what went well
what tasks are completed from the last stand-up session what tasks are pending and the obstacles
the team was facing if at all any uh specific task is not accomplished for certain reasons
so what are stopping them stopping the team to accomplish that that needs to be made visible
so that separate meeting can be held to discuss on that and do the necessary corrections by
taking proper actions so the objective of this daily stand-up meeting is to understand
the overall scope and status of the project further individual discussion can be taken
up after the daily stand-up sessions as i mentioned earlier if at all if you find something
is not accomplished as per the plan now how do we ensure that is corrected and why is
it happening is there anything any support is required by the team to focus on that so
something like that can be checked out question number nine what is scrum ban so scrum ban
is a development methodology that is a combination of scrum and kanban so this can be used to
meet the needs of the team that aims to minimize the batching of work and to adopt a pull-based
system so kanban is called as pull-based system so which actually uh helps in terms of visualizing
what work is in progress and since it is a visualized visualized system which is visible
to everyone so it works in terms of making people become conscious to take that work
and get it closed quickly so it's also called pull system because work is pulled from that
particular list so when this kanban approach or methodology or thought is applied in scrum
we call it as karamban so combination of this definitely helps in terms of making that entire
journey successful and supports the scrum methodology so scrumbar includes the structure
of scrum along with the flexibility and visualization of kanban so scrumbar is used by the teams
that need to be structure of scrum that has the structure of scrum and the flexibility
of a flow based method like on1 so question number 10 what is sprint 0 and spike so the
term sprint 0 refers to the short amount of effort put for creation of vision a rough
skeleton of the product backlog so now we do this whenever we need to understand certain
things how things looks like to get certain insights so this also includes insight towards
estimating the release of products so you get some vision it gives some clarity right
so this sprint zero are required to create project skeleton alongside research spikes
keeping minimal design develop a small number of stories completely have low velocity and
be lightweight so speaking about this spike so spike is set off activities used in extreme
programming i think uh this was introduced there in extreme programming that is one of
the agile methodologies so involving research design investigation making proof of concepts
etc so the objective of spike is to reduce the risk of technical approach by gaining
knowledge which helps understanding requirements and to improve reliability so more aware we
are more clarity we have i think putting step further will become easier so informed decisions
you can take so next question what is crumb of scrums now scrum of scrums is a terminology
used for scaled agile techniques which is required to control and collaborate with multiple
scrum teams so when will we come across the need for collaborating between multiple scrum
teams so these are the scenarios where organization has a complex structure complex in nature
where you may require to handle them together all of them uh together for accomplishing
the common objective for business various chrome teams you would have so scrum of scrum
helps in terms of better collaboration and handle them easily or better way better control
it is best used in the situations where teams are working together on complex assignments
just visualizing the system various different deliverables which are not a simple deliverables
which we can do with a simple scrum team instead we have various different deliverables which
needs to be made and dynamics are too complex so bigger projects then scrum of scrum approaches
can be taken so scaling the agile methodology to that level so it is used to establish the
required transparency collaboration adaption adoption to the required scale to ensure the
products can be developed and delivered so whatever the products are delivered whatever
we consider to be delivered so those needs to focus on the business objectives which
is very essential so what is user story mapping so user story mapping represents and arranges
user stories that help with understanding the system's functionalities the system's
backlog planning releases and providing value to the customers so first of all we write
user stories to understand the required features functionality in their user perspective now
if we map those user stories which use a story link to other user story which functionality
links to the functionality determining that will become easier so now user story maps
arranges user story based on the priority along the horizontal axis on the vertical
axis they are represented based on increasing level of sophistications so this will help
in terms of handling in a regular flow in a specific not regular specific flow so that
things can be done in order with full clarity so question number 13 what happens in sprint
retrospective so after this print review so sprint completes so sprint review happens
the sprint retrospective is done so during this meeting the lessons learnt what went
well what mistakes we did what were the issues so is there any new way of doing things so
all these are discussed so that these necessary corrections can be considered in the upcoming
iterations the sprints so data from here is incorporated when planning the new sprint
so the learning what you had you are going to collect it what went well what went wrong
what was supposed to be the best approach and how did we approach it is there any other
way of doing it so these are discussed and very essential to do it at the end of completion
of each of the sprints review question number 14 what is empirical process control in scrum
so empiricism refers to work based on facts experiences evidences observations and experimentation
so empirical process control is established and followed in scrum ensuring project progress
and project interpretation is based on facts of observation so actual facts and figure
is very important any decisions what we make any progression what we make should be always
based on on ground facts and actual pictures we should not deviate from it so these rely
on transparency observation adoption obviously when you're working on the data on ground
reality so are working on the actual one it is transparent it is on the observed data
the mindset of the team and the shift required in thought process and culture are very essential
to accomplish the agility required by organization so mindset of the team is very essential and
adoption of process compliance to the process the culture the behavior obviously plays a
very important role when you do something within the organization so that needs to be
done as per the need which should complement to the business objectives very important
and that should be based on facts not on some thoughts or assumptions or ideas so next question
is what are some drawbacks of using scrum so scum requires individuals who have experience
without whom the project risks will have a risk of failure so one does not have a capability
difficult scrum requests team to be collaborative and committed so people collaborating individuals
collaborating itself is a big challenge in many organizations so bringing this into the
place is very important when you want to adopt scrum so scrum requires teams to be collaborative
and committed to ensure the required results they should work together and also they should
collaborate with customers stakeholders the less experienced scrum master can cause the
failure of the project so be careful scrub master is the one who is facilitator we should
understand this who enable the scrum teams who ensure scrum teams goes the way we need
them to work if scrum master doesn't understand this dynamics does not have the clarity on
this obviously the e or she can not enable to team to become that if tasks are not well
defined the project can have any inaccuracies chrome works better for smaller projects and
would be difficult to scale to large complex projects that's where we were discussing on
a few questions before this scrum of scrum we were discussing about when it becomes a
complex project which those needs to be handled together which will become complex so next
question is what are the skills of a scrum master so a strong understanding of scrum
and agile concept scrum master should have fine-tuned organizational skills so when scrub
master is working with the self organizing team with various different capabilities so
unless the organization skills interpersonal skills if scrum master does not have working
with them will become difficult so scum master should be familiar with technology that the
team uses basic understanding of that how it works the dynamics associated with that
and scrum master should have an ability to coach and teach the team to follow scrum and
its methodologies and very clear about the terminologies artifacts and all the events
what happens so scrum master should have an ability to handle conflicts and resolve them
quickly so conflict is a scenario which would happen for various different reason however
when conflict occurs the scrum master should not shy away from it own it to resolve in
the interest of the project whatever is being done it is very important scrum master has
to be a servant leader so it is not like i am a specific manager or leader of certain
kind and i am doing this with certain way no i am actually facilitating i am guiding
i am showing certain direction to the organization so that says to the team when i say organization
speaking about scrum team so that they are unable to take up the specific project and
accomplish the results accordingly question number 17 how can discord be dealt within
the scrum team now the root cause of the issue need to be identified in interest complete
ownership needs to be established when you deal with this and try to diffuse the disagreements
so emphasizing on the focus area that complements the project so here when we take up any of
the discussions any of the opportunities or any actions what we take everything should
be revolving around objective of ultimate objective of whatever we are doing so when
we need to resolve something when we get into the root causes always it helps to look at
the actions in terms of eliminating those causes so once the causes are eliminated it
is quite obvious you can able to deal with it and address it with easily with the right
set of actions so emphasize on focus areas that complements the project in the sense
that should be the ultimate direction not my individual interest not that individual
interest i favor this person i have that person that's not be the case so favoring this solution
or favoring that solution i am okay with this particular technology i am very happy with
this technology not such thoughts it is the direction what is set i should move things
in that direction so to establish a common understanding and to guide the team to the
direction performing continuous monitoring and providing complete visibility very very
important the next question what is a user story so user stories are an agile software
development project management tools it provides the team with simple natural language explanations
of one or more features written from the end user's perspective now for example i'm a account
holder in a bank so first what is the facility a bank would give to um account holders there
is atm banking there is net banking there is mobile banking and there is over the counter
now when bank is working on creating certain specific features or specific mobile app to
the account holders now what are the things user needs that needs to be visualized now
if i say the role here is account holder as an account holder i want to download the statements
of every month as an account holder i want to download the
statements every month this is what my requirement is how will you facilitate this this will
provide the insight towards how the bank what are the features and functionalities and how
this requirements are can be fulfilled by the bank and what features functionality the
particular mobile app should have so that account holder can download the statements
so user stories will provide that insights whatever users so account holder is not just
an user here there are many users when it comes to mobile app of a bank we have people
who monitor it manage it would develop it so they need to have a clarity on what exactly
they need and that needs to be written as part of user story that what features functionality
can be easily determined out of it so a user story does not go into detail it
just mentions as i gave an example it just mentions how a certain type of work will bring
value to the end user the end user in this case could be an external end users or even
internal customers or colleagues within the organization so if i am an organization i
produce an hr application i create an hr application for claim processing which i don't have till
today so that is for internal users in the bank example and speaking about external customers so user stories also form the building blocks
of agile framework like epics and initiatives these help ensure that the team work to the
goals of the organization through epics and initiatives so further the requirements for
making the user stories a reality or added later after discussing with the team so to
write a user story the involvement of the team members are very essential they should
discuss and come out and agree yes this is the features functionality which should be
there user stories are recorded on post-it notes index cards or project management software
whatever is visible and whatever is available there next question how are the user stories
epics and tasks different so user stories provides the team with simple explanation
of business requirements created from the end user perspective as we saw the few examples
in the previous questions epics are the collection of related user stories they're usually large
and complex so these epics are created with specific objectives in mind and user stories
are grouped so that will form an epic whereas task refers to the one which are used to track
work so they are used to further broken down from the user stories so there's a smallest
unit in the scrum used to track work a person or a team or two people usually work on the
tasks so these tasks are these through this task i think the features functionality what
are required to be accomplished are done so question number 20 what is print now as i
mentioned earlier in the question number four so sprint is the terminology used in the scrum
i think we explained various different concepts as we went through so sprint is the terminologies
used in scrum which refers to time box iterations so we understood what is this iterations in
scrum approaches when we are going through that the creation of specific modular feature
which is part of a product is done during the sprint the duration of sprint varies between
a week or two so means it's a short duration simple few features functionalities are taken
and created so what is velocity so velocity is a metric used in scrum that is a measurement
of the amount of work that is completed by team during the sprint so this is help to
measure how things are moving how faster they are moving it refers to the number of user
stories completed in single sprint so this speaks about that speed so our velocity velocity
uh how faster we are going how slower we are going this helps to vary the variations we
can do that velocity uh depending on what business need so what are the responsibilities
of a product owner so product owner defines the vision of the project they anticipate
the needs of the customer and to create appropriate user stories so they don't write user stories
as such they definitely have a set of people who should get involved the team to write
the user stories lot of discussion has to happen brainstorming has to happen to write
user stories but product owner is accountable so product owner has to evaluate the progress
of the project based on this backlog what project a product owner has and has to be
licensed for all product related questions the team may have certain questions as prints
as the sprint progresses the scrum team may have certain questions clarification relating
to the user stories those needs to be clarified what is burn up and burn down charts so generally
when we say chart it is a graphical representation so burn up chart is a tool that is used to
track the amount of work that has been completed so it is a bar chart the amount of work completed
the height of the bars keeps increasing in burn of chart based on what is completed which
will show the total amount of work the need to be done for a sprint or a project so it
is it is a bar chart where each of the bars keeps increasing in its height as number of
things get delivered increases so burn down charts typically again a graphical representation
a bar chart so what is pending to be delivered it shows that now initially we'll have a bigger
bar and as the project progresses the height of the bars reduces indicating what is that
is pending for deliverables it is a representation of how fast the team is working through the
user stories it helps you to understand that so it shows total effort against the amount
of work for each iterations which is helpful for it oc to that what is pending to complete
question 24 how is estimation in the scrum project done so the estimation of user stories
is done based on its difficulty a particular scale in which which is used to assess the
difficulty of user stories so to analyze how difficult or easy is that some of these scales
which are used like numeric sizing 1 to 10 t-shirt sizing like sml excel fibonacci series
or dog breeds based on their value so many such approaches are taken what are some risks
in scrum and how are they handled so first of all we should know what is risk so some
types of risk in scrum are related to budget people sprint product knowledge and capability
now when we say budget risk of uh increase exceeding that allocated budget taking more
as looking for more variations i estimated for x it is going like express delta x so
can we control it we need to look at that so you need to assess that risk when what
possibilities the cost can escalate people related like team members need to be of appropriate
skills and capabilities if they lack that obviously difficult it's not about just skills
and capabilities the culture the behavior the attitude the energy this energy that collaboration
what people will have then sprint related in terms of duration and deliverables exceeding
the duration addition of scope to that sprint in between so that challenges that difficulties
so product referring to user stories and epics having ill-defined user stories and topics
not properly articulated there is no proper visualization when you look at that user story
not understanding so nobody is explaining it correctly so then knowledge and capabilities
so it is not just related to the people here itself entire system everyone was who is involved
with the specific resource with its capability it can be technology capabilities also so
when i say risk it basically involves identification assessment analysis and defining risk response
plans and implementing them now when i say assess assessing the risks should be qualitative
as well as quantitative so depending on the impact and probability of a risk if it is
a high impact risk obviously you are required to do both qualitative and quantitative if
a simple one with the very less impact you can take the call accordingly to what extent
you may require to analyze and have the response plans for it so once you have implemented
and defined and implemented the response plans quite obvious you should keep monitoring it
and manage the risks the risk impacts and probabilities may vary as the project progresses
so we may require to keep assessing the identified risk and keep identifying the new risks as
you as we progress in the project so these are done on a continual basis right from starting
of the project till completion the reason i told it is essential to understand that
the impact of the risk is based on the proximity of actual occurrence of the risk now for example
if you start working on something nothing is delivered at the moment now if specific
risk of peep no people not available our customer is not involved initial stage very initial
stage so risk impact is accordingly project would delay in entirety our requirement is
not very clear it is delaying something of that sort of impact you will have now as the
project progresses almost like 50 percent of the project complete now the there is some
uh challenges or risk associated with issues are occurring related to customers involvement
now you are made of project so again you will have a different kind of impact 50 percent
is delivered now you need to progress because active involvement of stakeholders including
customer is very important when you are becoming a child so when that is not happening as an
example i am taking the involvement of customers the collaboration part of it that is not happening
now here the impact level is not equal to the impact level when you when this happens
in the starting of the project same type of risk what we are assuming so that is the reason
each of the risks you should keep assessing the identified one keep assessing as the project
progresses and check on is any new risk is introduced as the project is progressing so
next question what are some popular tools used in scrum so these are the list so you
can think of github soho trello jira software yodex varies version one so now what i am
saying is these are the tools technology tools so when we say tools we cannot just limit
our thought to technology tools so what exactly this tool does what are the techniques used
that we need to be very clear right the metrics what is measured and methodology of measuring
it and what processes are used what steps are used so what needs to be used so unless
we are clear relating to specific type of project usage of these tools may not make
any sense you cannot even implement or customize this for the requirement what you are trying
to accomplish so you be clear about it when you are selecting the tool so 27 how does
scrum master track sprint progress so we have various different events which happens in
scrum like daily scrum meetings scrum retrospective scrum planning scrum review and checking on
the defects which are escaped density of the defects burn down spring burn down velocity
so so checking all of this uh provides the better insight to scrum master so that tracking
the progress of the sprint will become easier so how to deal with the scope creep before
we understand the dealing with scope tree we need to understand what is scope creep
so the term scope creep refers to the change which is uncontrolled and added without checking
the impact on the constraints like scope time cost now what happens is you will be uh doing
certain or delivering certain features now you are forced or you are influenced or without
your knowledge some additional things are put in place so which may impact later it
may add value it may not add value later it doesn't matter but it may lead in terms of
impact your cost time and schedules which is unexplained and that extra effort what
you have put in extra cost what you put in uh will become like not recognized by customers
and you will not get anything paid for it so scope to avoid the scope creep to deal
with it one has to ensure close monitoring of works being done on day to day basis because
scope creep can happen through team members influencing team members are influenced by
consumer because of that it may happen so understanding communicating the vision to
the team for ensuring the alignment so the team is very sensitive about that changes
what is happening then capturing reviewing the project requirements regularly against
what is delivered to emphasize to the team and customer about the requirements signed
off so that someone will not come and influence you or make that additional things to be delivered
they need not push you right ensuring any change introduced to go through change control
so no changes without any proper approval by the authorities so that only those what
is required to be implemented is implemented and that is done formally through the formal
change request so avoiding gold plating so it is with different thought process when
we say gold plating so we were doing the projects are trying to add certain things into the
scope to please the customer as an example doing something additional providing some
additional features and functionality for which we are not paid so scro creep is not
a terminology used for it but gold plating is the term used but however since it is an
additional scoping so we're just added here so don't say that when the moment scope creep
we says that is not gold plating gold plating is a different direction so just to explain
you along with scope creep what else would happen to where the additional deliverables
would come in which is gold plating so question 29 what is mvp and mmp which means minimum
viable product and minimal marketing product so now minimum viable product is a concept
of lean startup which stresses upon the impact of learning while performing product development
so this allows one to test and understand the idea by getting exposed to the initial
version of the product for target customers and users so to accomplish this one has to
collect all the required relevant data and learn from the collected data so the thought
behind mvp is to produce a product to provide access to the users and to observe how the
product is used pursued and understood this will also provide more insight towards what
the customers or users needs are so when it comes to minimal marketable product this refers
to the description of the product which will have a minimal number of features that addresses
the requirements of the users the mmp would help also the organization reduce the time
to market because you have the clarity what is that we may require to provide the question
number 30 what does dod means definition of done right so dod refers to the collection
of deliverables which includes written quotes comments on coding unit tests integration
testing design documents release notes etc this would add variable and demonstratable
values to the project development so deword is very helpful to scrum while identifying
the deliverables to achieve the objectives of project for the stated reasonable so defining
the steps required to deliver the iterations the usage of appropriate tool like burn down
to make the process more effective ensuring on-time feedback throughout the project life
cycle ensuring the walkthrough of the product backlog items are done and understood correctly
so then creation of checklist for product backlog item ensuring the deword is defined
to become task oriented involving the product owner for reviewing during this print and
sprint retrospective that is about dod the next question how can a scrum master be a
servant leader so very important thing to understand so what is the meaning of the servant
leader the term servant leader mainly stresses on service orientation which a leader should
demonstrate so today we say every organization is service organization even an organization
who is producing card if there is no service orientation they cannot sell so more stresses
on being service orientation the scrum master needs to be facilitator a guide a mentor etc
this helps the team have increased involvement and empowerment so now question number 32
how can one coordinate between multiple teams so one of the most common approaches for this
is kram of scrum's meeting so where members representing each scrum team discusses the
progress performance issues risk etc together this is complex structure what you're speaking
about the frequency of these meetings must be predefined well articulated well defined
generally scrum master would represent the particular scrum team on behalf of that scrum
team they would go and represent the meeting represent in the meeting besides having a
chief scrum master who's responsible is coordination and collaboration among all scrubs who facilitates
these meetings thank you guys with that we have reached the end of the scrum full course
video by simply learn i hope you have found this informative and helpful thank you for
watching stay tuned for more from simply learn hi there if you like this video subscribe
to the simply learn youtube channel and click here to watch similar videos turn it up and
get certified click here