Comprehensive Overview of Scrum Methodology and Practices

[Music] hey guys welcome to scrub master full course video by simply learn

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