Transcript for:
Daily Scrum and Scrum Events

he's kamis welcome to this daily scrum live demo  session friends we all know that after scrum guide   2020 updates traditional three questions are no  longer mandatory so in this session we are giving   you totally different new trending daily scrum  questions which you can also propose to your   teams so this session is also going to beneficial  for all new wannabe scrum masters who want to know   how daily scrum looks like and after watching  this session they can gain more confidence   friends we really appreciate if you hit one like  for our team members efforts your one lag is a   big motivation for all of us and if you new to  our channel please do subscribe for more real   life valuable content so without further delay  let's begin our session over to you shashank   yep before we get into the topic so that's me so   my name is shashank pachnuri i'm a scrum master  in india with 10 years of it experience i am an   agile enthusiast helping organizations and teams  on their journey towards agile transformation   with an agile mindset using various frameworks  tools and techniques now let's get into the topic yes so daily scrum meeting rules so what is daily  scrum for those who are new to agile and being   there beginning their agile journey allow me to  take a couple of minutes to brief you about daily   scrum meeting the daily scrum is one of the five  events the scrum framework offers the daily scrum   is often referred to as the stand-up which comes  from extreme programming instagram framework   on each day of the sprint the whole the team holds  a daily sprint meeting called the daily scrum   meetings are typically held in the same location  and at the same time each day ideally a daily   scrum meeting is held in the morning as it  happens and it has it helps set the context   for the coming days work these crumb meetings are  strictly time boxed to 15 minutes this keeps the   discussions brisk but relevant the purpose of the  daily scrum is to help progress towards a sprint   goal and to form a 24-hour plan to increase  the likelihood of the sprint goal being met   all team members are required to attend scrum  meetings since both the scrum master and the   product owner are committed team members  they are expected to attend and participate   anyone else for example a  departmental vice president   a sales person or a developer from another project  is allowed to attend as a passive audience and   listen this makes scrum meetings an excellent  way for a scrum team to decimate information if you're interested in hearing what where things  are at attend that day's meeting the daily scrum   meeting is not used as a problem solving or issue  issue resolve issue resolution meeting rather   issues are raised and taken offline and usually  dealt with by the relevant sub-group immediately   after the meeting during the daily scrum each  team member answers the following three questions   what did you do yesterday what will you do  today are there any any impediments in your way   by focusing on what was what each person  accomplished yesterday and will accomplish today   the team gains an excellent understanding of what  work has been done and what work remains the daily   scrum meeting is not a status update meeting  in which a boss is collecting information about   who is behind schedule rather it is a meeting in  which team members make commitments to each other   any impediments that are raised in the  scrum meeting become the scrum master's   responsibility to ensure that are that  they are resolved as quickly as possible   typical impediments are for example i need  help debugging a program or problem with   an xyz or i'm struggling to learn xyz  and would like to pair with someone on it   or it also can be i cannot get the so and so group  give me any time and i need to meet with them   or you can say some another example could be the  departmental vp has asked me to work on something   else for a day or two right you might have heard  most of such scenarios with your teams as well   right in such cases where the scrum masters cannot  remove these impediments directly by himself   example usually the more  technical issues when which were   brief right now one of the examples he still  takes responsibility for making sure someone   on the team does quickly resolve the issue  most teams conduct the daily scrum meeting   by having each person answer three questions  in order you answer all three questions then   the next person and the next and so  on an interesting alternative that   some teams find helpful is to talk through one  product backlog item before moving on to the next   in this way an individual may get an update at  multiple different times during the same meeting now let's take a look at the set of questions  that we have all right so set a is nothing but   the classic questions that we often keep using  them it could be a different phrase a different   sentence framework might vary right the questions  might vary based on the framework of the question   what story did you work on yesterday who worked  on it with you and what story did you plan to   tackle today what will you work with on it who  will you work with on it what obstacles if any   do you anticipate to finish so these set of  classic questions are commonly used in all   the teams both new and experienced teams now  let us take a look at the new trending set   of questions that enable the teams to have a  different perspective and think out of the box the next set of questions  is called as shared learning in this set of questions can help teams which  are in the forming stage which have begun   the journey towards agile transformation these  questions can help teams to share their ways of   learning bait research or investigation they  are doing throughout the day to ensure the   set of tasks or commitments for the day  are completed this will help team members   to share different ways of approach to one  problem which can help other team members   the questions are in the work you did yesterday  what did you learn that could help the whole team   what do you hope to learn today how will you   share it with all of us what  gets in your way of learning and comes the next set of questions  wherein you're trying to find some help   this set of questions can help new and experienced  teams which are in forming or norming stage   this set of questions allows team members  to share their library of knowledge   that they refer to in order to address any  issues or challenges these questions allows   teams to explore and share knowledge or sources  of knowledge and help each other the questions are   what helpful resources example websites books  articles repositories team members expertise etc   did you access yesterday for your work wherever  you look for help today when have you found it   difficult to find helpful  resources what gets in the way the next set of questions are set d that is  achieving the plan in this set of questions uh can   help both uh they can help the experienced teams  strategize to achieve the plan no sprint goal   can be achieved by a single person in the team  it is a collaborative effort of the whole team   with these questions it reminds all the team  members all the team players to know how important   their role is to achieve the plan by using the  confidence index towards the end of the questions   on a scale of 0 to 5 we come up we  come to know the pulse of the team   which boosts their morale and confidence  sprint confidence level sprint after sprint   let's take a look at the questions how did  you help the team move towards achieving our   iteration plan yesterday how will you  help us move forward in the plan today   what will impede your progress and on a scale  of zero to five zero being no way and five being   super confident how confident are you that we  will complete all the work in our iteration plan coming to the last but not the least set of  questions this set of questions uh can help   new or experienced teams to realize  the significance of the commitments   and that their commitments are to one another so what are the questions so the questions are  what did you commit yesterday what do you hope   to commit today what hinders your ability  to continuously integrate your work today   so those were some interesting questions i  hope uh these are something different which   uh you can utilize you will help your teams  to come up with different ideas and thoughts   during your daily scrum meetings i would  also like to share a couple of basic uh   rules or maybe you can say just during  the meetings which i share with my teams   so some do's and don'ts in a meeting which can  really be helpful for your meetings to be more   effective and more informative so the do's are  please turn on your camera for all the meetings   so i request all my team members to turn on the  cameras why the camera should be turned on so   as we are all are connected virtually the  two most important factors that we need to   utilize to the fullest to ensure maximum  exchange of information via communication   is audio and video in any virtual meeting this  will help the facilitator the scrum master   to know if you're able to keep up with  the discussion or you want us to slow down   and another important point is that this will  also help the facilitator know that if you   that you are participating in the meeting  hundred percent as we might need your thoughts   and inputs during any point of the meeting  and the most next important point is ensure   internet connection is stable and bandwidth  is good enough to support video calls   and the don'ts are please do not multitask  during any meeting team might get might need   your 100 attention to provide suggestions  and valuable inputs during the meeting   don't be late to meetings always join  the meeting on time to have a productive   and time box meetings to our extension  that might impact the following meetings   so these do's and don'ts are for any meeting  regardless of any event uh throughout your   day right so i think these are some basic  instructions that we can share with our teams   so i just thought to share with you all all right  i think that was it for today hey thanks sashank   for that presentation over to you shashank you  can start the demo now all right thank you sanam   so let me quickly start sharing my screen and  we will begin with our deletes from today guys   all right i hope you're all  able to see my screen yes yes   awesome so yes guys so like we've been doing our  daily scrum every day using some classic questions   right the regular questions that we have what did  you work on yesterday what story did you plan for   today and what improvements that you have right so  just to break that uh monotonous questions so we   have come up with some new set of questions like  we just introduced on day one of our spring today   so let us go ahead with this set of questions that  i said be where neha will be sharing her plan for   the day and yeah what do you mean yeah hi shashank  good morning so yesterday i worked on ui creation   for login page i have learned the optimized  way of routing the page so basically this will   help our team towards uh to achieve our initial  step towards our sprint goal so today i will be   working on database creation of login page so here  after today's task i will hoping to learn to write   the optimized way or good way of query basically  so in the every task that i do basically i will   definitely i learn definitely i learn something  so uh when i will complete my all the tasks i am   i'm hoping or i will be in a part to learn about  a database like in how to increase the memory of   database or how to write a good query that is  all from my aunt nice thanks great thanks nikha all right now let's move on to the next set of  questions that is said see finding help so deepika   would you like to share your updates on your story  with respect to these questions sure shashank so   i'm working with respect to assist 11 uh user  story so with respect to that task i have been   contact i contacted ramya by cover po with respect  to few uh inputs as discussed in the last call so   she has given me a few changes and almost 60 to 70  percent i have completed on the task and regarding   where will you look up for the health today i  want your uh help because i have to contact the   squad team and also center of excellence what  ramya has suggested as per that and this is   the impediment i am facing and i you can give it  to us and before that i will try to investigate   from my end and if it is not possible i will reach  out to you for help sure yes thank you thank you all right now let's go to  the next set of questions   that is set d okay over to you kately would  you like to share your updates for today here yeah sure um so as for the sprint goal we are  targeting to implement the login page for the   portal itself in this print so for that uh  my story was related to the masking of the   login page password uh i tried yesterday  uh building on a framework which can easily   enable the functionality but currently i am facing  uh so my plan was to move ahead forward today but   yesterday i had connected with some teams who  have already worked on it but somehow is that   is not working maybe they will have capacity or  they don't have time for help so shashanka would   need your help in this uh to help me solve this  impediment and um on a scale of zero to five i am   currently not very confident because we are on the  fifth day of the sprint so um we would be uh maybe   on a scale of five i'm at two currently if we get  little help i'm sure we'll be able to do the story   sure definitely we'll catch up offline and we'll  get to speak with those team members and we'll get   all the help you need to make it fine all right  sure thank you thank you for sure awesome great would you like to share your updates yeah sure  also mine is ss14 yes yep as we committed the   implementation for login functionality right  so the backend part is already completed   implementation of the services and the ui part  was taken care by the pica that also completed   but the challenging part here was the backend  the production data which we are expecting from   the client side to validate the same uh from the  development perspective uh hope we are getting   this today so that there are no implements at  this moment we have completed all the development   part only thing is waiting for the testing from  development and if we have completing then we   are good so part of like confident level from zero  to five i could say like uh uh we are sure we will   compete by today absolutely like this that's great  thanks thanks for the confidence there all right   so now let's go to the next set of questions that  is set e continuous integration so we have sindhu hey hi shashank hi everyone so mine  is three yes all right thank you   so shashank on this i do have uh four subtasks  like a full name email address username password   i have to create i'm done with the  full name username and password   yesterday i was about to finish all this item  i was committed to do that however i was facing   some kind of issues with email address the issues  with regular expression so when i'm validating   with regular expressions i was struck and still  now i'm not able to clear that one team anyone   aware of this issue anyone have worked with  regular expressions can anyone help me on this   uh yes i can help you with that i have  done that in the last field itself so   it's quite fresh oh thank you kitty then  i will start to work on the sign up below   the fields place a clickable button sign up below  the fields that was that as well i need to finish   so i will work on that once after your  work can you please help me on that kitty   sure sure i'll do that thank you so much kitty  you are very kind so shashank that's it with   the help of kitty probably i will try to finish  this by uh tomorrow at maximum both of this item   yes yes we'll do it together no problem yeah  thank you kitty that's it on my end thank you   that was an impediment i faced yesterday and still  i'm continuing tomorrow hopefully i will make it all right thank you so much thank you for  jumping in there for helping all right so   that was really quick guys thank you so  much for sharing your updates and yes   so and coming to the questions uh so i hope you  all uh i hope you are enjoying the way you are   uh integrating these questions to the  day however we are planning every day   and our continuous you know our goal towards  what uh to achieving a sprint goal what we've   been doing every week so yes thank you so  much guys and you guys are really quickly   adapted to the new set of questions that we  shared and you're always ready for the experiment so yeah thanks for that guys and yeah  coming to the action items for me so with   deepika i'll be working with deepika where  we connect with the center of excellence for   uh the dashboard ui integration approvals and  also we raise the change request if needed to   implement the same yeah and coming to tt she  wants help on connecting with the web framework   who have built the same masking functionality so  i'll be doing that uh and then get back to you   guys by end of the day and so that we can quickly  uh resolve them and we can remove that with the   roadblocks yeah yeah sure thank you awesome  so apart from just any other challenges or   any risks that you see guys that you see which  is which might stop us achieving a sprint rule   anything comes to your mind not  only the stories anything else okay copy machines are not working i'll  work on that and i'll work on with the admin okay guys so uh today uh we are going to talk  about the sprint planning so what is sprint   planning so sprint planning is uh one of the main  main event uh uh you know that is the scrum guys   suggest and it actually kicks off this print right  and the main purpose for having a sprint planning   is what can be delivered at the end of the sprint  and uh how that work can be achieved so this the   definition that you're seeing here on the slide  it's taken from the scrum guide so let me just   read through it and just take a note that each  word in this definition has its own meaning so   i'm just reading it through reading it through  and then maybe we can discuss more so is print   planning initiate the sprint by laying out the  work to be performed for the sprint the resulting   plan is created by collaborative work of the  entire scrum team okay the product owner ensures   that attendees are prepared to discuss the most  important product backlog items and how they map   to the product goal the scrum team may also invite  other people to attend sprint planning to provide   advice so yeah so this is the definition that the  scrum guide provides so as i already the purpose   of this print planning is to define what can be  delivered at the end of the sprint and how that   work will be achieved so we will get more into  that in the you know few further slides uh so one   thing i like to highlight here is uh three things  that uh is the the intent of stream planning is to   look at the three things one is uh why this  print plan is the sprint is valuable so   how we can find that is by looking at the item  the user storage that we are going to pick up   for this print is is how is it how it is aligned  to the product goal right and the second thing   is uh what can be done in this print so once uh  we uh we are aware of the pos uh help the team   to understand what all user stories are aligned  to the product goal when we pick up from the uh   the user stories in the order of priority and we  decide like what all things based on the available   capacity of the team and their past performance  or the previous velocity we pick up those items   so that is something we decide as part of the  sprint planning and at the end how will we choose   the work to get there and get done so again this  lies with the developers within the scrum team   so they decide how this works needs to be done and  completed within the sprint so in this case uh the   po or the scrum master or no one outside from the  team should influence the developers so they are   the one who take the accountability and decide  how this works uh that they are committing for   the sprint needs to be done yeah and one more  thing uh this plane planning our time box to   say eight hours for a one month long sprint and  and uh and in case of a shortest print uh the   duration gets proportionally shorter so for a  two week sprint mostly the teams i have noticed   or experienced in past they follow the two weeks  sprint and uh normally for two weeks sprint the   what the scrum guide suggests is uh the sprint  panic should happen for two hours or less okay   so again if if the teams are mature and uh if  the team has done a good refinement throughout   the previous sprint there are chances that the  sprint planning may not last may not take to   us we can finish it even in the lesser time with  that being said i'll move on to the next slide so   who all should participate in the sprint planning  so first of all the scrum team is mandatory to be   one of the major participants for this sprint  planning meeting and what uh when i'm saying   scrum team or the product owner the scrum master  and developers all three roles should be present   and participate yeah and there will be cases when  the stakeholders or the business sponsors can be   invited so suppose there is some ambiguity around  one of the user's story where the team needs some   answers from the business or the stakeholders  so in those cases uh scrum master or the po   can invite the stakeholders or business persons  into the sprint planning meeting so that they can   help the team in clarifying any questions or any  open issues right it's it's not like they should   you know estimate or they should  enforce team to pick up something   they will just be there in the meeting to  help the team on clarification part all right   so that's on the participant part for this  print planning i'll move on to the next slide   so what all things uh that uh the team should  do before sprint planning when i'm saying team   again it's consisting of both po team developers  and scrum master so before getting into the   sprint planning meeting the product owner  should make sure that the product backlog is   ordered in the list of highest priority based on  the uh product goal that we are trying to achieve   right and we also need to make sure that the user  stories are as per the definition of ready so   definition of ready is again something which which  varies based on teams two teams so each team will   uh sit together maybe and they come up with the  pointers which they uh call it as a definition of   ready and if those pointers were not met they  normally don't take up those stories or don't   commit for those user stories during the sprint  planning right so this pointers can be anything   like uh you know there should be no external  dependency uh or or the acceptance criteria   will be you know written in a clear manner so it  again as i said it depends on team two team so   they should come out with a definition of ready  pointers and the po should make sure that the   prioritized user story that he wants  team to be pick up in the upcoming sprint   should have should meet this criteria for  definition of ready before the sprint planning   uh the next point is uh okay i already discussed  that the privatize is a story to die yeah   so uh team should have the refinement station  in the in a previous sprint before the sprint   planning and in during this refinement session  uh the po will already have some idea like what   all things what can be the sprint goal for the  next print and based on that he will have a few   of the prioritized story and uh the team sit  together during this refinement session they   go through this uh stories try to understand what  uh what is the business value of it and uh and the   focus should be on why and what part and not on  how part okay how like how they should uh you know   complete this story the focus should be on why and  how part so they try to get all the answers from   maybe all their doubts clarified by the po during  these meetings and then uh since the team consists   of different skills right like maybe a designer  a tester developer front-end developer back-end   developer so everyone should have a shared  understanding so that's the main purpose of   having a refinement session everyone should have  a shared understanding of what the user's theory   is about and what is required and once uh the team  is having the shared understanding then the scrum   master can help the team to estimate those uh  users stories during this refinement session again   the best practice to refine these stories  is using story points but yeah again a team   can take up any any estimation techniques  for that matter maybe t-shirt sizing or   linear numbers or there are still few teams who  do it in a manner which i don't recommend and even   which is not a good way to do but yeah so once  uh another thing before student planning is   half the practice your story is refined and  estimated okay and then the third one is that uh   again it's not uh very critical but if team has  uh some uh vacation plans in upcoming sprint maybe   they should uh highlight that before getting into  the sprint animating so uh jira or azure devops if   you are using there are plugins in jira and azure  devops also has inbuilt capability where a team   can update their capacity for the next print so  it will give a visibility to the both pu and the   scrum master before getting into the planning that  okay what will be the available capacity and based   on that they can think about their sprint goal  or modify their sprint goal right so that's one   thing and in the cases where uh there is no tools  uh electronic tool where the team can update maybe   uh the scrum master can create one excel template  for uh you know for updating the capacity and keep   it in some shared location where a team can  go and update their planned leaves or some training if they are getting into a training  or they are not available for doing the   you know the sprint work they can highlight  those unavailable times okay so this is what uh   normally we do before getting into the sprint  planning meeting moving on uh what all things   we do during the sprint panning meeting so  i i have listed out the pointers in sequence   like how it goes uh so i will follow the same so  during the sprint planning meeting we start uh the   scrum master we facilitate the meeting uh first  of all so he will uh ask of the product owner to   share uh what is his vision for that upcoming  sprint yeah and uh the product owner he has some   uh some product sprinkle in his mind and uh he  will uh propose that his print goal to the team   and then uh the scrub master since pu has already  uh kept the project backlog in the order of   priority based on the sprint goal uh subscribers  will start navigating the user series from the top   and uh if team has already refined those user  stories uh well and good if not we will uh we will   again go through each user's stories one at a time  and if those are refined those are assimilated   well and good we'll just have a quick discussion  and we'll move on to the next one but if they are   not then we will use the planning meeting to again  refine it get all the answers clarify all the   questions clarified from the po if there is any uh  doubt or any dependency teams can highlight them   can discuss through it and we'll again refine and  do a simulation during the planning meeting itself   in case the user's theories were not refined  or not discussed during the refinement meeting   okay so when this is done maybe when we went  through all the user stories that were uh   shortlisted by product owner as part of the  sprint goal once we went through all then uh   you know we will uh check the capacity of team  uh so i had mentioned that the team will either   fill on the capacity excel or in the tool prior  to coming to the sprint planning if that is not   done maybe scrum master can quickly uh check with  all the team members and fill up the capacity and   check what is the available capacity and then  they will scrum master will help show the past   performance of the team like what is their let's  say last average velocity of the last three sprint   and uh what was their pass performance how many  stories they were delivering uh so like looking   at these two items the available capacity and  the past performance the past velocity team will   commit the user stories okay so once that is done  uh so it may happen that uh you know say po has   selected uh say six user stories but uh based on  teams available capacity or their pass velocity we   can team can pick just four so in that case we  may have two to you know negotiate with po and   change our sprint goal so that thing will also  happen at this moment so a team can work with   po and then we can modify and finalize our sprint  goal suppose that uh team of the scrum master will   ask team to break down all the user stories into  tasks so what all tasks that is needed to complete   that user story so one user story can uh may need  uh you know contribution from all the skills maybe   some contribution from a tester from a developer  or or maybe two developers in that case so   we promote generally we in scrum we promote uh  cross-functionality functional team members but   sometimes it doesn't happen uh in on the ground it  doesn't happen we try to keep a cross-functional   team where all the skills needed to deliver a  story is present right so now what we do here   we will break down the task and so the owner  of the user's theory can be one person but   the task can be owned by multiple person so  that is the idea here right so now each of   the individuals will add the task under these  user stories and they will uh give some hour   estimation based on their prior experience and  whatever the sheer understanding that they had   based on the discussion we had during  refinement even during the planning   so team started giving the our estimation again  this is an at individual level say i am creating   a task which i am going to perform so i will  give the hours based on my understanding and my   skill level so a fresher can as i said like as  a fresher can may for a similar task a fresher   can take say to a loss but a senior member  may take for us so we are not going to judge   anyone uh so this our estimation should be  at the individual level but i'm just just   want to highlight one more thing here the story  estimation that we're talking about at the top   that should be at the team level where the  story will be estimated based based on some   benchmark story that team has already decided and  based on the shared understanding of the team and   everyone should agree to the you know same number  while doing a story point estimation but during   our estimation it should be at the individual  level i just wanted to clarify before moving ahead   okay so moving on uh yeah so yeah i think i  covered the last part as well so this is all the   things that we do during the spring planning  okay and once we close the sprint planning   the sprint get kick-started and uh team get to  start started working on the committed stories   so these are the things a few things  that we do after the sprint planning   so we again before closing or maybe after closing  the scrum master again verify the sprint goal is   meeting uh from the committed stories by the team  yeah uh if uh the sprint goal has something which   which the which is uh not there uh in the  committed stories maybe it's like uh that   story is uh not taken by the team maybe we have to  work with the po again to modify and finalize so   the chances of that team while negotiating and  finalizing their sprinkle this item is taken   care but it's a good thing for scrum master to  cross check after the sprint planning the next is   circulate the spring planning notes to the all the  team and the stakeholders and the business so that   the business and the stakeholders are aware that  what they can expect at the end of the next sprint   so uh this is more of a setting expectation and  being transparent so transparency is one of the   key values right so we have to be transparent with  our stakeholders for business uh then the next one   we have is the other team will start development  on the committed user stories and throughout the   sprint uh team as well as the scrum master we  all can you know track the progress towards the   screen goal we can use the burn down chart or  maybe look at the board to see how things are   progressing we should keep an eye open to look  out for the impediment or any dependencies and   if there are any maybe scrum master or po can  help you know can pitch in and try to help or   maybe at least uh help team to understand  what what all things are impediments and   make them highlight or voice out those the initial  phase rather than taking it till the uh end of the   sprint so these are the few things that the scrum  team can do after the sprint planning so a quick   two things so what are the prerequisite for the  sprint planning of course the prioritized backlog   refined and estimated user stories again it's not  mandatory there can be a chances that after the   team done their refinement and before we get into  the sprint planning things have changed outside   and pio has some new user stories to be introduced  to the team so this is a good prerequisite but   it's again not the final but you can always  introduce some user stories uh during the plan   uh then the definition of ready and the planned  capacity okay one more thing about definition of   ready is uh though the pointers the team come up  with these pointers and and they commit to user   stories only when this definition of ready  is met but again it's not military and not   you know suggested by or not mandated by the scrum  guide as well so there are chances that uh team   uh you know is aware that okay though one of the  point is not met but we know so suppose there is a   external dependency but they know that dependency  will uh end with by the first week of the sprint   so with that condition they take up the  take up those you know commit for those   stories as well so it is not mandated and it's  not a hard and fast rule our team can always uh   tweak it quick around these things so what are the  deliverables for from the spring planning there   are two things one is the sprint goal or which  should be aligned to the bigger project goal   and uh and then the sprint backlog which  should help the team to achieve the   sprint goal uh one more thing i like to highlight  here the spreading backlog will may contain the   user storage which may not be aligned with  the sprint goal so there are chances uh the   team also working on something else which may not  align with the sprinkles for example maybe some   uh technical dates or some spike which may come up  in the next print yeah or maybe some retro action   item so it can be anything so sprint backlog will  have will contain the user stories which should   uh you know suffice the sprinkle but it  it can also have some other other user   stories or other work items which may not you  know uh have direct impact on the sprint goal   okay so that's uh the basic of this print  planning i shared with you guys and the next   is the role play exercise so sunand you  want me to continue here or you want to okay hi team so today uh welcome  to the sprint planning meeting so   today i have a po ahmet is going to talk about  or share what we are supposed to do for uh   one of the highest priority item that  we're going to take up in the sprint   uh so over to amit okay uh thank you shovik so uh  team as we have already estimated and refined uh   three of the four user stories uh we won't go  for those i would like to share and bring to the   attention this fourth user story which is for  searching uh functionality that we have to add   um as part of the use uh user sorry i'll  quickly reiterate for this forum uh as an   online customer i need to search for products so  that i can find the ones that i want to buy pretty   simple one acceptance criteria is something like  uh search for a product by name or category that   would be our first scenario uh view products by  category view images and details for each product   and last one is add to cart from the from the  detail or search pages so yeah open to questions so after this what we'll do is we'll try to  estimate this user story but first want to   understand if there are any questions yes  amit uh so one question probably so are we   already having a list of uh products to be  included into the portal or is it going to   be like a dynamic addition so right now we have  a database of images already um after this search   functionality we would add a certain drop down  or text field uh with which we'll be able to   search the product either by name or category  or whatever scenarios you can see right now okay okay so view it by category it is  like a freezer is it it's like a what sorry on certain category and then while  you're searching you can just either   select that particular category or you  can change it from the dropdown that this   drop down of category it's already  there on the left side of the page right so after clicking on add to cart we have to  navigate to the another page right correct so that   whatever items you have in the cart those would  be uh retail and then when we go uh to the cart   page we can search in there as well so the same  functionality uh search functionality that we have   it could be replicated on the cart page as  well okay and the wireframe for front-end send   it is available correct so wireframe are already  created i have it from the ui ux designer they're   pending for one final approval from customer  i have it in my mailbox i'll share the latest   version over the mail after this call okay yeah  i have one question like uh in like if you are   working on the search criteria is it required  that you know the add to cart from the detail   or the search pages it is required or should  we have it separate so uh with the upcoming uh   festival time that that's going to come soon  we are the customer is actually optimistic   wherein they are hoping to have a huge list of  products that people would be putting in their   cart and that's why they are hoping that if people  want to search some some particular product in   in the cart page as well so we'll just replicate  the same functionality on the cart page   no big thing no changes in the search  functionality as such this is the same uh   way we would be searching on every page the same  would be replicated on the page of cart as well   okay thank you makes it clear uh hello uh i have  one question like are you going to have uh any uh   you know like obviously wish list uh like just  not adding into the cart but people want to add   some product in the wish list as well so are you  going to add that one i'll i'll take that note for   the customer and uh i'll check with them if if if  this would be added we'll create a new user story   preferably a new epic as well and we'll see how it  goes but i have taken that note uh in in parallel   thank you and one one more question  uh when we are displaying the images   are you going to add any short uh like  shorting technique will be there so the   images uh would be there of the product itself  and we are searching by the product and now   the the search criterias are there on  the screen itself so by name by category   or whatever details we are trying to put in in  the search box it would be uh searched as for that okay but uh like in short functionality in the  sense uh if people want to see like low to higher   price product first or higher to low price product  first so in that i mean i'm i just say oh i i   yeah maybe i misunderstood we are talking about  searching here sorting would be a different thing   so when when i search it would be searched by  name or something sorting i'll again take a note   and yeah actually i'm talking about the viewing  the viewing the images actually displaying the   images on the screen so how it will be do you  have any short functionality so right now we have   default uh sorting which is a to z alphabetical  order okay okay you want to show anything from   the previous searches as well in the search  box uh no not right now i'll take a note of   that as well um if we want to retain that previous  searches done by the user because that would again   require a certain number of uh searches to be  saved and captured within the db as well yeah   so i'll check with customer if you want to add  that functionality i mean how many list items are   how many items are expected on one page correct so  right now uh whenever we are viewing the products   they are listed in uh 10 uh batches of 10 so 1  to 10 11 to 20 something like that search would   again reuse the same functionality and we would  go by the same way so whenever we are searching   it let's say we have uh 70 or 80 products so  that that that are refined by the search we   would go from 1 to 10 11 to 20 something like  that so same everything would be replicated so   in one pitch 10 products we can expect right yes  yes thank you okay so my understanding currently   it is a requirement for the web application  not for mobile um no our portal is also uh   viewing and it's working just  fine on the mobile as well right   uh we'll we'll just continue on the mobile  side as well no changes on that side uh hi ms gautham here one question from yn  uh while we search for the product uh will   it show some reference like what i search  will the will it auto complete in the search   box that's a good point i have  not considered i'll add that uh   in the points to be discussed with  customers thank you that's a good suggestion can i search for a product if it is not available  is there be like i mean is there already a future   available when the product is available there will  be a notification right so um i'll also add that   part as part of the acceptance criteria so might  be a negative scenario wherein if there is nothing   uh coming out uh because of the as a result  of the search we'll just show a blank page uh   something like uh oh your product or your search  didn't result into uh our product would you like   to uh search something else or we will show our  top product something like that so i'll add that   i'll get it checked with the customer  and i'll add it as the fifth point here   uh yeah yeah actually i think uh my question was  different so when i'm using a product the product   is not available right now it will be available  after 10 days so are we go is there a future that   will notify when the product is available  so i i will check with customer on this one uh also amit is for for browsing and  searching product uh in the portal   is authentication and authorization is  mandatory uh no you can uh search uh without   logging in so you're just browsing and window  shopping kind of a thing you can do that okay are we good to poke and now just so  in the search results it will display so right now whatever the products we have by  default uh with discount or without discount   whatever list we have in our database will just  reflect that same as part of the search if it is   having discount if it's applicable we'll show it  as it is if it doesn't we'll show correspondingly you guys i think we have enough info shall we  yeah so any any more questions from anyone any   i haven't heard anything from the validation part  anyone want to check on anything or are we good i think we are good yeah we're pretty much clear you have some something yeah i think as part  of validation and verification of the products   i think there are some many quite a few corner  scenarios or use cases that needs to be considered   here uh to ensure that the existing portal  is working as expected and the new changes   which are coming as part of search product is not  getting making any changes to the existing portal   so i think there are quite a few uh corners in us  because we'll be navigating through multiple pages   uh in that aspect i think uh there should  be some uh quite a lot of testing to be done   in that area so that is my observation so as we  proceed i think there could be some increase or   decrease in the scope but yeah i think for  now i think based on that we can proceed   sure further point sasha thanks thanks for  bringing that up uh okay before we get into poker   one with a couple of things that i want to check  with um you mentioned that the wireframes the   final approval is pending so till how much time we  can expect that right so um if we don't receive it   by uh 10 a.m tomorrow morning i have a schedule  called with the customer at 11 11 30 something   around that time if you don't have it by that  time i'll get you by lunchtime tomorrow itself   but we won't hold any more on that i'll definitely  get you that just to keep you guys moving uh like   i said i'll also share that in on the mail just  after this call so that you have idea of what all   components you're going to bring in on the screen  so i i hope that helps okay that will be a help   and one more thing uh the question asked by  satish i believe so the error page you said that   we will show up somewhere so what exactly you  are going to show that also you are going to get   the confirmation from the customer right so yes  what can what will be the etf for that uh i think   it won't it should not take much time i i can get  that done in that call itself so by tomorrow same   time slot i i'll get you the details sure again  that will help amit and then the couple of more   things that retain search and auto complete even  if a customer agrees to that do that it will come   up as a separate user story maybe 100 it won't  be it this this particular user won't be extended   it would come as a new scope new user story great  okay okay guys uh any any more questions for amit   uh are we all aligned about what this user story  needs yes one last point i had i think yeah sorry   yeah so one last point is like add to cart  so if we have zero one or many products uh   within the cart so um will be uh having another  acceptance criteria or another story to test that   card details as well uh can you see that shishanka  again i i didn't follow uh yeah yeah so uh i had   to cut the last point in the acceptance criteria  right so i took out from the details to search   pages so i was wondering because if we can  have different use cases like if there are zero   items in the cart or one item in the cart or many  items in the cart right so in that aspect zero one   many uh if we consider that like we have in  the wazer technique right off for splitting   the stories so in that aspects do we see that uh  there is a need for splitting the story in that   for to get the acceptance criteria there uh uh  sure we can uh we can extend that i i understood   yes we can do that yeah yeah thank you okay  sure okay so i assume that there's no more   questions and we are aligned on what needs to be  done so we can get into the planning poker yeah   yeah okay so guys uh while uh giving the  score uh think of the login functionality   which is our benchmark story that  we completed in our first print   so that was a two pointer very basic so compare uh  this story with that relatively like how bigger or   how complicated this story in comparison to that  well giving your scores yeah and uh maybe you can   consider all the acceptance criteria that amit  has mentioned think about uh all the validation   part right as sashank mentioned that scope uh  think about the scope as this feature need to be   developed in both mobile and desktop and we have  to test in different devices as well as different   browsers so keeping all that in mind and all the  discussion that we had give your score please um okay adele yes i am yeah yeah have you given a score i've  given my score yeah okay and chunky only uses left shankly have any issues with uh giving your scores   uh yeah it shows disabled  i'm not able to do anything okay maybe okay we're just waiting for shankari okay so we  have got all the schools uh let's reveal the cards okay so yeah quite a diverse so  i see a lot of folks given eight   couple of them has given five and shashank  has given 13. so uh let's uh hear out from uh   the outliers maybe first we can hear out from  uh bratati and shangri why they have given five   maybe what was your uh thought process or your  point of view for giving doing the story five shank you want to talk about that oh yeah uh it  is so i think based on the login page and this is   for authentication and authorization uh so most of  the thing i think the coding will be we can we can   use it from the existing codes so  uh also it is a very uh uh regular   uh uh what to say the regular feature  that we are working on so i think uh   we can have a five story point on this if  there is no further difficulties on that you haven't want to add anything yeah uh yeah  i agree with the shankari that we are not   doing that much like we are not doing  any transaction thing over here just uh   searching the product if we are getting then  we are displaying it if it is not then we are   trying to display the error message or you know  whatever we have decided upon later so based on   the login functionality i have chosen  that five pointer here okay okay   fair enough sure thanks thanks for for the  comments uh what made you give it a 13 pointer   uh yes sherwick i think because uh considering the  point that in the acceptance criteria there is a   scope of still we can slice the story based on the  card details right so based on the number of items   i think i think based on that and also on  the corner scenarios that we have on the   number of use cases uh and also we need  to test on both the desktop and mobile   uh considering all these aspects uh uh  you know considering the efforts and the   um required and also storage splicing which could  be uh needed here in case of uh any much more   details once we get from amit and the customer so  i think once because based on because including   that uh the card details also if we need to  validate in that aspect i think if we slice   that story into smaller pieces then i think we  can go down from 13 to maybe eight or five depends   but uh yeah it again it varies from the uh  acceptance criteria on the story so yeah okay so yeah amit what are your thoughts uh  i agree let's um so shazam would it help if   we bring in four scenarios specifically into a  new user sorry because i believe uh the first   three would be important to add maybe fourth  one we can try and negotiate with customer and   see let's implement three in this friend and  then fourth one in the next one would it help   yeah yeah yeah it's it's like uh we will be  if we split the story uh into smaller stories   i think that will be really helpful for us to  uh you know uh to reduce the efforts and also   um and we can uh complete the  story achievement faster right yeah   sure okay i'm taking it in my site  notes and uh yeah i'll save it further thank you back to you guys and i  think uh amaze having two pointer is it okay we'll go back there okay so yeah hello  guys i'm in the team as well uh yeah so i feel   you know the code is already available with us  the repository is also there so we just need to   apply the code and uh yeah and then we can see  because you know the search functionality is   also quite complex and in that sense if you  see the first four criterias are quite pretty   clear which we also developed in the previous  way as well so for me that is why i put two okay yeah so maybe i like to hear  out from others what they think i waited for voted for eight because i thought  you know like some of the functionality we can   definitely put in some other usable core  component uh but at the same time i think   the validation is definitely required and  some efforts on the automation as well   so thinking that i marked it as eight yeah i have also marked as eight considering  the development required for front-end   and back-end and also testing like we have to  test on different browsers as well and uh like   for mobile application also we need to test so  considering all these points i have voted eight okay so yeah uh what do you think now like the  team members are saying maybe the other things   will take more time uh that can be powerless yes i  can come to five or eight it's uh it should not be   challenging because i can see there are situations  seen clearly so i can even come to eight or five   it's okay with me but 13 is too much i guess  yeah yeah but you agree to the points that were   highlighted by adal and the other team members  right yeah okay great so uh sorry my uh the fonts   were very small so i [ __ ] i didn't able to see  that you get two pointer yeah so uh so yeah if now   if as a team we are aligned so amit has uh move  out one of the acceptance criteria and uh yeah so   when i move out one of the acceptance criteria and  uh now we have we can go for one more round maybe and see how much aligned we are okay yeah okay  can i start a new voting yes yes okay done thanks okay we're waiting for two more votes okay i think she has logged in from two side  okay that's fine maybe we can reveal the cards okay so now we have couple of fives and uh three  plus four five six eights so yeah i think we   are pretty much aligned but still i like to ask  shangri and uh and uh adel right uh are you guys   good to go with others oh yeah sure uh shall  we yeah i think uh i can go with it as well   okay okay so in that case maybe we can uh   put the 8 as our story point for  this particular story and move ahead okay so yeah maybe before uh moving to next theory  uh if we can uh do a quick task breakdown for this   particular thing so how we are going to do it is  what all things that needs to be done to complete   this story so amit will help me here uh you know  jotting down this point uh which will actually   come as a task inside the pbi inside the story so  you can uh i'll just link them i'll just relate   them to the story one you can just share the task  i'll update it here i'll mark it as a task yeah   if you guys can either say it or maybe  write it in the chat i'll copy and paste it   create a add card page okay so that's one of the tasks so guys uh  the thing here is to under understand is uh   whoever is uh going to work on those tasks uh they  should create like they should give the task right   to complete this theory maybe uh if  we can identify who all in the team   is going to work on that we can just  ask them to help us with the task maybe unmute and say that well is  going is yeah what are you working on what should be the task that you are  going to perform i just paint in the chat   okay so that's in short but i can  elaborate it once we add the task yeah sure   good okay so we have one task  that is create a ad card page uh   who is going to develop this anyone anywhere  i will be working on add card page okay just   one piece right now and any other developer  who wants to pick this up pick other things yeah i can pick one okay so other like what  all things you want to pick maybe we can   create a task for that uh i can work on the search  component maybe okay develop such component yeah   okay i'll add the mail ids with the assigned  name i'm just putting up in the comments here sure so will that suffice with that these  many works like creating a cart page   working on the search functionality  and validating and verification   is enough to deliver the story or  some other things needs to be done i'm looking at our yeah i need to work on the   services part which uh pull the  data from the database schema great so that's a b that was a bishop right yes   yeah okay so are we good with these  many tasks to complete this user story please thank you guys to test on multiple devices yeah we can cover in the same task  that is what we can mention uh we can   have some more sub tasks within the same  task where i will be mentioning browsers   on and the different devices that you'll be  testing yeah great okay so if first of all uh this   mini task supplies maybe you can quickly estimate  or give a rough estimation it's indicative uh us   in ours it's not like uh when actually we know  like when you actually get into it things may   change but uh to start with can you guys give  some uh hourly estimate for computer usual so you are saying you will just  take six hours to complete this task   no no i'm saying i'm saying like uh how are we  currently i'm just one no no i just wanted to know   how much how many hours you will need to complete  this task and that's again just an indicative date   it should not have to be exact yeah i think i'll  take uh 18 hours yeah 18 hours 18. cool okay uh   adil how about you uh to implement this search  solution i think uh eight hours should be okay i will take 12. so that covers okay here now   another this 8 hours is enough for you to  develop as well as perform the unit testing yeah cool uh abhishek how about you for if the uh are  available then i can do in eight hours okay uh   anyone has aware whether the schemas are already  with us or we have to work from the scratch we have the database and everything created  uh if avishay would need something specific   for search that would have to be created  from scratch sorry i interrupted satish   please go on same thing i was about to  tell it we already developed that so   it's available okay thank you cool so yeah  we shake we have we have the schemas ready   so based on that maybe you can give your uh an  estimation yeah then i'm able to finish in uh 18 right eight hours sorry okay okay i think uh we are good there so yeah this  will help us and uh at the end when we are doing   checking the capacity for committing the stories  here so yeah so shall we move to the next story or sunan sorry i think we are good uh yeah okay okay team uh so so we have uh pulled in uh  these four user stories and we have breakdown the   task for one of this user story that is solution  and uh we are given some uh our estimation to it   as well but uh keeping the time constraint in  mind uh let us let the team to add the task   outside the sprint planning so you guys can uh  you know connect and add the relevant tasks for   the other user stories and maybe you can add  the estimated hours for that them as well right okay so with that being said let's uh finalize  our sprint goal so let's hear it out from our   product owner amit what was the sprint goal that's  in your mind when we are taking up this show so as   per the vision for this print uh we are hoping  to have a search functionality implemented and   card authorization uh feature to be  uh implemented as well so those are yeah okay uh team what was the second one on it sorry uh card  card authorization c a rd card yes yeah okay so these are the two main features that uh   is the vision for this print and all the user  stories that we have picked up for this print   are going to enable these two features  so you guys anyone has anything to add i think we are good so we need the help from  all of you to write so spring goal should be a   statement it should not be like what all things  that we are doing so what should be the value   uh that we are going to generate by  delivering these two functionality   so maybe one liner that should  you guys can think of and come up of course summit can help  here see he has the vision   so while delivering this two functionalities  i'm at the what value we are going to generate so the value is people should be able to have  credit card authorization which would lead to   credit card payments as well and as part of search  functionality they can try and find the products   based on different categories which were  mentioned in the acceptance criteria   so as part of the sprint goal maybe  we can mention implement credit card   authorization feature along with  the search functionality for for the customers for the online  customers because both of them are   from the persona of online customers specifically such functionality for   for the online customers and how it's going to  help them maybe one line so that with increased   uh how should i say i think better user  experience yes better customer experiences better user experience yes correct okay so yeah  so this is our sprint goal anyone want to add or   modify this a better user experience  in all the device and the browser yeah thanks abhishek anyone else has anything  to add here or are you guys agreeing to it   sashank shankari oh yeah thank you i am  good good yeah good yeah we are good to go great okay so shall we finalize this i am going to   you know circulate this sprint goal along with  what all user stories we are going to commit   with the stakeholders after the planning  meeting shall i lock this answer okay great i'm just starting this i think  i think your camera is turned off   uh maybe it's turned on i'm sharing my screen  as some network issue we can't help in this okay   okay uh so the next thing is the capacity  planning so though as we discussed as a team that   we will create the task at the latest stage  outside this print uh stream planning and you guys   will add the effort estimation so maybe we'll have  the greater picture at the later point of time   but let's see uh how everyone's capacity is  looking alike so next week uh we and then do in   next week we have like in next sprint we do have  one holiday it seems so we have nine working days   okay and uh so these are the eight working hours  so let me just check uh okay so what are the any   any plant leaves guys i'll start with the first  i will shake any plant lifts in next few weeks   uh it's already mentioned i have a two  leaves plant okay so that's confirmed right   actually i'm traveling yes till 12th so till 12th  of october uh sashank you have any leap plans uh   yes shall we actually i'll be traveling next week  so uh i think i'll be away for the entire week   so five days you will be out right yeah okay sure  uh adil oh shall we come there okay no lead plans no leave plans okay uh okay so 16 is already mentioned here satish  how about you yeah i don't have any leaves   but two days i have full day i will be in  complete training i am taking so i think   you have to consider that also  here okay so i think team members so this column right okay fine uh gotham how about  you uh i will also be there for the entire respect   sorry can you come again no leave plans i'll  be ready for this okay cool thanks autumn   so it seems like uh our uh okay our network us is uh the team capacity is  around 408 hours okay and once you guys   fill up the effort estimation for the task that  you will going to pick up we will evaluate if   anyone is overloaded but i can see here that  sashank is having more than uh what he can take so anyone maybe uh the the storyline that sashank  is picking up or maybe anyone can help him here   so let me go back to her for uh testing parts yeah  yeah yeah i think the user story which i am going   to take i think i would be able to complete much  earlier so maybe i can help here shashank on this great so yeah one thing you can do  is maybe you can break down this   sub task into maybe some smaller unit and you  can uh check with satisf where he can help you   yeah sure thanks i'll collaborate with satish  and we'll work together to complete it here   great okay and so i think we are good here  yeah uh one last thing before we close out this   sprint is uh as we all know our uh average  velocity uh from the past three sprint is uh 20   uh actually it's 21 so now let's just see how many  uh stories we have committed for this sprint so it   seems like we have committed more than that  so it's like 20 38 it's around 40. so amit   we as a team like as our average velocity is uh  21 that too with uh almost full capacity but this   sprint uh couple of folks are out and sashayanka  is out for one week as well uh and the available   capacity is also so i'm assuming uh that we will  complete somewhere around 20 story point summit so   what you suggest like which two will take priority   um which two we are considering  in further for this one so we have pulled all the four these four user  stories right for this sprint uh burst but with   the available capacity and based on our past uh  velocity which is 21 i don't think uh team will   be able to uh commit and complete all the  four so you can help us in prioritizing and   um sorry i think these are the tasks  actually not just is it how come i went   okay let me go back i think you can  scroll down the user stories will be down   yeah stoke is three okay so we just have  picked two right okay then i think we are   good sorry sorry about the confusion guys  so eight and 13 so we have 13 story points   picked up so i think we so uh with full capacity  the team has delivered around 21 but this print uh   we have a lesser capacity so i think 12 is not too  well we do have almost 12 12 13 is fine but what   do you guys think shall we take any more is the  story one small story or we just keep it as this i think we can have start off with this show  week and then maybe you know in the second   week of sprint maybe we can revisit a backlog  to pull something new okay fair enough okay so   uh i think we are good with these two then and uh   so 13 story points that's what we are going  to commit so i will communicate again the same   along with the spring goal to all the stakeholders  and the business sponsors and a couple of points   that you guys will add in the task break  break the stories into task and add in us   and yeah i think we all are good then any  closing comments or questions from anyone i would say happiest printing yeah great  okay if nothing else then uh thank you guys   for your time and your contribution  uh let's uh make this print success   thanks thank you shaving thank you all thank  you all bye thank you all the best thank you hey scrummies welcome to this sprint review  live demo session friends there are tons of   articles youtube videos on sprint review but  no one shows us how it actually looks like   now this session is our small attempt to show  how in real life sprint review looks like so if   you are new scrum master who just joined your  first organization or aspiring scrum master   who want to know how sprint review looks like then  i assured you after watching this complete session   you will be more confident on your job friends all  our team member in this session are scrum masters   and spend lot of their personal  time to make this session successful   so please please appreciate their efforts in  the form of big like and the last if you're a   scrum master and new to our channel careers talk  then please do subscribe you will find tons of   valuable content for scrum master on our channel  so let's begin this session over to you shashank welcome all my name is shetland pachanovi  i'm a scrum master in india with 10 years   of id experience i'm an agile enthusiast helping  organizations and teams on their journey towards   agile transformation with an agile mindset using  various frameworks tools and techniques in today's   topic we will be discussing about sprint review  its purpose who all are the participants duration   and more please stay tuned till the end where  we demonstrate a real time sprint review meter so to begin with what is the purpose of sprint  review the main purpose of the sprint review   is to inspect and adapt what is being delivered  at the end of the sprint the whole team gathers   and review what is being done this event  is to evaluate the outcome of the sprint   the product is being inspected whether  it makes the definition of done or not   the definition of done is generally decided in the  beginning of the sprint a potentially shippable   product increment is reviewed inspected  and then adapted based on the feedback   collaboration between the scrum team and  stakeholders is the key during the sprint review   the sprint review aims to get feedback from the  stakeholders on the user stories done during the   sprint the definition of user stories include  deployment to production acceptance testing   and anything else needed to release the user  study to the final user with the potential   this is the deliverable and the end goal of sprint  the whole meeting should be focused on reviewing   the shippable product agreement another purpose  of sprint review is to review what is being done   and make changes to the product backlog  to optimize the value it is important   to note that the sprint review is not a demo  while the team showcases what they have done   the purpose is to collaborate as a group take  feedback and decide on how to move forward who all are the participants in sprint review  so the whole scrum team gathers to review what   is being built during this event the scrum team  product owner and the stakeholders collaborate   and review together on what is being  done during the end of the sprint   as the purpose of this print review is  to take feedback from the stakeholders   all the people who have a stake in the  sprint deliverable must attend the technology   so it comprises of the scrum team that is the  scrum master the scrum team the product owner and   must attend the spring review they collectively  need to collaborate with all the stakeholders   and answer any questions and take feedback on the  next steps and the stakeholders are people within   the organization that have a stake in sprint  deliverables these could be program managers   other scrum masters marketing sales id support  business development teams and we sometimes you   can also invite customers and also the end users  which is optional and it varies from time to time and how long what is the duration of a sprint  that we make the duration of a sprint review   meeting totally depends on the length of the  sprint as the length of the sprint is time boxed   so is the length of the sprint review meeting  yes time works if the sprint length is one week   this meeting should not be more than one hour  for two weeks this meeting should not be more   than two hours for three weeks of sprint this  meeting should not exceed more than three hours   likewise for four weeks this meeting  should not be more than four hours and how often does this sprint review  meeting happens sprint review is one of   the most important scrum event and the sprint  review is the second last event on the sprint   followed by the sprint retrospective which  usually happens on the last day of the sprint so what is the agenda of this  print review so basically the   term market needs to ensure that the prior  invitations are sent to all the attendees   it is the responsibility of scrum master  to make sure that the event takes place   everyone gathers to attend the meeting and the  scrum master facilitates the meeting through   by following the agenda given right so the agenda  is nothing but to introduce if it's a new team   that are formed recently uh which they are  just keeping off their agile transformation   in their projects so the scrum master introduces  the new team uh and set expectations and they well and he also introduces the po and his scrum  master together introduce the stakeholders to the   team so this is also to set the expectations  of why why are we actually uh having this   important event what is the importance of this so  for the po for the first time he collab it it used   to set expectations to collaborate a working  system to have a collaborative working session   and this is also to ensure the business  value is delivered the review working   so then this here we need to definitely review  the working software produced during this print   share spread so the po has to share the sprint  and the product incremental goals connect it to   the review road map and or the release plan set  context on where the sprint is in overall efforts   release or increment focus less on individual  user stories and more on the value created   and we need to answer the question how does  this print add value to overall product   iteration so the it is the responsibility  of product owner to showcase stakeholders   that what is the value that is being delivered  out of the sprint and how are we uh how are we   creating it with the roadmap that is already set  for the product vision to achieve the product   we need to review the value delivered by the team  so the scrum team starts there starts showing the   value that the team has achieved and it's uh  once they have uh presented the uh reviewed   the working software with the stakeholders we  will be receiving some feedback we need to note   down the feedback from the stakeholders  uh on on the value delivered so once that   feedback is noted down so that they can refine  the product backlog items uh which the po and   these company together collaborate and they can  make changes to the existing product background and then it is time for also the scrum team  to share their uh challenges and the risks   that put but that might be involved during the  sprint that they have faced during the sprint   and some challenges that they can resolve with  this only with the stakeholders they can put   forward those questions to them and they can ask  the questions directly to the stakeholders which   uh which will get addressed within the within  the call or maybe after the call if there is some   dependence right so once we know down and they get  the help required help from the stakeholders then   the product owner uh if the product owner can  show what is the plan for the next sprint if it   is already there right so and towards the end it  is the time where we celebrate and have some fun   so it's time to celebrate all together the hard  work of the scrum team that has accomplished   before they plunge into the next build so the  key takeaway is to ensure that the trend review   is recognized as an event to make critical  business decisions about product development how do we provide inputs during sprint review   as the time is very short and while providing  the feedback discussions can go on for a long   time we can use post-its or sticky on the mural or  myro whatever whiteboard tools that you're using   to write input or use a simple document to  track feedback if you are on one or in the same   same meeting room if the users are  familiar with your project management tool   uh they can add their product feedback directly to  the product backlog or if they're using a document   online like day first weekly or confluence you can  add a page with the feedback of each print review   or you can create a page in one note  dedicated to the sprint reduce feedback   so these are different ways where you can input  the feedback or the gathered observations uh that   we can make note of during the sprint review  who leads this printed sprint review so as you   can see uh the host where the scrum team presents  the results of their work to key stakeholders and   progress towards this product rule is discussed  here so here the facilitator is the scrum master   wherein the po or the scrum team can take a lead  where they can host the session where they will be   projecting what they have what value they  have delivered for this part of the sprint the next print uh the next uh slide talks about  what should we prepare for this printed how do we   prepare so this this event is a very important  event uh meeting wherein we there's a lot of   preparation have to take space in the background  so these these are the activities that they   usually the product don't identify stakeholders  for the review and uh the invitations are sent   and everybody's invited so we just ensure that  everybody is there and we need to ensure that the   scrum master's responsibility is that to ensure  that all the user stories have met the definition   of done he needs to get the acknowledgement and  the agreement or the commitment that we have done   towards the beginning of this print with the  scrum team and the view right so there should   be an internal review within the team with the po  so that it's all set ready for the sprint review   before we display uh display the or share the  value that we have delivered as part of this print   right and also uh we we need to sort out things  suppose we have uh select we have selected suppose   uh we have shortlisted for this particular  sprint goal we have listed 10 user stories   and we are able to complete only six due to some  dependencies or some challenges that we have   so we need to ensure that what is already done  and what is not done and that needs to get updated   into the jira or any project management tool  right so yeah like i said we need to identify   and uh the user story should meet the  definition of them that is nothing but   the commitment that we have done prior and it  is very essential to present the sprint review   as one team what this means is a clear plan and  order in which the team will present usually the   product owner starts by talking about the goals  of the sprint and what functionality is delivered   the scrum master can show the burn down  charge and the velocity of the team   afterwards this ground team will showcase  their work this it's always good to decide   beforehand the order in which the presentation  will happen and if you need to prepare anything   example any setup or any specific data  test data anything that you want to do   you can you want to display it's also encouraged  that most if not all the team members to present   what they have achieved during the sprint it's  not a good practice that the same one or two   team members present the entire team sport so it  is always good to motivate or encourage that all   of the team members to come and speak uh in  the sprint review meeting and showcase their   work that they have produced or done or  delivered as part of that particular sprint so what actually happens in sprint  review execution of the sprint review now   uh we are done with all the preparation activities  it's time to execute this print review meeting   then these are these there are some best practices  that we need to follow to conduct these print   review meetings effectively first of all we  need to summarize the work done in the sprint   the sprint review starts with the product  or representing the sprint goal set for   this print po also presents the backlog  items that associate with the sprint code   the product owner explains with product that what  product backlog items have their status as done   and not done so this information gives a good  view to stakeholders of the achievement of the   sprint against the goals defined inspect product  increment the scrum team inspects the product   increment with the stakeholders by discussing the  approach to achieve the spring code they also talk   about the challenges they faced and how they  resolve them the scrum team will answer or any   questions that the stakeholders may have on any  of these quote items at this point it's essential   that the discussion remains focused on the work  at hand and not deviate from it from anything   regardless scrum masters needs to pitch in to park  any such discussions and remind the team that it   is a time box meeting and the demonstration  of all the work that needs to be completed   discussed under that so the sprint review is an  opportunity for shared understanding between all   the stakeholders the people who create it that  is nothing but the scrum team and the people   who benefit from it the end users the customers  and stakeholders the product owner discusses the   product backlog as per its current status the  product owner also presents the target dates   rough milestones on what will come up in the  subsequent steps the entire group deliberates   on what to do next the basis of this discussion is  what work needs to finish including any spillovers   from the current sprint as a group the team  discusses the priority items that we should   take in the next print the stakeholders like the  marketing team could provide valuable insights   to how the potential use of the product might  have changed based on the marketing conditions   and in that context what makes  the most sense to pick up next   so what is the output of this print  review once the sprint review is done   what is actually what do we get out of it so the  product owner will take the feedback and adapt the   product backlog and prioritize accordingly so they  can be some changes made based on the feedback   that we have and we can make change to the product  backlog items that we have and in the background   the scrum master can also talk about the team  this velocity and how the team is improving   every sprint which also feeds to how much  work we can finish in the subsequent springs   the sprint review meeting uh ends with a shared  understanding between the stakeholders about the   accomplishments of the work so far how much work  is spending and how much privatization of work   happens for upcoming spending so this helps us to  reprioritize the product backlog add new items to   the product backlog and it also helps us to do  a better planning for the next step so these are   the benefits of having a sprint review so now let  us discuss about what is not a sprint review so   these are some of the myths that uh we really  need to take a clean look about as to what   is not dispensable right so the sprint review is  called a demo by the scrum team and stakeholders   so usually we i've seen we have seen we have come  across many things where this they think that   it's only a demo uh and not nothing else apart  from demo right so by treating the sprint review   primarily as a demo the purpose of this crucial  opportunity for inspection and adaptation is lost   too many scrum teams approach the sprint  review as their moment to show progress   to give a product update to sell what is built  to stakeholders or to talk about what they do the next method is like uh the sprint review  is a powerpoint presentation with screenshots   of supposedly working software so ideally   the working software should have should be  a live working uh shippable product that   where the stakeholders or the uh scrum team  just showing the product with this company to the stakeholders should show the live working  model not the screenshots or any presentation   using a powerpoint it should be a working module  so none of the stakeholders present are using   or going to use the product so we need to ensure  that the product the stakeholders who are present   in the meeting are the ones who are going  to ultimately use for the rather than the   end users who are going to use the product  instead of just having some random participants   who do not provide any feedback right and  do not add any value to that meeting so   we just need to ensure that we invite the  right people so that we get the right um   feedback on the product that we are showing during  the sprint review and there are it also helps us   to avoid there's another myth that this is that we  sometimes uh there are hardly any inputs from the   stakeholders right or they're not invited to so  sometimes we just like i mentioned in the previous   that we need to ensure that the right stakeholders  are invited and we need to ensure that we are   getting some feedback from the stakeholders right  and if they are not sharing any feedback either   they are not understanding it or we are not able  to reach to what we have actually planned or we   are not able to uh meet their expectations  so we need to clear those uh ambiguities   or those disturbances in order to ensure that  we get some input from the stakeholders every   which will help us to prioritize re-prioritize  add more to the product backlog and keep on   enhancing the product as we go forward and  usually uh the keyboard and mouse used to   click through the product never actually  reaches the hands of stakeholders uses users   during the sprinting but remains soundly with this  company so the product or the mvp or any any dem   any software that we are sharing or that we are  displaying during sprint review should always be   handy to the stakeholders or the end users so that  they can actually use that by on their machines   so they can look for any feedback or any fallbacks  or any issues or bugs that they can identify   without which we cannot get the live uh live  feed as to how the live feeling of how by   using that particular product right so we need  to ensure that we are giving a working software   to the stakeholders and the end users so they  can use them and give us the proper feedback   there's an applause after every display  of working software completes or worse the   scrum team is moved out of the room right so it  should not be either just like right after the   sprint review oh that's an amazing job we just  clap and we just dispersed so that's not what   it should actually happen right or rather if they  didn't meet with their expectation and they just   simply go and they just leave the meeting right  so this is not how it works so ideally we should   get a proper feedback as to even though there are  there's a lot of things that the team is already   provided there is always room for improvement  right so there could be it could be very minor   but it could also have a huge impact right so  any minor feedback is very much important or   needed in order to get a better  product out of each uh sprint   and usually there is a general area of nervousness  in this country right if the scrum team are quite   new that is quite understandable really just  completely motivate them as a scrum master and the   just keep motivating them but even after a  couple of sprints they are still nervous and   they are quite uh not so open to share with the  stakeholders and openly speak to them so there is   something uh wrong so we need to really work  out on that with the team and make that make   them keep them uh motivate them and encourage  them to open up and be transparent as to what   their challenge is right so we need to figure out  that we need to fill out those air bubbles and   stakeholders are easily distinguishable from this  company both occupying their own side of the room   right in if at all we are at offices they all  sit in different corners of the room what does   this just separate far away sits far away from  this complement so ideally it should be like all   of them together as a dvd to just collaborate  and sit together on the same table and discuss   as all of this is our product and this is our uh  end goal to achieve uh the product code for after   if after every sprint goes like that right  so these are nothing but few minutes that uh   we got to bring up to you to all of you so that  we know as to what is not a sprint review right   and with that uh thank you so much for being so  patient but definitely please hold on right now   right after this slide we are going to begin our  uh working or live real time sprint review meeting   and please do support our channel like comment  and subscribe and i hope the team is all ready   i'll just quickly check and we'll get  back to you shortly thank you so much okay thanks sashank for this wonderful  presentation i hope you guys have loved   this presentation and so we have covered the  theoretical part with the help of shashank   and let's now move on to the actual demo  session so over to you shashank and sindhu uh   why don't you tell us about your team and  everything and uh introduce us yeah guys   yeah thanks thanks for that uh  so so this is the live demo of   the sprint review so i am the scrum master  and sindhu is the bo product owner and uh   amit neha shankari and meghata are part of scrum  team and manoj aron and ramya are part of the   stakeholders so today we'll be going  through sprint one uh where we'll be so today we'll be going through sprint one  where we are going we are going to show   what we have delivered as part of the sprint  based on the requirements that we have received   from our stakeholders so i'll hand over the mic  to sindhu so that we can go over the sprint rule   and go to your single thank you so much sashank  hi all so uh we have done a great job in this   sprint and as chashang already said ahmed neha  and shankari and vengara are the scrum team   members they did an amazing job i could  say appreciate the team for your work so team what we have achieved so far is great  and i would like to provide some overview   of this project and uh um again saying the same  thing why because some couple of team members   we have added newly um in the sprint so what  is the purpose of this and what is the vision   we as a team going to have okay so stock shopify  is a project and uh our parent organization is   shopify we are as a child we have created this one  going forward slowly the data has been transferred   to our end and it will be a massive application  it's not only a web application you're about to   create a mobile application as well which would be  a very user friendly one to all and the interface   the interface with the users is going to be an  amazing experience for the user so these are   all the core areas we are about to concentrate  what is the purpose of this thing is that um   since the name itself replicate the stock  stocky shopify we are about to maintain the   stock details and via this mobile application  we will be having a shopping the stocks over our   application so we are like a third party thing  and uh slowly going forward uh the our parent   organization all the data will be translated to  us at that point we may expect some huge data   will be transferred into uh our project so that  time we will be have ready to handle those data   and as well um our main vision on this is that  not only having the text message or something else   some kind of pictorial representation which  really attracts young people so that thing if   you're about to concentrate more even though some  people might not think that they're not good at   reading english or some languages so for them to  make clearly understand on our vision and to make   this application very friendly to them pictures  as well is going to take part more on this so that   kind of pictures will definitely impress the youth  as well as old so those things are the main area   and maintaining the stocks with performance good  performance and reliability and security is the   key for this one so this is this is our vision  and uh we are about to progress on this vision   so we have 10 we have just started our sprint so  since our sprint won we had just had this as a   very chill period we had some little items only  so going forward we will be expecting some more   user stories to be added of course it would be a  definitely a sustainable increment only so this   is our vision any any doubts any questions from  your end team but can you please share your screen yeah thank you so much so for our project stock  stock shopify we have picked up three user stores   for the spring and our spring goal is that to  enable all our users to provide some login access   for our website stop shopify application so this  is mainly our spring goal of course when we are   progressing we have faced some bugs and issues  irrespective of all odds team has perfectly   finished all those items uh kudos to the team once  again and i'm very happy uh that we have finished   this item for this sprint now amit and teams our  scrum team members will represent uh will provide   the product increment to you over to amit can  you please take up can you please provide us yeah   thank you amit i'm ordering yes okay uh so yeah  uh thank you cindy for that uh intro so uh let's   uh quickly go over to the increment first  and then maybe we'll come back to this i just need to stop share and  reshare just a second sure okay uh you're able to see the web portal right  yes okay so this is the poll that the team have   started working on and uh like sindhu already  explained we have given the login access and   the signup access so that we are able to enable  any new uh user to sign up and any existing user   to log in into the application so going back to  the jira board and we'll go through each of the   users slowly so first one is as a registered user  the world should be able to authenticate using my   credentials which is an existing user uh in this  along with me uh and uh shangri we were able   to incorporate and update yeah so uh username uh  it's it's an um alphabets eight characters so i'll   quickly write my username for password for now we  have created a static password which is here so   when i click on login you're able to see my  screen on the mess a message on the scene   yeah we can able to see your screen i  think you need to share your full screen i'll share my completes right away you're able to see now yes yes we could  okay so this message is a prompt that   comes on the top i'll quickly show you  again because of that screen sharing okay so when i click on login  uh so this message comes up   uh this after this the intention is the page would  then go back to the next page which is our home   page and uh with this we are successfully  authenticated uh going back to our second user   story so this is our first user story uh and that  was our acceptance criteria any questions anyone before i go to the next video it's  really fantastic the way what we are   expecting it's very nice can you  go back to the screen please okay yeah i would like to have like the  username whatever you are adding here right   can be keep like email address along  with the username is it possible   so that will look far better right more better yes  yes that is doable so uh i would request sindhu   uh sindhu you would be able to take that note oh  yeah i have i have thank you i've already taken it   thanks manoj thank you very much for  that yes any more questions on login user okay so next one was worked up by venkat  uh i'll quickly go through the user story   first uh as a user the login page should give  me the capability to see the masked password   i will yeah so i'll again give the credentials so  um giving a summary of this user story it's like   this is right now hidden so the capability  is with this i button i should be able to   see what password i was entering so it's  a toggle button that we have incorporated   to see and not see basically mask and then mask  the password so yeah that fulfills the user story   i'll quickly go back to the jira  to show you the acceptance criteria so it was default by default it was masked  and we have also provided a button to   mask and unmask the hidden  characters any thoughts on this one um you're good emma please proceed  to the next year's yesterday   great uh next one as well was worked up by venkat  uh this one was for the sign up so as a new user   provide the capability to input my details as  a new user so that a user can be registered it   had a similar acceptance criteria like uh the full  name field should be there email address should be   accepted so the feedback that manoj said it can  easily be incorporated because anyway we have   email address in our database uh username it's  already we are accepting as uh alpha numeric and   uh password we have as uh uh eight uh character  we cancelled it yeah password we are having and   then a click click cable button which is sign  up so let me quickly go to this page so yeah   when we click on this button sign up a new page  should open up which is this very similar to   login just to have the continuity in both the  pages like i explained all the fields full name   email address a username uh and setup password  we've also added the capability like a placeholder   is given so whenever we start writing the behind  placeholder goes away which is which was full name   in this case so that helps user to understand  where uh value which which value goes in which   field and yeah so this is our good old signup  page any feedback any thoughts very nice amit   and team i really appreciate for the work you  guys did uh just a small correction i need here   in this screen i could see like a  full name right all are small letter   can you just make a like generic the first letter  will be capital something like that yeah yeah   you think that would be nice that can be done yes  yes i agree on your point if you're having in that   case it will be more the visibility is more good  i think all right thank you thank you very much   yeah so one more thing is in both login page  and sign up page it would be nice if you can   have this no company's logo name is really  very important and you know the brand should   be maintenance if that can be added into the  pages it will be great we can do that yes   thank you yep um here um this is really good uh  this is k mode as expected like what we wanted   uh the one thing i want to suggest here is  uh whenever we want to sign up we want the   email to be verified so if if we can you know  add this feature um in the future right now   uh whenever the email id is entered and signed up  we want the email ready to be verified through the   you know from the mailbox so that would be  uh really good okay i believe that one would   require some discussion uh like what kind of uh  verification validations we want to add but yeah   we can take it up in a separate dedicated session  with uh sindhu uh as theo and uh you are thank you uh cindy one quick note on the uh  ramya's comment uh the company's   logo we would need that uh prior to  starting our next sprint so that we can   uh prioritize and add it yeah  sure we will discuss and uh   we will prioritize based on it i will discuss  with the stakeholders as well thank you yeah any more thoughts anyone so manoj and uh know anything else thanks from here you like to add any anything  else oh really i'm happy with the progress of   what the team is doing here right i just wanted  to know like for the security reason how you are   maintaining the password here how  you have implemented those things okay sorry someone was speaking no  i was about to call you yeah okay   so uh for password for now because this is the uh  first print and we were trying to incorporate that   login functionality what we have done is  and i would go back to our jira for that   we also faced a bug during our development  and neha was the one who resolved it   so we received a login api from the integration  team and we are not the ones who are uh   checking the authentication or authorization  so we are just passing on the credentials   that we receive from the portal from the  user and then we share that to a login api   and then we wait uh for 300 milliseconds to to see  a response so they are the ones who are actually   authenticating and authorizing if the user  is good or not and being the based on the   error codes or success codes we're just  uh moving ahead so yeah that's good   okay thank you so much actually i was just  trying to understand curious to knowledge   how you and things are taken care from your  ends yeah i'm so happy now great welcome   thanks manoj thank you very much thank you  team as well so so stakeholders have provided   some feedback for us to know so manoj has provided  he has requested us to have some email address   when we are logging into the page in addition  to the username and password apart from this   um ramya has proposed uh everything we can have in  capital letter instead of small everything is like   seems to be very small in small letters and then  company logo and random yeah i do feel like to   agree with this point uh since we are having some  stock things we are handling on those stuff some   having our company logo is a priority i  believe however we will discuss on this   and then apart from this um email id verification  yeah there is a valid point from a stakeholder a   room this also needs to be considered as a  priority i think and then security reason   which was covered the manual already we have  uh ensuring those security as a part of this   three user stories so thank you team these are  all the items we have covered and again once   again uh great job team irrespective of all odds  you made this uh thank you so over to shashank   yeah that was a wonderful uh sprint review and uh  thanks for the amazing feedback i don't remember   so while we were discussing uh i was  also parallely uh making notes so that   we can have it uh discussed also we can add  those items to our product backlog and yeah so   i hope you are able to see my screen  the feedback right yes yes we could see   all right so yeah that is uh for this  print and anything else before we wrap um for this print uh i think uh we  have done it's everything is perfect   yeah just one last question had cinder shank  like are we making even user names as unique or   is it okay to have duplicate user names if we are  allowing only user names of course email id will   be unique i understand yes do you remember once we  have discussed uh we we were agreed that we will   be having our user id as unique not to have any  duplicates or anything like that right uh some to   three weeks back we had this discussion the same  question arise so that point we agreed this way uh   so i have proposed the same to the team as well  in future sprints we will ensure those validations   and all from you great thank you thanks ramya  thanks for your input and thank you so much for mvp that we started off with the project right so  and you all did a wonderful job but i know because   after hearing or listening again uh because  neha and shankar are new to the team so uh after   listening to this sprint question and strength  the product question that we have ultimately so uh   at where we are the status quo that we are and  where we want to be down the line after three   months so do you have any questions from your  end guys so let's go one after the other who   would like to go first yeah hey so i haven't  questioned basically for the stakeholders we   uh the production server is not available with  us so by when we can expect it to be available why um server is required uh yeah sure so  basically if the production uh server is   available with us so we can uh basically do  the thorough testing with production data   so it is needed for thorough testing okay  i understand so i'll check on the details   and i'll make sure the production server access  will be provided as soon as possible for testing good a good question neha but ramya however since  it is a production server uh we we may not provide   access for all the team members right some kind  of uh security and sensitives are live um so at   that point uh we have to be little astringent at  initial stage on this access area i believe from   here yes so we can discuss it on offline and we  will have some agreement how we can provide access   to the team who are all can get the access those  things we can discuss i think something like that   i agree on that because security aspect is really  very crucial yes yes it might be on live uh if   supposed team members have updated something  then it will affect our life and since it we are   maintaining stock that may be the team yeah yeah  thank you thanks for bringing that okay thank you next hi this is venkat so i have a  small request uh when we were testing   we found a pdf server down and  then we started debugging it   and after one hour we came to know  that there was a scheduled maintenance   so like we request uh can anyone help us uh  informed about the scheduled maintenance tasks yeah i guess there is a email alert which might  have generated but i am surprised like how it   is not reached to you okay uh sindhu could you  please help me on this uh just include my notes   just include that list right yeah yeah sure one i  will ensure to include all the team members on and   i heard from uh jon stating that we have changed  the vendor on this and also this maintenance are   happening uh at the end of friday but uh as per  team concerns uh if you're having this maintenance   activity on the weekends then it would be very  great uh as per team so they have rise at this   concern with the when the sprint is in progress so  we have to work on this i think manoj so we have   to align with the new vendors uh to ensure that  either can we have this during the weekends to not   to affect our work or progress so we we have to  discuss on this and yeah i will note it down and   i will ensure all the team members are included  uh since venkat has joined recently we have we   might have missed his name i think so thanks  even thanks for bringing my movies yeah i'll   take care for the new vendors yeah thanks thanks  manage thanks hindu okay and yeah who's next so hi uh hi all uh just i came up with uh one  doubt like uh for now i could see there are uh   uh one billion downloads uh of this app so  uh uh by looking at the statistics we could   expect uh about 10 it could reach to 10 million  and now it may be in the next couple of months   so uh i believe our server will not have that  capability to hold those a huge data increase   in data is there any idea that uh do you have i  have any idea on how we are going to manage this um here uh thanks for bringing this up you know uh  we really thought that this would happen after six   months but uh we are at this number right now  so um i would talk to infrastructure director   once uh to see like what can be done  to uh leverage and get this expirator   and i will come back to you and use   um with an update on know how we can dislike based  on your expertise yeah sure thank you for watching all right thank you so much  guys thanks for bringing up   i would like to yeah yeah before uh closing  uh i would like to hear from the team um   are they facing any challenges serving their  sprinter's progress um of course this is spring   one uh we have picked some three to four  user stories only however uh any they are   already wenger has uh provided we haven't sent  out so the emails haven't he hasn't received   a time so apart from that any challenges  team did you face when you're progressing any specific challenges uh you have faced uh not  nothing different just the one that uh shankari   already explained the server that you're currently  using uh it would definitely have some scalability   issues so that's just the one that uh we wanted to  highlight nothing different from myself thank you   yeah yeah but we have to ensure the performance as  well when the data is getting increased so those   are all the key thing and the security that is  really important uh since we are maintaining with   the cash and stocks so those are the things  anything uh yes we have like i have already   covered that point because uh now we have done  testing through some random data as the production   data is not available with us so this was a  challenge that i have faced during the spring will it be helpful if i replicate the production  data to some test servers or some other servers so   can i mirror the data production data will it  be helpful for you neighbor uh do you think   some other yeah till the time we are getting  the server access it can be done that if you   will giving the mirror data of that production  data we can be it will be helpful for us yeah so   ramya what do you think on this point uh can we  mirror uh production data and we can uh provide   team to test right in that case um we don't  worry about uh security issues or something   else right yeah uh the networks what do you  think we can just get something uh so cynthia   i need some time on this to discuss with the  client because we're not sure whether we can   you know uh just give the production data  just like that because uh there are certain   issues security concerns and all those things  so i'll get back to you on this on discussion   right give me a couple of days i should be able  to you know provide a solution for this okay   okay i i have a few suggestions i'll uh share  it on the mail to use hindu and ruby you can   consider those as well tv links views something  like that that will be great thank you so i think   yeah uh so if do we have any other questions  for our stakeholders as we have them here   but anything apart from that i think  you can take it up in the retro so once up right after this  we'll have a reprocession so   maybe we can discuss more in detail over there yeah sounds good all right thank you  so much guys thank you so much for your   uh raising apologies like this and uh  stakeholders and being so supportive   thank you so much guys uh because we thought that  your support thoughts and support will not be able   to uh deliver such amazing products so thank  you so much for your support and thank you and on the first surface of the first print and i  really hope that we continue the same momentum   and speed and the delivery and the value that  we are providing to the stakeholders amazingly   thank you shashank for you as well  you're really motivating the team   and you're the key person pillar i could say  thank you so much sashank okay guys it's not   vulnerable without all your efforts thank you  guys thank you thank you guys thank you team   thank you all it's really a good job  thank you thank you very much nice job so team what we have achieved so far is great and  i would like to provide some overview okay hello   friends uh as you know retrospective is the most  important event for any scrum master uh we feel   like there are a lot of critical stuff present  on the internet on youtube videos but there is   a huge gap between the practical approach so  this session is going to show you how you can do   this easiest retrospective technique to start with  if you are new a scrum master and yeah friends   just go through this video it will definitely  going to help you and please appreciate our   efforts in the form of life and please provide  your comments and if you want to see other   retrospective techniques in the future please do  let us know in the comment section hey this is a   going to be a wonderful session we have distracted  with the name agile in the sea so uh adil captain either you're on mute thank you sunant and welcome everyone  on board the ship today so today as as   as sunan mentioned we are in the ajar in the sea  retrospective meeting we have a very tight agenda   today you know by the way with some really fun  interesting games so let me just quickly show you   what we have in the agenda so first we are going  to have a quick ice breaker followed by a little   about you know why retrospective meetings are sort  of important part of the agile ceremonies then   we will be today especially going to touch  upon the sailboat method of retrospection   it is a very interesting technique which you can  definitely use in your organization we have a very   interesting case study as well so that case study  will be a part will be played through a game today   and then towards the end generally i like to  finish my retrospectives with some you know   interesting polls so we'll have that towards  the end followed by i also wanted to share   some of other themes which we can use in during  our retrospective meetings with that said let's   jump into the most interesting thing of the day to  begin with the ice breaker so here we have an ice   breaker for you it's a simple thing two truths  and a lie how to play that so i would request   you all to please think of three statements about  yourself i'll give you 30 seconds you know out of   three two has to be true about you and one could  be a false statement okay so your time starts now   can you all just quickly think of three statements  about yourself i'll come back to you in 30 seconds all right i think uh by now you should have  your statements with you shall we start this   okay so let me call out swarna you want  to say three statements about yourself okay my three statements are i have visited seven  countries in my life that is the first state   my second con statement is i am  terrified of water okay swimming and   open bodies of water so this is  a good thing if that is the truth   and uh the third statement is i'm terrified of  heights okay so you have visited seven countries   you're terrified of heights and what's the third  one terrified of water okay all right so team   you wanted to do a quick guess what is false  out of this i believe the third one is a false okay all right swanna you want to  reveal what is the faults about you   yeah i'm terrified of water is the first  time i'm more watercolor okay okay all right   interesting okay so i would ask  shashank you want to sure yeah yeah so my three statements are like um i did scuba  diving and i collect coins and i'm a sports person   okay i think scuba diving uh something  uh is seems to be unreasonable for me   what about others i do think uh i think it's the coin collection okay okay  all right i go i go by the first one okay okay   what do you think yeah it is scuba  diving oh awesome okay yeah thank you   over to you nacho you want to see well yes um  the first is i like watching uh and next one   i eat only vegetarian foods okay and third is  i like melody songs you like melody songs okay   so one okay anybody wants to take a guess  here i think it's vegetarian food for me   yeah i think it's the vegetarian statement is i like watch action i don't like oh   okay okay all right interesting okay guru  you have your three statements about yourself   yes sir i love to watch serious movies the  other one is now to travel to unexplored   and haunted places okay the third  one is i'm a very religious person okay any guesses here and does anybody  knows guru the city haunted places   yeah i'll go with the same option  same with me as well i think so i know it is the it is the first one i am not  a person who watches serious movies i'm more into   jovial and more into fun okay okay all right so you  do visit haunted places guru yes very much wow i think  you're on the right ship then   yeah sounds interesting would like to go with  you someday guru to some haunted places you   know definitely desperately all right yeah  thanks everyone i hope uh you are now you   know sort of into a mode wherein we can do some  real brainstorming so with that moving forward   let's see why retrospective meetings are sort of  important okay so the very first thing is because   it provides us that ability you know to inspect  and on what went well what could be the things   you know which we can improvise upon uh you  know and what things are something uh some   sort of things which are you know sort of slowing  down our progress so overall uh if you look at   this crumb guide it actually you know talks more  about you know it is it is based on the concept   or the principle of inspect and adapt so that is  why uh scrum retrospectives are sort of a very   important aspect of our scrum ceremonies  okay now let's come to the most important   or interesting uh topic for the day which is  the how we can use or what is sailboat method   uh you know how we can utilize that to identify  what were the impediments or what were the great   things that team has done okay so it actually  talks about the way a team can define its vision   and from where it has to go i mean uh you know  so that is nothing but uh if you look at the   image here the island depicts the vision of the  product which the team is intending to achieve   okay uh the boat here is nothing but the scrum  scrum team which consists of the product owner   uh you know the scrum master and the dev team  as well and then you will see the two important   things that are happening here is the winds uh  uh you know which is actually helping the team or   the boat to sail towards this goal so there could  be an example you know so let's say for example   if i quote an example of creating a maybe an  e-commerce site you know wherein a product owner   has vision to you know build any e-commerce site  wherein stakeholders are very working you know   quite closely with the team so that is sort of  a wind which is you know propelling the team to   move towards the uh the goal of you know getting  the site ready for them however however during   this whole journey uh you know there are some  challenges with the team is uh sort of you know   anchored with like for example having too many  meetings that is definitely slowing down their   overall progress and they are not able to you know  meet or overcome the velocity they are intended   to do at the same time if you look at this image  how the way you know the ship can be uh hijacked   by a rock or an iceberg similarly when you think  of a risk or any blockers that may happen for an   e-commerce side could be the the major role which  the payment gateways play here so that's how if   you try to envision this image with the the goal  of getting an e-commerce site you will see that   you know the ship is actually surrounded by some  of the impediments and there are few positive   things as well in terms of the uh the wind the  way it is blowing so using the sailboat method the   team can definitely you know identifying the ways  how we can reduce the number of meetings and also   evaluate how we can stable our payment gateways  you know to overcome or achieve the goal of   getting a more stable e-commerce site so that  is you know that is in a nutshell a way of   implementing a sailboat method within the  retrospective ceremonies to identify our   impediments and also make sure our progress says  through you know towards our goal moving ahead   so the way it works is you first identify or you  know you set the context uh what we are looking to   achieve we do a little bit of a brainstorm around  that we gather the data uh you know which helps   identify what were the blockers etc and then once  we have after the brainstorming when we are ready   with our you know pointers we can find out a  potential solution to how we can achieve that   moving forward so today we have a very interesting  case study you know that is happening about   for one of the software deliveries in the industry  wherein the team is required to build up work on a   project which is to do with the improvement  of how we can improve a web application   okay so here the case study talks about how does  a team of nine pirates you know who have sailed   on a journey uh that definitely consists of  you know people from onshore and offshore   and they have embarked on this  journey to you know deliver the goal   which is about uh you know how you can improve  the web performance and at the same time within   the timelines so if you look at this case study  closely you will see that uh the team has already   been through you know 20 sprints so far during  this journey still the team is lagging behind   because they are still not able to deliver the  with the same velocity meanwhile there were some   incidences wherein you know people have left  the firm and new people have joined the company   and at the same time during all of this journey  still they are left with around at least 60   of the work which has to be done so therein close  i mean if you look closely there is a lot of risk   you know and some impediments which are there  blockers so let's use our retrospective boards   to analyze the situation and find a potential  solution for this okay now let me take you go   all to the retrospective board and  see how we can overcome this challenge so for today's session we are  going to use this particular board by the way can you all see my board yes sir okay all right yes okay fantastic so  uh here in this port i have already placed the   goal which the protocon are looking forward  to which is mainly talks about you know how   we can improve the web performance if you  look here and how we can achieve our sprint   in the by the end of the next month so these are  our goal okay and then the wind as i said we'll   talk more about what are the positive things  or positive outcomes from our last sprint   there could definitely be you know some uh aspects  which we wanted to carry forward to our upcoming   sprints however during the journey i mean as you  have seen there were few you know things that have   actually slowed down our process or progress so  you can mark them under the anchors section and   then let us identify what are the impediments  of the risk or the rocks you know which are   holding back us or which could be the potential  risk which we can anticipate in coming future   so with that can you all please come to the board  and you know uh let's start with the brainstorming   what i would like to do is so before that let me  just quickly give you a glass of you know this   particular tool how we can use the tool so you can  use the sticky notes to put forward your comments   like for example i've already put the sticky  around you know what is the team consists of   and what is our vision and so on okay once  we are done with that so let's first start   putting ourselves uh our pointers with regards  to what went well in the past sprint so may i   ask subarna to you know to start and putting  what you think went well in our last sprint by the way what i wanted to do is let's make  it you know more of a time box effort so that   we are not deviating from our time and still we  are able to you know find the potential solution are they liking uh whole team  can put it simultaneously and   if you make a little zoom yeah i think it's okay yeah so once you guys done  with the specific you can maybe   jump to the other one if you have  the understanding of the problem shashank can you see what pointers you have yes adil ah i'm  working on all right yeah let me check that   okay yeah he has to unhide  it he has to make it public okay and guru what about you do  you think anything went well   i'm just doing it okay sure i can see  some interesting facts coming up here okay so we have got good technical  expertise within the team   people are asking the right  questions to the stakeholders and there is a good understanding of the  business issues as well yeah good points group can would you like to check on your fonts can you share your sticky notes guru you will see an option for  making your sticky notes public i have put in the chat there is an option to make the sticky  notes public guru if you look at my screen you can hide and unhide these sticky notes   okay all right fantastic so i can  see some really good points coming up now let's move on and let's see  you know what were the things that   went that made our delivery a little bit slow   so i would request you all if you can you know  start putting the things that were holding us back okay changing priorities was a concern okay there were some members being pulled  out for the ad hoc work like interviews okay okay interesting some attritions as well yeah  definitely that contributes to a slowness yeah looking at the current situation  some unplanned leaves okay all right good points there should we identify  what were the risk that happened okay all right so i guess now we have got good  points in terms of the risk in terms of slowness   and also some good things coming up you know  like the team are getting a good understanding   so with this since we have got  more than one discussion points   would you guys wanted to have a quick poll  and see you know what points do you want   to prioritize in the upcoming sprints so  that we can find some solutions to them before going for the poll is it okay  to read out everything just so that   everyone's on the same page yeah  sure so swanna starting with you   you wanted to at least you know touch upon  like uh what do you think was holding us back can you start can you start with winds please   can you start with little positives  okay let's celebrate something which okay yep so i think the team  has very good domain knowledge   even though there are new people the guys  who joined recently have picked up quite   well and they are able to progress faster than  anticipated so that i think is a good thing okay does any everyone agrees or to this point  that we had a good understanding of the business yes adele yeah that really helped the team to  you know put yeah you know take into the new   functionalities as well and to understand  the business problems and the business   functionality that really helped to progress  up the you know take the new huge stories there   okay you also mentioned about  having technical expertise shashank   yes yeah so along with the business processes  right uh the technical expertise which to   develop the correct code in the you know in the  stipulated time so that technical expertise which   we our team members are having uh that really  helped us you know to save a lot of time there   so i think that's a plus point to us which is  actually adding wind to our boat to reach the goal   nice nice nice okay all right nacho you  wanted to highlight your context here   yeah uh like the keep is uh hopefully like they  are very much able to ask the right questions   to the stakeholders which helped us uh to  come out with what they actually required   the requirement was very clear by putting the  right questions only we'll be getting their   acceleration in the right answers so we were able  to ask and the stakeholders they're also openly   uh they actually cooperated and they were  collaboratively all probably working together okay good to see that collaboration happening  with the stakeholders thank you guru you wanted   to touch upon working as one team uh yeah  that was one of the final points and good uh   work from the team and in two or three uh  instances when the team were stuck up it was   some of the members who were experts in their own  rights they were able to pitch in and giving in   suggestions so that they were able to come out and  complete that particular activity within dimension   time so that way they were able to complete their  activities as part of their previous students and   i hope that same kind of uh collaboration and  oneness of the team will help in completing the   rest of the activities in the uh mention  spreads absolutely yeah thanks guru it she   definitely seems you know the team  has progressed well in this area   let us now move too slowly to you know the item  the action items that were sort of holding us back   little from our progress  coming back to you swarner yeah so as i said i think the new members of the  team are picking up uh of course but uh obviously   uh onboarding new members it does take some time  and well because there are so many additions and   experienced guys who have uh you know  work done worked in this area and they   have already have the domain knowledge can  work much faster so due to this i think   uh we are slowing down probably they  it's not like they are not doing well but   uh end of the day the output will be different  of a new member versus an experienced member   yes yes absolutely understandable thank you  shashank you mentioned about priorities yeah   they'll uh so as you know that there's a scope  grip which happened in the middle of the sprint   which actually changed the priorities right so  that is actually adding the anchor to the team uh   which is actually holding us down from progressing  on the planned activities so due to the switch of   priorities uh i think that is actually  holding us down okay okay all right yeah sure   nacho you mentioned about uh i think some of  the members from the team going for an ad doc   interview task yeah yeah they're like during our  sprint like there are mostly uh there is no plan   for the interview so we are getting our requests  and nada basis and we are not able to plan okay yeah uh guru coming back to you i think you  have a bit of a concern regarding our capacity yeah that's right with the recent spurt in the  covet cases there have been fewer instances where   the team members have taken unplanned leave either  to look after them or their family members which   has affected our overall uh uh sprint goals and  also the deliveries that we had as per what we   had committed to uh other stakeholders so that way  i'm a bit concerned and this is slowing down our   overall progress uh that is where  we are in this current situation   so i would like to have of course a plan for  this in our uh in our uh planning sessions   so that instead of uh having uh say uh we  have planned in around say ten percent for   leaves we can have this twenty percent as part  of our until the covet situation that gets uh   completely out of our site so that we can  again bring a bring back to the original level   until that time we had additional buffer for our  needs that way i think we'll be able to plan our   activities much better yeah yeah let's come to  that solution uh later part uh guru but thanks   for highlighting this concern and i think you  know uh in few minutes let's come back and see   okay now moving to the most important  concerns uh you know with regards to the risk   you people are forcing in the team so uh nacha  you had some issues with regards to validation   or getting the right tools yeah currently like we  are doing our testing performance manually i think   this is taking much of our time because each and  every time we need to do the same testing again   and again if you have some right tools then  it will help us uh actually in even raising   we can be on track okay okay all  right yeah i think let's figure out   that uh you know but before that let's see what  others have so swanna uh i think you are touching   upon a very critical aspect you wanted to  talk about it yes so again circling back   to uh you know new members of the team it's a  very huge application and it requires a lot of   domain knowledge so uh basically you to achieve  something one modifying one piece of code has a   lot of impact in other areas and unless you're  very familiar with it you might not be able to   assess the impact so because there are new members  adding to the code and you know uh not able to uh   get the impact the other code quality is coming  down okay all right okay yeah thank you guru   you wanted to touch upon the documentation part  uh yes for any new new joining part of the team   or even for the experienced member having a  documentation has its own benefits because   looking at the document and also the code they  will be able to better understand the flow of the   uh functionalities and wherever required only they  can get in touch with the existing team members   for the clarification that we will be able to have  a much better clarity with respect to the overall   application functionality for the new members who  are part of that particular team are going to join   correct correct yeah yeah sure okay let's see  uh we'll we'll come back to that guru uh let me   just you know quickly see what shashank has from  the environment perspective yeah they'll uh so   we have been raised this uh issue right  so unstable test environment environments   which is like uncertain right unplanned so   so this is actually interrupting our plan the  testing cycle uh which we are doing and uh that   is actually kind of a road blocker which we are  facing and we need to just ensure that you need to   you will maybe probably will discuss on the  solution part but this is a problem right now the   unstable test environment yeah okay okay all right  sure so i think all you know the risk and the   uh the the slow things whatever you know  we are encountering sounds reasonable   and like we are now we can see we have got quite a  few here right so what we can do probably is let's   pick up you know few of them from this list uh  you know uh identify like what we can implement   on an immediate basis okay so let me quickly  open the poll can you guys do a quick polling and   let's see you know what the team agrees in  terms of the risk which we can prioritize okay is everyone done okay so from here what i'm seeing is you  know at the moment team is more interested   from the getting the right tools   and having a documentation around and the  code quality aspect as well so let us yeah   so how many uh votes is allowed per person are  they over here because we have a team of what   four or five yeah so uh ideally it's like one  person can vote for multiple things what they   think is you know of importance for them but at  the moment what i'm saying is you know people are   wanted to concentrate on three  things that is getting a proper   code quality in place having the documentation  considering that uh the team there is a lot   of attrition happening new members coming in  and you know so that is something and in fact   uh rightly mentioned uh you know since we are  working on a critical aspect of performance so   yeah i think we need to figure out some right  tools but yeah let's let's go to the solution   before that i also wanted to see what is your  reaction from the things which are holding us back okay so yeah the ad-hoc interviews  are definitely concerning is what   we can see here unplanned leaves yes  again contributing to our capacity okay attritions okay so let us pick up you  know the uh considering the uh the way the   team is inclined to so let us at the moment we can  focus on the ad doc interviews that is happening   and on the unplanned leaves okay so what  do you guys think of you know so now that   we have discussed uh the uh the anchors and  the risks or the impediments uh within the   team okay and we have also identified uh  what we wanted to you know take it forward   so i wanted to know what is your thoughts  on what kind of solutions we can have so can we start putting these solutions here do you have solution okay all right okay so i think we already have got some solutions  happening here i can see uh one solution about   the you know streamlining our interview rooster  so probably this is something i can definitely   pick it up you know and i can work with our  talent team and also at the same time create   a rooster for our team so if no i mean uh if  you guys think that's okay i mean i can take   it up otherwise if anybody's interested you  wanted to you know take this responsibility uh we think like otherwise there are a few more solutions coming up in terms  of you know how we can make the create documents   for the new hires and creating of team calendars i would like to take the responsibility  of creating the documents   for the new eyes and also for their members  who join the team so that it can help in   their uh overall speeding up of their  uh productivity and also improving their   uh knowledge on that particular aspect of  functionalities okay okay all right yeah thank you you wanted to yeah yeah yeah i'll take up the  automating artist coverage but i'll uh just uh   have some spike with exploring some tools in the  market which is available in the market and maybe   like which suits for our project i'll do a spike  and then i'll give a documentation for the entire take this up how we can proceed yeah i want to check if there are any  tools that decrease our manual effort   to test performance and that way our time  will also free up and our pace will improve   okay okay all right yeah sounds good so it seems  like you know we have some plan in place you know   and we have uh the people assigned at least  with one task you know and good that we came   we came up with some good uh pointers you know  which should definitely help us save through   this project of improving our web performances  and at the same time meeting our timelines so   let's connect and you know during  our next retrospective and see that   out of all the action items and the possible  solutions which we have derived let's find   out where we were able to you know achieve  and implement them okay yeah sure are there   all right yeah thanks everyone uh before that uh  before we end our retrospective i actually wanted   to you know do something uh quickly with you all  so generally i like to do a quick poll you know   just so that people can understand or you  know it helps us to identify that what was the   uh uh the best thing which we can do or you know  what was the team's pulse from the uh perspective   uh what they liked about the retrospective and you  know where we are so such posts definitely help us   uh to gather the data and you know understand  what what was the team's mood so for today's   activity i have actually created a poll uh i would  request you all can you please go to the polling   link and you know start putting your  own thoughts on from the credit session yeah please let me know once you have done your polling can you please ping that  link to me in the chat okay thank you interesting okay has everyone done your vote so it seems like the team is  definitely has got some good   insights from today's retrospective  and will continue to do this okay thanks everyone but before wrapping i  have a quick thing to share with you again   so uh you know generally as you have seen  in today's session uh we have used a method   of sailboat similarly there are a few other  uh themes which you think you can implement   maybe you know you can use any car brand  or maybe you can use a mat set and a glad   theme to identify if a team is sad or some  things or you know they are glad with some   certain achievements or if you think like  something has to be stopped or continued you can   use those themes so keep exploring you know and  uh yeah make your retrospectives more interesting   so thanks again thanks everyone  for joining this today's session   hope you had a good time thank you thank you very  much yeah thank you thank you thank you thank you okay hello everyone and welcome in one more  session so today we have rakshit with us and he is   going to take us uh through this retro session and  this session is going to be a continuation of the   previous session which adil has taken so couple  of action items from the previous session we   will see in this yeah so i'm sure this session is  also be going to be rocking like the previous one   so rakshit hi welcome you looking dashing and  you're new after so yeah rakshit over to you   hey thank you thank you so much for having me  today hey guys i'm kalool rakshit you can call   me cal or you can call me rakshit uh anything  is fine with me yeah uh so i did view the last   session from adil it was amazing so i thought it  would be an opportunity for me uh to bring in my   perspective and let's see how this one works out  for the team right sorry guys all ready yes yes awesome let's start i will start  with sharing the screen right now okay so it is in presentation mode let me  know if you have a very good visibility   yes that's it yes okay so let's begin with this  specific uh section right so we have been having   multiple retrospective sessions during our teams  and the projects that we might have been part of   um so i'd like to take an opportunity  right so here what i am planning to do   is spend some time with you guys and uh we just  like to do a self retrospection about ourselves so   we are quite adopting doing retrospection about  our team our job our challenges right our sprints   so let's take this opportunity and retrospect  ourselves um okay let's think in this way   for the past one and a half year it has been quite  a challenging period for everybody right because   of this pandemic that is happening in this world  uh so let's not go back to one and half here let's   look at the last 30 days or i would rather  say one month of our life and let's look at   three important aspects that might have happened  with you or something that you might have seen   happening right the first thing that i would like  to think about is a good thing that happened with   you or something that you might have seen second  would be the bad or a negative aspect of life that   you might have experienced or might have seen and  the third one would be any specific changes that   you'd like to bring about or any kind of self  target that you have that you promised yourself   that you're definitely going to accomplish that  um since we have been so busy with our day-to-day   activities we have been cribbing about the fact  that time management is a very tedious job so i   cannot have time for myself i am on back to back  meetings calls client negotiations retrospective   review so right now since everybody's on the call  right now and you have some time so i'm taking   15 to 20 minutes of your life to retrospect  and i'm going to give that time back to you   so could you please make a note of these three  pointers one good one bad and one change that   you'd like to bring about let's take some time to  introspect ourselves i'm sure it's going to be fun   are we all ready sure yes okay great let's do that looks like a lot have happened in  sasha's life you're thinking very deeply yeah it's difficult to figure out what happens   is ready ready my god you guys are fast okay  let's begin who wants to go first please thank you so the good thing that i've done in  the last one month is i've been able to read   consistently i've i wanted to i am a reader  but i'm not a consistent reader so i've been   able to make that part of my daily routine  as much as possible weekends don't count so other than that yeah i think that i have  improved but uh i'm able either able to take   out time for reading or for working out i'm not  able to do both every day so i think i need to   manage my schedule better uh changes again as  i said i need to manage my day better i think yeah thank you savannah for sharing that uh part  of your life yes yeah sure so for me i think the   good thing that happened really was you know one  of my childhood friends has recovered from a very   chronic disease and uh a couple of weeks back  so that was a great great news what i heard   in the recent time structure considering that  what we are you know experiencing in those   days uh the bad thing was  unfortunately i lost my granny   uh and the changes yes definitely uh  after joining this agile community   you know interacting with people around me a  lot of changes has happened internally for me   from a learning perspective so yeah i'm just you  know experiencing these changes at the moment right um well i'm happy to learn that your  friend have overcome a difficult situation   and i'm really sorry to hear about your granny  um thank you for sharing that aspect of your   life that is very dear to you who's gonna  go next yeah i would like to go next uh   yeah so the good thing is that i started with uh  thinking on you know that 21 days transformation   plan where i was about to transfer myself by doing  those walking things and i started let's say you   know maybe one or two days and then the bad thing  happened that the government announced lockdown   and then the case is increased so that is the bad  part i can say and yes the learning i can say that   maybe i could have done much better in time and  i'm not waiting for this uh 21 days and yes there   are other options like doing it online and getting  up early morning and doing all of these things   yeah yeah thank you so much uh one of  the difficult challenges that i faced is   getting up early in the morning so yes i would  agree with you on that um who's gonna go next   uh can i go next yeah sure please yeah so thanks  uh thanks richard and yeah so one good thing is   like i found a group of energized scrum masters  who are always you know continuous in a learning   mode uh who was very active and they're  like lost to my journey to being more agile   and uh towards this learning and transformation  and the bad thing is like covert has done some   major damage to many of our family and friends and  we lost most of the day once and um and we and now   we are learning to get equipped with it and trying  to face the challenges uh how to overcome the   disease so but and the changes and the target what  i i would say like i have planned to start reading   some books and uh to upskill my knowledge and  i've been motivated by many uh many readers and   the publishers to their work and uh really looking  forward to learn from their books and i also need   to plan on my work at a workout schedule  and uh that is what i'm looking forward to   good luck for you having six packs i think  you can connect with us one on because uh she   mentioned that she's an even reader yeah thank  you for sharing that okay all right so i think   we're waiting for some more things coming from  guru i have to go next i would like to show next   uh so the good thing is that after having joined  this community i've been able to increase my   understanding of argentina and how it  works and put that into practice so   that i have much better understanding with  respect to how agents converge and get good value out of this one on the bad thing is that  even though i have been able to understand and   appreciate and learn more i still believe some of  the concepts which requires more of understanding   i'm not able to do it due to which i am making uh  very silly mistakes which is a bad thing for me   from my perspective and on the changes part  i'm getting involved in two or three major   what we say initiatives that is being rolled out  in our current company that way i'm able to bring   some kind of a change in the way the development  team is working and hopefully i would like to see   that change going down to various other teams that  are in the process of conducting scrum for their   so that's a very good uh an interesting topic  to share guru thank you for bringing that out   bringing about change is something that  we as scrum masters always aspire for   and take it for granted that that is definitely  going to happen but it's not that easy it needs uh   time so perseverance so hopefully  you get to see the change that you   i would like to bring about and uh maybe about  the challenges that you face about not being   able to apply specific concepts we can discuss  as a team and kind of maybe help you out on that okay thank you for uh bringing  that out guru um who's next i think we're done okay yeah so uh good thing is uh yeah a lot of  learning with you guys so i'm in touch with lot of   people with the various regions of various country  and it's a amazing thing to talk to all these   people and learn from them and yeah bad thing is  yeah i mean i lost a couple of my team members   to whom i'm interacting and then suddenly you  came to know that they are no more so it's a   yeah i mean very different altogether different  experience suddenly if you lose someone   who is very near and dear to you and changes yeah  i'm getting a lot of fat so i have to reduce my   weight doctor told me and i mean i'm dealing  making a plan that okay i'm going to hit a gym   but somehow it's not materializing as of now so  yeah these are the things from my and uh rakshit   thank you thank you for  sharing that so looks like we   somehow have to have uh similarity  connect so we have shashank bonding with it seems to be a good sign now yeah pitfall  is the future world right the only thing is we   are just thinking about executing executing is a  difficult thing but i agree but since the pandemic   started uh i feel that i am married more to my  chair than my wife so that's a different story   but yes uh let me bring out some of the things  that i have encountered uh the last one month   so when i say about good things so what i see  is a lot of people are coming out in the open   and helping in terms of blood bank or money  donation or group funding putting to help   people who are hospitalized so there's a very  good thing that i'm saying happening all around   bad thing of course comes to the fact that we have  seen a lot of loss of lives and a very young age   which we thought they would be having more years  to survive but unfortunately if it had different   plans when i said learnings i think this group  the community that we have in which we are able   to bring about our difference of opinions and have  a constructive feedback which is uh kind of very   enhancing for me because whenever i think that i  understand this concept well and i'm being proven   wrong to meet it next day when i see those group  discussions so yes last one month if i can sum up   everybody's good and bad things and the changes  it is somehow related between your personal life   your professional life and the things that is  stopping you right from being positive in life   so yes uh cell retrospective is very very  important for us to look at the different   aspects and in the last 15 minutes i was able  to understand the different areas of the life   now so bottom line i would say that during these  difficult times please be empathetic towards your   team members towards each other because this is  the need of the hour i don't know what you are   facing i don't know what your parents are facing  right so you might have been going through a lot   of stuff and then you come back and do your job  without any kind of questions so i would like   to start off by giving a round of applause for  everything that you do in this difficult times   keeping aside all the challenges so can you  have 30 seconds of clapping for each other okay great uh so how was the retrospective  that you did about yourself it's about   asking some difficult questions about  yourself and then sharing with your team   how was that experience it was interesting rakshat  we get to know i mean we got to know a lot about   each other and uh the common the terms and  phases on which we are right now right so   what we've been through and what we're  planning to do so that really helps   yeah okay so i'm thinking that this is a very  good uh feedback and i'm going to continue that all right uh moving on to the case study so in  case if you do not remember the last session that   will quite magnificently handle about this pirates  right so what you can see on the screen is uh   quite a bit of shortened summary of the case study  right so would you like to go through that let me   read that out for you so we have a group of nine  pilots comprising of five from onshore and a four   from offshore so they're all selling in a journey  with the same learning uh leaving midway and   others replacing them on route is on a mission to  improve the performance of their website so that   it loads faster and provides an appealing ui so  it's all about a website enhancement right so what   we have done so far in the previous sprint is we  have let's say sailed 20 nautical miles or sprints   and we have a lot of work to catch up so we have  60 percent more of work to catch up which was in   the previous sprint so i'm hoping that we have  at least covered another 20 in the last sprint   for which we're gonna have a quick discussion  are we on the same page here yes okay perfect   so the last retrospective was about adjoining  the sea this time i thought how about having a   different way of handling it okay so before i get  to that there were some action items that we have   actually planned in the previous sprint right  uh let's go through that and i'd like to see if   there were any action items that is not yet  completed or if there is any dependency are   there any challenges let's talk about that so  we had a action item to create a team calendar   so that we can keep a track of the capacity of the  team uh so this is the reason shashank was working   on that and i see that shazam was able to create  the team calendar and update that so everything   good from you and sashan any challenges yes akshat  we are able to do it and i'm following up with   team on every sprint basis and we're updating in  confluence and keeping it updated perfect and from   nacha streamlining the addock interview work with  proper roasters so that is going good i haven't   heard any challenges from her so i think that's  going good from savannah automating test coverage   is being worked upon but with so many people  getting involved i understand that's a challenge   but would you like to bring out anything so now  do you need any help yeah for now we are good honestly speaking i didn't expect so much  participation and that's a good thing uh   but all of that what is coming out is  there's a lot of management over here our action items and we take accounting  the potential vendors which is going to   meet our expectations so this is going to  be long shot and uh i can help you with that   maybe you can set up some calls and see if you  can maybe streamline this process or making a   bit quicker but apart from coordination with  that team are you facing any other challenges   not as such rakshas because we  have identified few you know   potential tools so we just need to catch up  with them and see how we can take it ahead okay and i think i see that from your end guru  everything is going well on the interview part   documentation any challenges from your  end uh nothing at this point in time   and as we have a scheduled every week on fridays  we have a half an hour slot where we review the   progress being done with respect to the current  sprints and also what was the uh ones that were   supposed to be done as part of the previous  print and check where we are with respect to   the progress and if in case if it needs some  additional hands to complete the documentation   we ensure that the right persons are available  for the team to have the documentation in place   by the end of fifth stretch that's what we have  agreed internally to complete uh when we have   this documentation ready for the new joiners  and the new people who uh join the team awesome   i really appreciate guys because when you take  an action item and accountability we are working   diligently towards the due date at the same time  we are also working on the current sprint item   so thank you for that and the only dependency  i see is the infra team uh collaboration idol   so i'll work with you on that okay sure thank you  great uh so it looks like a plate is empty so i'm   really happy about that and let's move on to this  uh post-mortem technique that i'm going to call it   for the retrospective so please don't get spooked  by the name we're not talking about any kind of   deaths or post-depth introspection this is  about our sprint and when i say post motive   this is something that has ended previously  and we're just going to dissect it and look   for the opportunities to improve and we are just  going to shed something that is not working out   and we're going to take out some learning items  and action items right so what you can see right   now are four quadrants if you see the left top  corner is the areas what we like so please make a   note of the pointers in which you think that these  are the things that really went well during the   sprint and i really love them right so big thumbs  up for that quadrant number two on the top right   corner what you see is the areas of improvement  so maybe you could have listened to something and   the other team was speaking in their meetings and  you thought okay why not we tried this on our uh   sprint right so we could have improvised let's say  cut down on the testing opportunities is one of   them i could think of next is what we learned are  the list of opportunities that we would like to   bring about okay so learnings and the last one  would be the action items or takeaways that we can   take accountability for us to continue just like  we did in the pre model are we good at that yes actually now i feel that someone is  going to be the sherlock holmes over here   with this technique right yeah i would say  you would get a very good understanding about   or i would say a holistic view about what  is happening so as a scholars it is very   important that you keep a grip on understanding  about the entire process structure as a whole   so that will help you to uh guide the team as  well so yes i am going to be the sherlock holmes   that's all the mystery though let's solve  their mysteries guys okay let's go get going   and let me do one thing i will just open  the link that i have shared with you   so what you see here is a hyperlink please click  on that and that should take you to a page like   you see right now i'm sure we are familiar with  idea boards this is an open source tool where it   is kind of used by multiple areas for us to create  retrospective sessions like this so if you think   some of the companies are not allowing us  we can always go back to our traditional   way of conflicts page right so since  we have the access let's utilize it okay i see the pointers  coming in through pretty quick so just remember your name and your point so that   is easy for us to understand who  is bringing what to the table right and if you see that there are two items it  is similar in nature and pretty much giving   us the same end goal you can delete yours  and click a like on that so we can count   it as one item with two people agreeing to that  instead of having the same item repeated twice okay so we do have some learning opportunities that's  good to bring up and the count is increasing okay so do not fill in anything for the  action items right away the action item   is going to be the combination of all the three  quadrants that we discuss and we will prioritize   the items that needs to be addressed immediately  take it as an action item and accountability   set up a due date and work towards it  just like we did for the last sprint   okay so do not fit anything for the actual item are we good to go i see pretty much everyone has their pointers anyone left to be updated on this board i see everybody's updating just let me know once we are ready for  discussion yeah the board seems to be full now definitely overwhelming lots to discuss my plans for becoming sherlock  holmes looks to be in jeopardy okay shall we start yep okay can  i just look at the board overview   and just try to see if there are any pointers that  is matching we can delete them clear the clutter   and maybe like specific sticky  note if your ideas are matching or all the pointers are  identical non-identical rather yeah uh somehow i feel uh what we missed in  uh shashank and suvarna the more or less it   is the same right feel over user stories  and too many issues found at last moment   so do you think we can club them or uh yeah   up to you shashank uh savannah is your idea pretty  much the same might be a different choice of words   uh the reason why i mentioned spillover story  is regarding the uh the scope rather you know   once we started the sprint uh and we started  working on the user story uh we found out some   uh additional scope there so we thought that we  could split actually split that slow story into   uh multiple stories okay that's that's fine uh  amen well let's do one thing let's get started   in the middle of the conversation if you feel that  something is matching you can delete your and like   somebody else's okay okay so let's begin with what  we like the areas that we that really work good   for us so we have team collaboration that work for  us and we have uh good support from the product   owner and we had got many volunteers adding to  that we had a clear visibility and enthusiasm   and surprisingly we were able to close couple  of items before time that's really good gives   us some time to look at some other aspects  and performance management tools analysis   okay that's working good as well so yes i'm really  happy to see that a lot of factors are going good   for us but i think our major area of focus should  be the area is what we missed and what we learned   right so let's move let's move on to that um so  let's discuss the first sticky note sasha can   you just give us a brief first of what you mean by  spinning off over uh user stories yeah akshat uh   the reason why the one of the user story in this  last print got spelled over is that it had a huge   scope which was not clear at the initial phase  so as in as people started working on this story   uh i think there was somewhat some more detail  needs to be added in the acceptance criteria   so maybe uh so that could be a reason uh why this  actually the scope has increased drastically and   which would take more time for the coding and also  the testing for this user story so i think we can   uh yeah maybe we can discuss about that in the  action item as to what can be taken to avoid this   no definitely it makes sense because unless you  have a good acceptance criteria it's difficult for   a development team to understand what  they are expecting to be completing right   okay so accept it i'm adding that as an action  item we can work on prioritizing that later uh   guru would you like to bring out your point yeah  with respect to uh some of the uh coordinations   with between the integration team and the scrum  team because this integration team sits out of a   different location and there are a separate  team even though there were a few healthy   cups in the uh in the initial phases i think  those initial hiccups would have been avoided   had we actually planned it and as a scrum master  if i could have uh been able to uh foresee that   uh kind of a scenario uh but as some master i  missed that so due to that some of the iterations   got extended of course we were able to complete  that in time but the multiple iterations could   have been avoided had have been a bit proactive  so i take that personally as a scrum master for   my area of improvement so that the same cannot  will not repeat in future and we are able to   bring this kind of a scenario and plan  accordingly that's a mystery question okay   no that's fine every day is a learning for  us so what we're taking away here is uh   effective but a better collaboration right so  i'm adding that pointer in the action item we   can discuss that uh thank you group thanks um what  suvarna would you like to bring your two pointers yes yes rakshith so uh so as you know we started  this test automation activity in order to   reduce our manual testing effort and there  were many volunteers from even from other teams   to participate in this activity so  that is something which is very good   despite their their own targets and their own  schedules they made time for uh this activity so   that is one good thing and another thing is that  we've managed to despite hiccups we managed to   close the feature before time so that is a good  thing okay yeah that's good i mean it's always   going to be a challenge to coordinate between  multiple teams so yes we can work on that so   it is pretty much the same thing that guru is  also facing okay so we have work in our hand   how about this one too many messes  found at last moment could you elaborate   yeah so we found quite a lot of issues we were  good to go we are done with the development and   had we found so many issues i think we  could have uh sped up much better so   we because of these last minute issues  we had to sort of stretch and uh   work on those issues so that is uh one thing that  learned early testing would have prevented that so okay so i would say better planning  yep okay and another thing that   we could have planned better is again we did  not anticipate the participation so multiple   teams and they're having everyone having their own  schedules so that that needs to be sorted out okay yeah thank you for bringing that out okay um how about you adal yes richard  so during this whole you know activity   of finding out potential tools etc uh in that  way i think somewhere we missed on you know   getting a bit more further deep down understanding  what kind of risk we might you know encounter or   go through because since we are more you know  wanted to practice some third-party tools   so that's something i think we again  need to investigate you know further yeah so if i can sum it up i'm  talking about risk management yes okay thank you that's a very good point okay um any update or maybe i may you can just  bring out your pointers yeah so have couple of   things the first thing is on the unplanned  vacations or basically so ideally we planned   everything but uh we you know as last minute  surprises getting that you know i will not   be coming tomorrow or you know so those last  minute surprises which we couldn't take care of   it well so that was on the unplanned  vacations and of course uh we need to   have little bit less capacity i would suggest  like this time we all started with 100 so maybe   we should have little bit of buffer that  would be something so that is one point   then release date yes we had those release dates  and uh we had you know we have said immediate and   other cycles but we did not plan it well maybe  the release date we could have taken somewhere   like you know moving into an emergency release so  that is what we missed and on the integration of   the cicd tools we could have managed it better  there was a bad background job setting and   we encountered at the last  minute so that is what we missed just to sum up yeah yeah so maybe the  ci cd aspect is one thing we can look at   under the planning aspect right and uh  unplanned leaves is something that shashank is   uh working on on the steam calendar yes so we can  work on that as well but i will just mention that   unplanned leaves is definitely a challenge during  this pandemic so yes we have work cut out for us okay so i believe everybody is looking at the  list of action items right all of you agree okay great okay so let me move on to  the areas wherein we were able to learn   something right so so shawn can you just tell  us uh the learning pointer that you have updated   yes so as soon as already planning and  coordinating on the uh automation perspective   right where she's gathering some volunteers who  are ready to get trained and start equipped with   the automation tools and implement that in our  daily sprints right so so that will definitely   be helpful for us to you know uh to save time  uh to reduce the manual efforts and also it   will uh it will also enhance the code quality  of the code that we are currently developing   so i think automation will definitely uh play  a strong role in our daily lives i think yeah   no i definitely agree that is going to help us  bring us product to market sooner than anticipated   but uh yeah that's a very valid point and so one  is doing a great job in organizing the team so   that's a good learning and i understand adult we  are working on the third party vendors and that is   a challenge all together in terms of security and  licensing factor so yes we can work on that and uh   okay that's an interesting point guru  maybe you can just bring up the point uh yes uh uh yes uh yes richard uh one of the learnings was uh  some of the standard codes were not used where   it was required basically what happened  was for the standard some of the standard   validations there were already  classes available in the application   which could have been used but the team thoroughly  uh bikes are injecting parks into the system which   would have been avoided that was a good thing and  also in the process we learned some of the new   classes which uh not many people would be knowing  so that was a good learning for the technology   team and we can start using that  thereby reducing the overall effort   that is required for the team and as a whole to  bring down the efforts for the overall project   got it so follow a specific standardized code  is one of the areas we can look at okay great   point thank you uh ame could you just give us a  brief about what do you mean by effort analysis   yeah so we could have spent more time in doing  more detailed analysis uh rather than just   taking in the first shot and saying you know  these things would have worked so when you   see many things have been missed out maybe if you  could have covered more in our detailed analysis   we could have achieved it in a nicer way so what  i mean to say is rather than starting immediately   let's spend some more time in investigating and  spending little bit of quality time that is what   i mean to say effort analysis okay so we are  talking about the quality of the requirements okay yes up to some extent yes basically bring in  all the clarity that is needed and as a team we   have to understand that requirement only then  i can do a bit of analysis so that there is   less of less factor right when you go later down  the sprint and realize there are dependencies okay that's a very good point so looks  like we were able to sum up the areas   of opportunity and the learnings in the  form of action item can you just have a   quick peek into that and tell me if we are  able to include everybody's pointers today wow so we have acceptance so we are on  the final part of putting actions now   yes that is the most important thing right so   once we get this area clear i'll be  the most happiest person on the earth so we have acceptance criteria we need better  collaboration we need better planning and of   course risk management would be there any  time when we have a third party involved   leaves management and standard code and quality  of requirements a proper effort analysis   will ensure that we do not have user stories  spilling over right like shashank mentioned so yeah so i see that ome has suggested an amazing  way of doing what he just uh suggested right so   when we say effort analysis and understanding  the requirements invest criteria is an amazing   way of doing that right now i'm sure  everybody's aware of what is an invest yes okay and uh we know what is a moscow technique  must have should have could have would have   right yes so yes so this would require a product  owner and the scrum masters working in tandem   to ensure that the scrum master is able to guide  the product owner and making him understand   that not every development team would be able to  understand their business requirement right it's   your job to break it down in a simpler form so  that i as a scrum master can work with my team   and give you a proper estimate right okay i think shashank added that well refined  user stories during refinement session to   determine the right acceptance criteria that  is uh the pointer that i added shashank if   you look at the first sticky note acceptance  criteria yes yes i think that should cover it   you might just hit a like on the first sticky  note sure um so why not create a regular catch   up and block people's calendars so that they  are available to sync up and work together   yeah what do you suggest tim how do you  handle this the challenge that sword is   facing right getting multiple people on a  single call while respecting everybody's time um okay what i what do you think savannah what do  you have in your mind yeah so what i thought of   was just uh right now it's not organized there  are people joining in and moving out working   according to their own schedule while keeping that  flexible we can have a regular sync up maybe once   in you know one or two days so that tasks  for the next days can be planned and that   sort of back and forth it still does happen  while still not disrupting their schedule   that is why that's one way of doing it definitely  and maybe if i may suggest we can try one thing is   since we have multiple teams involved we would  pick up one point of contact from each team get   them on a call instead of getting the entire team  on a call yep yep that's so he or she can pass on   the information to the rest of the team end of  the day our job is to get the work done and not   get everybody on a call right so let's pick up  one pocs from each team get them on the call so   my job can be done with five members since your  party members right right okay let's try that   let's see we can implement that sure so too many  action items guys and everybody i think has put up   a very valid point and these are important ones  but unfortunately we have a two-week sprint and   we have to do a regular work and we cannot accept  all these action items it is going to be a burden   on each one of us so can we prioritize which  one at least we can pick up three action items can you prioritize from the highest to lowest  so do we need to use voting what yep yes yes   so please uh hit a like or keep on adding those  numbers in the sticky notes i can see that we have   already two votes yes so roxy just on a funny note  after a long time i'm going to do a voting again please take a selfie to  prove that that's the trend it's difficult to convince people that i got  vaccinated or i have voted without a selfie it also depends where you have taken   yeah so that's a good point i  would like to take it offline so this is interesting we have one one one and two and uh just one thing to keep in mind guys  okay please remember that if your point is not   considered a high priority it doesn't mean that it  is being completely avoided it's just that there   are other priority items that we need to work  on and we will definitely come to yours right are we done voting yes yes okay yes all  right so we have the highest votes given to   a proper refined user stories and acceptance  criteria right so yes so who would like to take   this action item to communicate with product  understand uh the fact that a product owner   we are expecting them to know it all but  they might not be aware of at times we do   not have an actual product owner we might  have a proxy product on right who is more   of a business owners so he or she might not be  very good in a child so it's important for us as   a scrum master to explain them that this is the  process and your contribution plays a major role   would like to be taking uh ownership on this item  yes would you like to go for it yeah i would like   to take it up uh raksha then also and amaze point  is also similar to that where in investigative and   moscow technique is very important at the users  for the refinement session right so definitely   uh me and amy i think we can coordinate with the  product owner and uh what do you say i mean yes   yes i would love to yeah sure let's do it yeah  right right yes so maybe hit a like on this area   and just combine that uh invest criteria  into your bucket just so we can cover both   ideas into one shot so next on the list is better  collaboration uh better planning unplanned leaves   so for each of the individual action items would  you like to take a responsibility guru savarna   uh brexit i would like to take that uh on my  plate okay okay great so wonder how about you   the planning part so savannah you're planning and  you're a pointer about creating a catch up right   so you and i we can both work on that let's set up  a call with only the pocs and let's kill that bird   yeah awesome done so other unplanned leaves  how do you want to tackle that i think this   can be handled pretty quick we don't need an  action item to take it and follow through it   for the entire sprint uh what is in your  mind i mean how would you like to solve it   so uh adil and we both were discussing  that day that let's say maybe we can   have a good communication plan so  if there is an emergency leave and   you know usually we are not being notified  so there we are looking for some different   options where they can communicate us in a better  way so uh and also when they are going on leave uh   just having you know uh to to get it done in a  nicer way like even if they are on emergency leave   if there is nothing or like there is something  priority so some of them or he can tell you know   either adil or myself whoever can take you know  his part at least for some point which is very   critical so such things are popping in my mind yes  yeah yes um i would also like to bring one very   important thing especially uh in this time of the  mental situation that everybody is going to write   planned and unplanned leaves could be the last  of uh the point that i would like to think right   now when something is happening with me right  emotionally so as scrum master it is important for   us to have that emotional connect and understand  that not everybody is mentally fit through the job   they are handing to challenges and coming to work  so i would say maybe have a little bit of more   buffer of taking less work during the sprint and  have some part of a buffer for unplanned leaves   we can tackle one way of doing that and maybe we  can also use the team calendar that shashank has   been working on so these two aspects what do you  think we can work on that yeah yeah excellent i   think uh myself and shashank we will all come  together now yeah more closer okay yeah yeah okay yeah and uh also ensure that you are not  overburdened you do not have so many items on   the plate feel free to drag me in i'll be happy  to contribute right let's get this action item   very clear up okay any questions okay so this  has been uh i would say an amazing retrospective   of what we did as a team so that's amazing work  we have so many areas to work on and hopefully   next sprint retrospective is all about  changes and uh less of missed right   and let me move on to my favorite part  okay let me go back to sharing the slides okay so team what do you think about  this what do you mean by this   oh i was waiting for this here finally this  has come so bring some smiles again on our   faces thank you thank you and i hope everyone is  waiting thank you so much yes show your love show   your respect everything that you actually mean  for your team members let's let's get this done   this would be a big motivator for the entire team  to work more better ways and also bring in the   much needed the other side of each person so uh  one thing that always crosses my mind right our   families appreciate so much we do to be with them  to take care of them you know to take care of   their necessities give them a good life but if  you notice uh while you are doing that you are   actually spending 90 percent of your work with  your team members so this is your second family   so give it a thought right we are the  family so let's appreciate each other   sure and also uh without the support  of our family at home so that's   this is not possible to fulfill our  work and what's in our plate right   so it's really tremendous that uh that how uh  both the families are working together to get   the right outputs and the and the goal achieved  right so that really is a a plus point yeah okay um let me go to that link did i share the  link with you guys uh the team appreciation link   should be available with you yes yes on this slide  okay great let me click on that link i will go   there and let's have a very good visibility  as to what we have to say about each other   i would like to say thank you to you your uh i see  already a positive message on your shirt happy so   makes me happy more now yeah i'm always happy  with you guys because you're so cooperative and   coordinating right so definitely the collaboration  between the team members is uh that's what i'm   saying right uh you know uh you need each row to  you know to push this boat forward right so with   every push and every only then we sail forward  so i really feel lucky to be a part of this team   thank you guys you just uh brought back  my memories of enjoying this retro right true i remember that pirate background  was amazing yep by the way i wanted to   ask so are you giving a straight looking at you  know the recommendable work the team has done   so should we ask you for a treat as well   yes i'm always open for having an amazing  team treat or maybe a lunch or a get together   so right now it's going to be virtual so what do  you think guys i have something in my mind i was   thinking how about we create a team party  pool right we just contribute some amount   in that pool and uh whoever is maybe let's  say the star of that sprint we can give   him or her something maybe in a coupon code or  amazon gift card whatever you say do you think   that's going to something and the shipping  address will be ours and the billing address uh i think there was a disconnection  in the audio i could not hear it so i can say i can start availing  because this is the first time i'm   getting so much excited my name has  come popped up so many times thank   you team i'm feeling very much obliged  now thank you team thank you so much good job man you deserve that you deserve  everything that you are bringing um so it has to be yourself  that you have to do right now yeah i will feel a short of words  to all of you thank you if you i know today's theme is postmortem so if you think  that somebody's actually patting on your back   don't get smoked wow that's some amazing list of appreciations  are you guys done shall we just go through one   of them or maybe a couple of them or all of them  i would say why not yeah sure okay um so let's   see let me just sum it up for everyone okay so  thank you may for helping me on the tool analysis   appreciate the team for volunteering to contribute  to test automation despite tight feature deadlines   guru what's up once again as coming  as firefighter great job nacha for demonstrated your leadership skill as well as  thank you for sparing extra time and dedication   and commitment yes definitely i may explain the  business process which helped me develop the   coding of user stories i'll help you understand  the release process as i'm new to the team great   job you're nurturing the talent so wanna help me  understand the pair programming that's amazing   ah they'll help me understand the  release process as i'm new to the team   uh looks like it's duplicated but twice  congo thank you fans appreciation to team   for the support during the draft sessions for the  final cut yep guru was very patient and helped   clarify many doubts despite having his action  items in play yes guru you're taking a lot of   stuff on your plate so ensure that you have a  bigger plate right yes thanks for that and uh   guru thank you for coming as firefighter as usual  looks like you're gonna be renamed as firefighter   um thank you exit for making sure team did  not have to worry about impediments you're   most welcome um shashank thank you for making  team calendar and always being supportive yes   all right so that's uh oh we have one more thank  you rakshit for being a wonderful scrum master   is that sm scrum master or sms superman   both i'll take it both well thank you so much guys  so it's definitely not possible without having an   amazing team when i say amazing team this is  right now my second family so i love you guys   and thank you so much for being uh the amazing  folks and work in personal life and everything   we have something for cinnamon for helping  during this print review thank you sunan for that   so if you look at it everybody is making some  part of an impact with each other's life right   did you notice that yes that's right we are  kind of in a mesh network right everybody   is connected and everybody is helping  each other out so that's the beauty of   being in a closed net team right so whenever  you invite somebody in the team let's ensure   that we give them the warmth and accept them and  make them feel at ease right that's the job so   i would say an amazing uh sprint  retrospective what do you say guys yes yes   so that's it everyone can claim points now  right because many stickies around so right uh yeah it's expectations are actually  getting higher and higher and higher   so please think about how much you want to pull in what do you have in mind  what are you planning to buy   yeah amazon voucher for sure uh i  want to buy an amazon voucher yeah   okay guys let's make that happen we can take  it offline we can create a pool and uh give   something that amir actually deserves right so  may thank you for being the star of the sprint and uh i would be sending you a form  which would better potentially be   your feedback to see that how we  can improve on the upcoming sprint   and um let's continue doing the amazing things  that we have been praying thank you everyone thank you thank you thank you thank you okay guys  first welcome guys thanks all and i just want to   take two minutes of everyone's time so guys uh  honestly like i have seen a lot of retro in my   short career of whatever last seven to eight years  and i would say that this is the one of the best   retro which i have seen and who is uh watching  this video i must tell you uh the hard work   which all these people have uh done to bring this  retro session in front of you and you can learn a   lot of things from this retro this is uh i think  uh better than the actual retro which i have seen   and i just want to thanks everyone  rakshas especially the way he has   drive this uh complete retro session and all the  participants whether it's guru adil shashanks uh guys right now it's 11 o'clock in the  night and i know uh it's a long i mean we   are just shooting this uh session in weekdays  so it's going to be very tough tomorrow again   these people will woke up so i really want to  thanks personally to each and every one of you   you are taking your time and i'm sure that this  video is going to be uh at least add some value   to and a lot of other people who's going  to watch this video so i really appreciate   each and every one of you on the time which  you have taken and the way this uh retro   this session is come up i'm really happy uh  yeah guys thanks a lot rakshit one more time   sure thank you thank you guys for amazing uh  time that you have spent with each other trying   to bring it into life so kudos to all of you okay  thank you thank you so much thank you thank you   good job thank you thank you a big hello to all  my fellow scrub masters welcome to one more live   demo simulation session friends there are so many  articles books youtube videos on sprint refinement   but none of them shows us how it actually  looks like in real world this session is our   small attempt to solve that problem we have done  similar live demo simulation sessions for the   sprint planning spin review spin retrospective in  the past so go and check them as well link of all   those sessions are in the description box friends  our team of experienced scrub masters spend lot of   their personal time for this session so you all  can learn from it and be successful in your job   please please appreciate their efforts in the  form of big like and if you are new to our channel   careers talk then please do subscribe you will  find tons of valuable content for the scrum master   on our channel so let's begin this session without  further delay what do you show with hi everyone   i'm shawwaik and i'm an experienced agile and  lean practitioner with 13 plus years of experience   i bring more joy to the workspace and i increase  productivity by helping executives managers and   employees to create a better work environment i am  passionate about inspiring teams on agile values   and principle and also transforming the team  towards building a frictionless organization   so why we are here today so in today's session  we are going to discuss about backlog refinement   we will do a deep dive and also experience  how it's done right and how it's done in   real world and in real projects with real  people so without further ado let's begin what is backlog refinement so credit backlog  refinement is a method of keeping the pro backlog   updated clean and in the order of priority  so backlog refinement is a collaborative   discussion process to decide if the backlog  is ready for next sprint or maybe next couple   of sprints if the backlog is well maintained a  lot of time is saved at a screen panning right   and if the user's theories are well defined  acceptance criteria clearly mentioned risk   and dependency identified and highlighted and even  uh you know cross checked by all the team members   and then the planning meeting will be easy for the  team and this backlog refinement it also gives us   an opportunity to the team members to you know  interact with each other regarding the stories   and have a shared understanding it increases the  efficiency of the team by reducing uncertainties   right and refined stories are always easy to  estimate develop and test and implement right   uh so that's that's what the other backlog  refinement is all about so there are a few   node for the points uh backlog refinement is not  a scrum event okay we will talk more about this   in the next slide and uh the scrum team decides  who how and when this refinement will be done so   there is no fixed criteria it again depends from  depends uh on the product that team are building   and deposed from teams team uh refinement usually  consumes no more than ten percent of the capacity   of the development team right and the product  backlog items can be updated at any point of   time by product owner or at the product owner's  description so as we all know right backlog is   owned by product owner so he has he can uh update  the product backlog at any point of time yeah okay so as we discussed in the previous slide  that uh backlog refinement is not a scrum event so   there's there's a lot of confusion among the  people especially who are new to you know the   world of scrum uh that refinement is one of  the scrum event so we all know like there are   five scrum events and refinement is not part of it  but why why refinement is not part of it right uh   what is the reason so we uh if you see like  refinement is not same for all the scrum teams   right we can't say that we can universally apply  uh this uh refinement meeting to all the all the   scrum teams in the world right we can't say that  it's a silver bullet one size fits all kind of   meeting it varies it varies based on the team  and the product and the complexity of the work   right and uh so maybe uh the question that you  can ask me is if it's not an event then what it is   so it is actually a product management practice  right it is it can be used by a product owner   to make sure that the operat backlog is  healthy it is in the order of priority it   is it has got uh it is well thought through and  it has got all the required information there   right so another reason and the very important  reason why it is not an event is that we can't   have a predefined set of attendees or a predefined  uh duration of predefined frequency for this   backlog refinement it is very you know contextual  do we have an upper limit that it should not take   more than ten percent of the capacity of the  development team but we we we are not very   sure like uh what should be the least amount of  capacity that development team should put in or   the scrum team rather the scrum team should put  it into refinement if the product that the team   is working is pretty simple and not well not so  simple because scrum is applied in a complex world   uh if i say uh the product that a team is building  uh as uh they have the roadmap clear they have the   uh the product is evolving and they can uh in the  the team is mature and they can do the refinement   even during their sprint planning they don't  need a refinement but then there is a team who   need to more time to do refinement so they must  be spending at least 10 percent of their time   in a sprint doing the refinement for  the next next few years friends right   so it again depends on team to team productive  product and it's very contextual in nature let's discuss who should participate in backlog  refinement so as we discussed in the previous   slide that there is no predefined uh set of  attendees uh but let's see who are the primary   participants for uh backlog refinement so ideally  uh if we are having a team scrum team is having a   backlog requirement uh the product owner uh  the scrum masters and the developer should   be part of the planning meeting so that  is the requirement like the whole scrum   team should be there but again it's not  mandatory in case there are the cases where   a product owner along with a couple of scrum team  members couple of developers can have a meeting   so that is also kind of a refinement or just  a product owner a scrum master can have a   meeting that's also kind of a refinement  so it again depends right but ideally the   whole scrum team should be present because the  idea is to have the shared understanding right   and then we can also invite the stakeholders  or the you know other business sponsors uh   so suppose we may have we need some clarity  around the business requirements or we need   some clarity around the project goal and maybe  a po can explain that or pio needs some help to   help in explaining that to the team  he can invite the stakeholders and his   business sponsors into this meeting  so that they can come in and share   their views uh help the team in clarifying doubt  so yes uh we can invite uh stakeholders and other   business sponsors only and they can only join  upon invitation it should not be like taken   force in themselves into the meeting okay and  uh and thirdly uh we we can also invite some uh   cross-functionality members maybe architects  or the ux designer or maybe business analyst   or maybe uh if there is any center of  excellence team right who are working or   building a new logical solution new technical  solutions and this team will get some need uh   to implement that in their future sprint so they  can invite those person to gain that knowledge   gain their learnings or learn more about what they  have built so that the team don't have to reinvent   things from the scratch and they can reuse which  is already built or maybe uh the architect who   can help the team the development team member  to decide on okay which approach is best suited   or sustainable right so again optionally we can  request any member any cross functionality member   for their feedback of what their inputs  into the backlog refinement meeting   okay so let's uh divide the backlog refinement  into three parts like what is needed to be done   before backlog refinement what's needed to be done  during backlog refinement and what's needed to be   done after backlogger planner so first of these  three parts is like before backlog refinement   who is responsible for doing what so i'll go by  points so product owner need to create the user   stories so it's the responsibility of the product  owner because he is the one who owns the product   backlog to make sure that the user's stories are  created right and it is created keeping the invest   criteria in mind and also the definition  of ready in mind because without this too   especially without the definition of ready  uh it will not be accepted by the scrum team   members right like right by the developers for uh  starting the work yeah and when i'm saying product   owner needs to create there's a story again it's  not a hard and fast rule uh it is recommended   that product owner will create a user story  but when you go on the ground so sometimes he   product owner you know business analysts or work  very closely with them and they create the user's   stories you know the direction comes from product  owner and the business analyst used to create it   but yeah ideally the product owner is the  one who was supposed to create the user's   stories keeping the invest criteria in  mind and the definition of ready in mind   what else are we going to do in before backlog  refinement okay so yeah project owner uh based   on the his vision uh his discussions with the  stakeholders or the sponsors and based on the   project goal uh he will prioritize the backlog  like whatever user stories he has created he will   analyze or he will maybe the scrum master can  help the product owner with some prioritization   techniques and help the ppr user stories that  were there in the backlog on the order of   priority which will generate maximum value for  the customer of our stakeholders right so that   the prioritization will need to be done by product  owner before we get into the refinement meeting   next uh scrum master so what should disturb master  do before the refinement so scrum master need to   coordinate with the product owner to identify what  are the potential prioritized user stories that   need to be refined so scrum masters will have a  quick chat with the product owner uh ask him like   okay uh what what's your plan like what is the  plan for uh the next sprint or next to next sprint   what does the what uh what are the demands from  the customers or what the stakeholders need let's   uh practice those items and keep it ready for the  refinement try to create the user's stories try   to put in whatever we know as of now into the user  stories the descriptions the acceptance criterias   and then the uh any dependency and risk that we  can think of put everything in there and then   during the refinement we can discuss more right so  that's an idea scrum master should promptly reach   out to the product owner before the refinements  make sure that the potential prioritized user   stories are there and uh ready to be taken  up during the refinement for discussion right   now what the development team should do before  refinement so ideally the script master should   uh communicate once uh uh po and the scrum master  collaborated and identify okay these are the set   of five is two or five visual stories or you  know six two user stories that we're planning   to discuss in our next refinement or maybe scrum  master can uh send out a note to the whole team   and the team based on their available bandwidth  can go through this user stories before coming   into the meeting so that it will give them  give them an opportunity or some bandwidth   to prepare accordingly like they can they have  they will have the time to think through uh uh   what are the what are the requirements  or what are the kind of questions they   can ask during the refinement and uh what are  the what all can be the risk and dependency   so sometimes uh census refinement may be can  be a one hour long meeting uh while product   owner is explaining something uh the developers  may not be able to think on all the aspects but   if the scrum master is sharing the user stories  beforehand uh the scrum team or the developers   they can go through the list of resources that  are going to be discussed as part of requirement   and they will have some time to think uh on all  the different aspects of that and can come up with   more uh relevant questions right which may not  uh may not be feasible in that short period of   one hour so that's that's something that uh good  scrum teams do uh and lastly uh as we discussed   uh we we can invite people who are not part of the  scrum team like optional members from different uh   uh cross-functional teams like architects  or sometimes the business business sponsors   stakeholders so if we share the same uh set of  user stories with them they can also go through   them uh user stories and come prepared like  okay what how they can contribute how what all   inputs they can give during the discussions that  we're going to have during the refinement yeah okay so what we do during this backlog refinement  meeting so scrum master facilitate this uh backlog   requirement session and uh uh to kick start he  will uh ask or remind the participant like all the   developers that uh they they should you know ask  questions and he encouraged engagements basically   and he will make sure that the whole meeting  is time box and all the time is best utilized   just for the refinement right uh the idea is uh  to focus on more on what what needs to be built   and why it's new to people and less on the how  part like how it needs to be built right that   that thing can park the team can park it for  some other meeting right so to start with the   the product owner will uh describe the user's  stories uh the brightest set of user stories that   were taken for refinement uh to the team uh he  will explain about all the uh different criteria   maybe all the acceptance criterias what is the  business value what is the workflow look like   what is the usability what are the risk you know  what are the performance dependencies and what are   the interface etc etc so there can be many things  and once uh the product owner explain a user story   to the whole team uh at that point of the time  the team or if in case there are some other   members who are outside the team are attending  that meeting they can uh you know discuss around   on that user story and uh if they have any doubts  they will seek the clarification from the product   owner right and the team also discuss around  the amount of work the technical challenges   or technical uh dependencies complexity etc etc  and they they try to seek the clarity um among   themselves and if there are open questions  they go back to the product owner to seek   more clarity on that okay so that's the uh that's  what the development team members do during the   refinement meeting uh and sometimes what  happens say if there is uh some questions   which need the answers or which the questions are  more on a technical side where the pu may not be   able to provide clarity uh and if any architect  is there in the meeting so the architect is kind   of a member outside from the scrum team they can  jump in and they can share their input right they   can share their ideas like okay how it's going to  be or uh how it looks like similarly if uh if the   question is more around the business side and  it's beyond product owners uh knowledge then   and if a business sponsor a stakeholder is there  in the meeting they can pitch in and they can uh   help answering those questions for the team right  so that's the idea let's move on to the next slide   uh okay so there are a few more things  that we do during the battle refinement   uh once uh the team is aligned the team had got  that shared understanding then scrum master will   facilitate this estimation for that user story  so the idea is once uh team like talk through a   particular user story they identified all the risk  and dependency and discuss about the complexity of   that particular user story they talked about how  much effort that that will go into implement that   then uh it's a good idea to estimate it and keep  it ready for the uh sprint planning uh so now the   scrum team will facilitate this estimation session  uh he can use anything maybe a festive five or a   planning poker or t-shirt sizing whatever it is  uh the team is comfortable and they are using   they will use that estimation techniques to  estimate the user stories and then update   it and keep it in the product backlog yeah so  that's the whole idea and then the po will again   move it to the next user story and he will  will do the same cycle until all the uh user   stories that we identify to take up in  the backlog refinement are covered right   now there are can be few cases uh few scenarios  but things may go uh not as per plan so let's   discuss about those uh suppose there is a user  stories uh uh that okay team understood uh what   is the complexity what is the effort sizing  voter dependency what are the uncertainties   and after the discussion uh and the team they'll  go for the estimation and the estimations were too   high like it's in the range of 8 10 or 13. uh  and then uh or maybe if you're doing you know   a t-shirt sizing it's in the range of xl or l so  it's a good idea to break it down into smaller one   so the team will get in a discussion  again and uh with po's description if   you can split those big stories into the smaller  stories keeping the invest criteria in mind right   and uh if if it's possible we can do that then we  will just do a re-estimate for those two splitted   stories or two slice stories and give the story  points and park it in the background so that's   one of the thing that we can do uh what else uh  another another scenario say uh while discussing   while discussing one of the user story uh there  are some questions uh raised by the team uh where   you don't have the answer and we don't have the  stakeholders or the customers in the call so in   that case po is not in the position to give  an answer and without that answer there is   too much of uncertainty around that user story  where team can't move even move ahead and give   estimate that particular user story so in those  scenarios scrum master will suggest or propose   uh to park this user theory for the next  refinement uh and uh request the product owner to   go back and get clarification on these open  questions around this business uncertainty   right so that's another scenario and then the  another scenario which is very typical is uh when   there are technical uncertainty say now team is  discussing and there is a healthy conflict between   maybe two of the developers one is saying that  okay this approach is uh is good it will take   less time and we can you know release the product  within the two sprints while the other person or   the developer he has an idea of saying that okay  this approach doesn't look sustainable because   three months down the line we have to  scale up and this approach will not   help us in scaling and at that time it will be  a rework for us and we'll be adding tech debt   if we go with this approach now there is this  healthy conflict and uh product owner being a   person from a business side he may not be able to  answer that so what uh project owner can suggest   or even if the architect is there he can suggest  let's do a quick spike you know try out both the   approach see what are the pros and cons which  is more visible and then uh we can decide it   will help us to decide like which uh which  approach will work and until we do the spike   on both the two approaches let's park it yeah so  this is something uh which we normally uh you know   uh see during the refinements uh it's a very  normal case so these are the three different   scenarios which you can think of so yeah these are  the things that we do during the backlog refine   okay so what we do after backlog requirement so  normally uh there's not much on the developer   side or po site that that's need to be done after  backlog refinement until and unless there is an   action item as we discussed earlier where po  is going to seek clarity from the business or   the team is going back and doing a spy but  typically what uh what uh the scrum master do   after backlog requirement is uh or he's supposed  to do is uh to send out the meeting minutes you   know and the list of the stories with the story  points which were like already refined and   estimated so he will send out those to the team  uh just to be more transparent and communicate   right that's the idea and uh scrum master can  also send out a backlog health report again   it's not mandatory but it's good to send uh what  is a backlog health report uh if i have to just   train quickly it's like how many user stories are  there in the background backlog and out of which   uh how many are prioritized and out of those  practices user stories how many are refined   and estimated so it will given the fair  idea to everyone the scrum team as well   as the stakeholders like how how what all things  are refined and estimated and on the top of the   backlog which are which they can expect  in future uh expect in near future right   okay so this are the few things that  we do after the backlog refinement let's see what are the prerequisites for backlog  refinement so uh i already discussed it earlier   uh in the previous slide uh the only prerequisite  thing before we get into the backlog refinement is   a prioritized future backlog based on  the product vision and the project goal   and this needs to be done by the product owner so  it's product owner's responsibility to make sure   that the backlog is prioritized and the order  of value generation and uh he should be able to   identify the number of user stories that  needs to be part of the refinement where   the team is going to discuss on that and you  know refine and get it ready for the next sprint okay now let's see what are the deliverables  from the backlog requirement so once the backlog   refinement is done uh we can expect three things  first is the refined user stories with uh with the   clear acceptance criteria and description right  and uh and also maybe uh most of the times we   also estimate and make it ready for the planning  so yeah refined user refined and estimated user   stories with clear acceptance criteria and  description uh the other thing which is a   takeaway after the backlog refinement is that the  whole team is having a shared understanding the   whole team is on the same page right okay and the  last thing is if there are any dependencies which   were identified during the discussion those will  be highlighted or may be added in the user stories   so it will help the team when the actual they will  get into the actual work uh it's easy for them to   look into okay these are the dependencies or uh  these are the point of contacts where i need to   reach out it will be easy for them to uh you know  reach out to those people or uh mitigate those   dependencies or risk rather than figuring out  everything during implementation so it will save   a lot of time and make life of a developer very  easy yeah so there are these three outcomes as   part of other deliverables from a backlog refined  with that we are now at the end of the boring part   so what's coming up next is full of excitement and  learnings uh thank you everyone for your patience   and thank you for listening please do like comment  and subscribe our channel it's our it's your uh   love and support which keeps us motivated to  you know come up with new and engaging content   yeah so let me quickly introduce you to the  team and then i will hand it over to sunan okay   okay so this is our scrum team is our product  owner arun priya manoj ramya sashan venkata   sindhu neha and shankri are our developers  and i'm playing the role of a scrum master   so we do have a big scrum team uh not as  per the scrum guide so sorry about that   but yeah thanks and let's see what's coming  up next over to you soon okay thanks shovik   for the great presentation and uh i think it's  time for our live demo so over to you show it yeah thanks thanks so much for that okay  uh hi team how are you guys doing today   good how are you good good thank you you're ready  thanks everyone for joining taking our time to   join for our backlog refinement so uh just to  give you a heads up or i already communicated   to you over the mail that uh our pio kirti has uh  planned to discuss five uh user stories for future   sprints uh so without wasting much time i'll  hand it over to kt but yeah one thing before that   uh there are five stories and you as you know  like this meeting is sandbox for one night so   we'll try to have a good discussion try to have  the shared understanding of all the stories that   is going to explain as a team and we will  try to like i will try to see if for each of   the discussion for one user story is not go  beyond 10 minutes so i'll keep a time check   i'll keep you guys reminding if you guys are  getting too deep into the discussion okay   okay just a disclaimer uh over to you sure thank  you for that time boxing thing and hello everyone   and since i can see some new faces out here so  i'll just be reiterating the product gold ones so   that we are all aligned and we can understand the  product much better our product much better okay   just a second i'll just share my screen and here  we go so uh as you all know this is the fintech   mobile app a very futuristic one which we are  all proud of building and this is the one which   we are going to build in near future but uh some  of the features i would like to explain here now   so so basically what is the fintech app it's  uh something which can do everything right   from stock shopping to payment payment wallets to  uh creating new user accounts transferring money   depositing cash withdrawing cash anything  and everything what eases the life of   any user so we'll just be building this out  and this is what uh the fintech app stands for   uh so as you can see these are all the features  which we are going to build in near future   so the first epic is what we are going to  consider here today in our session as well   is the new account creation because that will  just kick off uh once the user boards in and   gets onboarded on our app then we'll be able  to have a customer profile kind of a thing it's   the spendings uh we'll try and make things more  and more easy for the user to just view and um   and the onboarding also of the user should be just  seamless so that they don't feel much trouble uh   joining our app okay so this is the first one uh  the second epic is transaction management uh this   is a very critical part since this leads with the  money dealing so i would just like to explain the   flow once uh based on the how transactions are  going to flow in our app so the first one is   initiate relationship where the user is going to  send the request to the sender bank and uh the kyc   will be verified know your customer as you call it  and the transfer request and some the transfer and   all these flows will once it's validated then we  actually get into the money transfer part so where   uh the request will be flowing to the beneficiary  bank and uh the same way the there'll be a real   time update where uh based on the currencies based  on the taxes based on uh all the dealings of the   money the total net amount will be decided and  then uh once the amounts get delivered to the   beneficiary uh the beneficiary banks is again  going to get validated and then the finally once   all the kycs and all the validations are done  then the finally the amount will be getting   delivered to the beneficiary bank and same uh  the distributed ledger we are going to update   all the accounts concurrently and that is what  the on-demand reports also suggest where we are   going to uh get the confirmation and the reports  will be published so this is what uh is about   the transaction management uh the next one is  again the part of the transaction management   epic which we are going to discuss today it's  about withdrawing cash through app which would be   cardless you heard it right it's cardless we are  uh trying to have a functionality built in where   we are going to go through the atm and you forgot  your car but what do you do you can't withdraw the   money no the app is going to solve the problem by  actually enabling you to withdraw cash from the   atm without using uh your card at all so  we are going to discuss it more based on   the user stories we are going to go with  but here we are done and any questions   team which you would like to ask here based on the  product goal or shall we move to the user stories yes okay fine so uh we'll go to the first user story  which is part of the transaction management   epic so as a fintech as a regular fentic user  i want to transfer money from my bank account   to another bank account using fintech mobile  app so that i can easily manage my finances   and pay my bills on time so this is a regular  feature which we've been using it across our apps   currently uh but a very important one because  there will be a lot of validations in place   so the acceptance criteria goes like  this user can log into the mobile app   user can enter the desired amount to transfer  desired amount is within users current balance   receivers account information is authenticated  prior to transferring the amount both accounts   are updated concurrently after validation email  and in-app confirmation of transactions are   sent out to users and receivers so this is our  first user story which we are going to work at so this functionality should  work for the existing ones   who are already using our app and  through banks they have already   got the app in place and their uh transactions  are in already in process but this functionality   we need to enable through our mobile apps  uh yeah yeah i see nia is having a question   yes so uh we have to add beneficiary  before transferring the amount we have   to add beneficiary that's right we have to  add beneficiary uh before transferring the   uh that's right nia we have to do that like  how much time it will take to activate that   beneficiary after adding yeah so i would just  like to answer this question like this time there   are two kind of uh transactions which are having  if we are doing a upi payment it can be done on   uh real time without adding anyone uh  okay and uh if there are beneficially you   uh you would like to add for because it it  is going to be a recurring payment then um   it should be uh we have we are targeting at uh  around not more than 30 minutes because uh there   are some banks which are uh taking a day or so and  we want to be really competitive on this front and   we want to make it more and more real time so  it's not more than 30 minutes is what once we   add the beneficiary it should not be more than 30  minutes to make it functional okay that's clear   and uh one more point like we are having some  otp verification also otp verification is um not   required in case where um otp verification as  in during the transfer of the money or you are   asking from the beneficiaries end no why we are  transferring money okay while we are transferring   money if you're doing through your app uh there  will be an otp which will be coming post you   initiate the fund transfer not during adding the  beneficiary um did i answer your question yeah   okay thank you so much thank you thank you for  your question yes is also having a question uh   yes my question is like the payment uh what we  are doing is it within the same bank or we have   that facility to like make transfer for other  banks as well and how are we going to proceed like   if it is for other banks so it is followed up with  an ask question like do we have to authorize them   before it is the same yeah so any bank it  is we have to authorize them we have to add   uh but it should not be more than 50 minutes the  timelines remains the same and to answer your   first question yes it should be any bank since we  will not be limited to just our bank it will be   any other bank transfer we have to uh just be  ready for it thank you yeah no problem okay   you can go next with your question yeah so uh  what i see here like pay my bills on time looks   like i can use this up for paying my bills as  well right so yes i feel like if i want to pay   let's say like i want to pay my electric bill  so i don't have anything to add in my like   beneficiaries in my account right so how will i  do this uh no actually if you see even if you are   going for paying any of the bills there is  an account number provided so you can add   that as a beneficiary for now and then  we can have this functionality in place   uh for any of the uh billing uh partners for  us so there is a account number and there is a   details provided for every site you can add  that be it like credit card bills if you're   trying to do so you can add that as a biller  and you can go ahead and do your payments okay so you mean to say like anything whatever i'm   trying to transform money so there should be  beneficial account number for which uh which   need to be configured in my account yeah  so beneficiary account number or upi both   both of them is what we are targeting for this  print at least we are going to go it more and more   deeper uh during our coming sprints but this is  the minimal viable feature which we want to have   for this print where we are just starting and  kicking off with a one payment kind of transfer   beneficiary and upi all right yeah thank you so  much thank you does that answer your question yeah i got it thank you okay great question  i see priya is also having a question   maybe yeah so i just want to ask there would  be any upper limit for this transaction   like you said desire and mod is within the  current balance but suppose balance is like   um three lakhs and he wants to withdraw kind  of uh the two legs so is there any upper limit   so it's a very good point i think i  should modify the user story with the   daily amount which which can be withdraw uh  the maximum limit is 50 000 for now okay yeah okay any more question for me no thanks  thank you uh shankari i believe you also   have something to ask yeah so is there any  restriction on transferring amount to the   beneficiary account if the beneficiary account  is added now and is there any limit it should   the transaction can happen only after 24 hours or  is there any limit within that 24 hours any amount we don't have any limitations of amount  except it should be within the limit of 50 000   and beneficiary should be once added it should be  active within 30 minutes is what we are targeting did i answer your question yeah yes  thank you thank you for your question okay any more question from anyone and casey you just mentioned about the 30  minute limit after adding a beneficiary   will that be part of this story i'll just start well casey is adding is there any more question  for on this user's story so like this is not a question but  i'm just trying to recall like uh   i think we have already implemented something  related to login that mobile lab right so   could we use the same functionality over here  also or what is the need just trying to understand the first point over here user can log into the  mobile app right so for login functionality uh the   secure like password all those things  we have implemented that functionality   earlier right so we are going  to use the same thing or   is there any specific requirement in  this uh user story for login perspective if you like to answer that um okay so if i mean  for if for any other uh business bank or you have   used the existing functionality we can definitely  uh use the exis existing one which will definitely   save lot of uh effort for us and uh reusing will  definitely uh be enabling us to build more and   more functionality faster so we would definitely  like to go ahead with it but look and feel should   be what uh as per what we have already discussed  uh with our stakeholders and we need to uh stick   to that all right yeah thank you so much thank  you thank you okay guys thanks for asking some   thought-provoking questions uh if we all are good  and no more question uh shall we go for uh justify thanks for meeting this story let me get see everyone and watch my video okay  uh on account of three maybe if you can tell me   what you think about it your story should be as  per your shipments okay so yeah one two three okay i see most of you are showing five five  five five five no that's a unanimous decision   no conflict okay i see oh sunan is showing  it as eight so most of us are fired   us you like to share why what make you think  that this user story is worth 80 story points i think our team members are pretty new   they have joined recently so we never know right  who is going to pick this so it will may take   time for them but then i believe if everyone  is uh agree on file so i will also go with it   okay great thanks thank you so okay if  you just update the story points to five   then we can move on to the next one thank you team for wonderful  questions really appreciated so we are done with user story number one we'll go  to the next story okay so the next story is pretty   interesting as a regular fintech app user i want  to withdraw cash from my bank account to another   bank account using fintech mobile apps so that  i can easily withdraw cash without using my card   so the user story um says that when like i  explained during the product vision what we have   uh we want to make the transactions more and more  seamless for the users and uh the card should not   be a mandatory thing for withdrawing your cash  okay so once we uh user can log into the mobile   app user can enter the desired amount to withdraw  they definitely have to go to the atm machine   and this car technology can be drawn using  the quick qr code so there are qr code which   pops up on your screen in the mobile screen and  the atm also when you enter uh the um your uh   there's a option of scanning the qr code in the  atm when you scan that qr code which is reflected   in your mobile so that uh and the desired amount  you have already entered based on which the   qr code will get generated uh so the um so it  once this is within the desired amount uh the   atm the cash will be withdrawn from the atm and  the accounts should get concurrently updated both   in the your account as well as uh so and email  and in-app confirmation of the transaction needs   to be sent to the user so this is the story  uh next story which we are trying to build any questions team on this story yeah i see uh dp guys have a question for you   do you think i can go and mute yes i had a  concern regarding the security uh issues here   so in case i have lost my mobile and i have  not set any screen lock app lock anything or   like that so how is that taken care like security  issues are considered and how it is what are the   measurements taken here to resolve those security  issues right so uh if you know the uh the main the   beta version of the app which we had delivered uh  developed where we have the fingerprint scanner   right so without your fingerprint scan the app  is not going to uh open so if that is not good   gonna open then this functionality will definitely  not work so security part we can cover with that did i answer your question they pick or  anything else which you would like to ask ah   no but thank you thank you deepika  thank you thank you for your question   okay i see aaron also is  having a question for this um authentication by entering that in the atm mission  it's kind of fun can we do that harley i don't i   i just could not hear your question can you just  please repeat so um along with you know the cure   uh code scanning initiative mission can we add  another level of authentication by uh entering the   debit card pin in the atm mission so that you know  we don't have to worry about the security thing   it's double validated yeah a good point uh i  think i need to talk to my stakeholders about this   because uh yeah so i'll just get back on this  um i'll just put it on my notes and um i'll just   get back on this yeah okay so it seems it seems  there are few clarification that is needed here   uh but i see neha is also having a question  on this maybe yeah you can on youtube another account refers to different  user account or what it means here another user account sorry  i didn't get this question   here in user storage is written  that uh account to another account okay i want to withdraw cash from  my bank account to another account   sorry it's it's just that um  i want to easily withdraw the   okay yeah i'll just uh good good catch yeah  i'll just correct this okay thank you no problem that's what qa are for right yes so is it the same current balance  uh the limit would be a daily 50 000 no no we are going to go  with the same 50 000 limit okay shall i add that as well yes i could be  good to have that sure sure good point yes   okay any any more question  on this uh user story guys okay i don't see any uh but it seems like uh you  we still have some open question for business   yeah i agree yes so is it a good idea for  you to go check with them and maybe we can   once you have more clarity around it we can take  this up the next refinement yeah fair enough yes   yes i i'll uh just get uh some more clarity on  this uh based on the layer of security because   that is definitely gonna impact the estimates  and the level of complexity i do understand   so i'll just get the uh clarity on this and i  will uh get back on this so okay yeah yeah that   works okay thanks thank you maybe in that case we  can move on to the next user story sure so uh the   next one says as a regular fintech app user i want  to deposit a check on my bank account using the   fintech mobile app so that i can deposit my money  quickly and avoid theft while running to the bank   so there's just a little bit of fun added to the  story but the thing is that uh we would like to   build this app where uh we uh when we click let's  say suppose when we click uh any picture of the   check from our mobile app uh then uh that amount  should get deposited in our bank account and um   so without cash actually basically but uh you are  actually depositing the cash through the cheque   uh so let's say suppose somebody has given you  a cheque so you are clicking a picture of that   in the through the app itself uh thus in the  in-store gallery images should will not work for   that so you have to click the uh image through the  app itself and then the money should be debited   from the person who has given you the check and  money should be credited in your account or vice   versa whoever is using the app uh fair enough  so i'll just go through the acceptance criteria   user can log into the mobile app user  can enter the desired amount to deposit   the picture needs to be clicked through  app of the checks uh the system processes   and validates the authenticity of the deposit  uh accounts are updated after the validations   within 24 hours uh email and inapp  confirmation of transactions are sent so any questions team anyone has any questions on that yeah  i see our own is having something so um regarding you know taking the pictures  of the check um i think we have existing   personality using another project we can  leverage that and we can try to use this   as part of the development um that is something  we can consider um that would be great yeah okay anyone else yeah priya okay so here  sorry same question for audrey again check no no for deposit we don't have any limit any  amount we can do that yeah yeah we can deposit yes   shall i add it uh yes yes but we should  have some bank limit right for that   okay i i will check this again and i'll  get back to you but once i discuss with   the stakeholders they went out of the  opinion because the amount is coming to   the bank so they were happy with it but i  will just go back and check once okay okay wait any more point guys one more question sorry your place for what about the license and all the about this  particular application how we will get the license   this is the third party application  or how it is uh the validation sorry different licensing uh you know external softwares  then there will be added cost to the company   that also need to be considered but for  now existing functionality we have to have   a research on that okay okay fine so  we can develop this kind of application   in-house as well right or do we  really require the third party or   one we need to research to understand like  how critical i mean how difficult it would   be uh based on that we can design we need  to understand the existing functionality   okay yeah we would like to go in-house for this  because if we involve the third party we will be   uh we will be paying the licensing cost  and uh you know our customer data we cannot   um uh like you know we cannot expose them to the  third party and said there are a lot of security   aspects which get into because we are dealing with  the crucial info so we would like to build this um   in-house yes okay so like i have seen the similar  application in other modules another business unit   so we can discuss it offline about that that  would be great yes that would be great yeah okay uh uh just a quick thought i'm just thinking  like building a in-house app may take a long time   and it may impact the deliverables that we have in  mind as per our pi planning right so uh the point   someone suggested like the third party app right  is it possible that we can do a quick spike to   just have a quick check how feasible that is  what are the security controls over there if   it matches to our requirements maybe it will  save us some time just a thought sounds good   uh let's do a spike first let's let's do the  poc kind of a thing and then maybe we can just   uh talk about uh what security issues  we are having if there are any so uh if   uh yeah like yeah we can go ahead with that  yeah i'm fine with it and this approach great   so i'll leave some volunteers here like who  who like who have some time and cut this sprint   uh to spend a few hours doing the spike uh i  can't do this oh great you need any helping hand   um not now but i will reach out okay and it  will not impact uh what whatever commitments are   given in current sprint right um yes it won't  it will not oh yes it won't it won't work   okay aaron uh so bye when now we can hear from  you uh fair enough so what i'll do i don't know   i'll set up a call or maybe between you and me  so the whole team is not required or just to   understand what the outcome from your spike and  once you decide whether to go with that approach   like in-house approach or taking the third-party  app i will again involve the complete team in next   refinement and we'll get back to this to it yeah  sure sure thanks thanks for taking that thank you yeah yeah i'll come to that yeah please uh if  you have any questions on this yes do we have any   time limit like uh banks won't allow deposit  objects after 2 3 pm right in regular banks so   how do we go with that in this scenario since  this is um app based and we are already having   a timeline of 24 hours for validations so  we are good with any time once the user   does it then maybe 24 hours we give the  bank to have the validations in place thank you thank you thank you for your question okay any more question on this another acceptance criteria that we have apart  from the one which you have taken first by okay i don't see any hand raise so uh   so kt maybe we can park it as of now  uh once we uh get the outcome from the   respect that arun is working we can take this  up later so let's do it then yeah thank you so just a sec there's a glitch yeah fma5 i'm just not able  to open it just a second yeah so okay so the next one is as a regular fintech app  user i want to create a new bank account using the   fintech mobile app the user can open the bank  open the app a user is promote prompted a list   of personal information questions the user can  submit the required documentation for validation   such as government issue id virtual video kyc  to take place in documents to be validated   email sms and in-app confirmation to be sent the  user can start using the app's banking feature   and start transacting so this is uh the  another uh user story what we have where   we would like to open a new bank account for  our customers through our app itself and they   don't need to visit the branch to have a new  bank account so um any questions team on this yeah i see neha is having a question here please  yeah so kitty uh to open an account is there any   minimum balance required to be maintained uh a  very good point so we would um like to start with   zero balance currently i'll just mention it but  once uh like you know three months period is there   then we can start having the minimum balance  so i'll just that add that in the user story   sure and one more point like how  the virtual video kyc would be done virtual uh okay so what what is going to happen  is uh once you are actually now if you'll see we   are during the covert time and everything we are  going all virtual right uh so people don't want to   uh go to place where it's crowded and uh any other  um functionality which we can give to get more   customer base this we are targeting more on the  video kyc where the once the account the documents   are submitted and it's validated uh there'll be a  video conferencing arranged with the bank personal   and the customer and they're the person who is  going to open the bank account the customer is   going to show the documents in the real time  in the video contouring conferencing itself   and that is that should be functional through  our app and not through any external uh zoom   to have the security in place so that is how  the goal and vision of this functionality is okay understood team do you have any  question regarding this virtual video kyc you can think around the risk  or dependency to implement this yeah how about you know the bank  account user is not available yeah so once the documents are submitted and  validated based on the uh slots of both bank   personnel and the user customer we gonna  arrange this call it should be a callback   and not just on the runtime once the user starts  creating the account so that is what we aim at okay what i think like we have to remove this  virtual video kyc from this current user story   because we are not clear like how we  will be doing the virtual kyby scene   okay so you mean to say in this  sprint we will not be able to do it or   we are technically currently facing  issues in not being able to do it like currently we are not able to do this and in  upcoming sprint we can take this maybe the show we   can confirm more on this point yeah it seems sorry  sorry no no no no no just do it i was just trying   to figure out what should be the work around so  that um instead of the virtual video what can we   do to make things life easier for the customer so  i just i'm also thinking on it yeah um you can go   ahead with your point yeah i just thinking like  this virtual video or it's kind of a new for the   like it may be the first time the team is going  to implement so uh if we're going to make it part   of this user story it's going to be too big or  may not be able to complete in a single sprint   um any any thoughts or anyone  i want to add on top of this yeah i think we can slice the story possible  uh so that we can uh have a less lesser   effort in terms of having only single story uh  wherein we can focus more on virtual kyc alone   and we can come up with the required uh technical  uh tasks that we can add and that we can work on   the virtual video currency yeah okay okay i was  just thinking yeah sorry yeah okay now in case   in case you are taking this out like what should  we do curiosity has a separate user story maybe   uh i know people uh that there's a center of  excellence team who already built something on the   similar lines maybe i can find a point of contact  uh you know get some training arranged in the   next print so that they can share their learnings  and we don't have to reinvent the wheel from this   branch sounds good sounds good you have to figure  out what is the workaround in case you are taking   this off okay i don't think this will be the  show stopper for us for now we can just go   ahead with actually onboarding the customers  and then having a physical kyc done for them   so okay i'll just change this user story for  now and um uh let's wait for the for your   uh session with the team so that we can progress  further on this maybe in the upcoming sprints   thank you thanks for accommodating uh i  see priya is also having a question here   april please go on youtube yeah okay you  have set the government id so is there any   specific government id they have to send it for  validation or any government id will be here   okay any government id voters card card card one  for the rest uh address proof for sure other card currently we are not catering that either passport  or aadhaar card is what we are planning to   uh voters id for id proof um we need  to currently we need to stick to that   then we'll see maybe if there are cases too many  cases then we can go ahead with um bank accounts   yes then so we have a specific choice at the  moment right let's go yeah correct correct so this this should be the standard  like what we are doing for all of   the banks currently we are doing so that  ways uh we can just go ahead with that okay thank you priya thank you and good  to have these two points clarified in   the acceptance criteria uh i see  shankar is also having a question   yeah uh so the either it is  going to be a video or physical   account creation is there any uh timeline  instant uh code activation will be done how it is   so in case of physical kyc it should not be the  case i mean we will not give the in video we could   have thought about doing it uh operational from  the next day itself but since this is now physical   i think i need to speak to my stakeholders what  should be the timeline we need to decide on okay okay but this open question  will not have any impact on   this user no currently i don't think uh  even if it is something which we need to   uh take on maybe we can take an upcoming sprint  so current sprint we can just go ahead with this   this added on validation maybe we can take  in the upcoming sprint correctly okay you're   almost on the mark of 10 minutes guys so any  more questions on this particular user story no sure no okay great then let's uh do a  quick first of five estimation for this   one on the count of three maybe you guys can  shoot all together okay yeah one two three eight i see eight eight five eight so most of  them are eight that is showing five right you   showed five yeah yeah maybe you are one of the  outliers so please explain yeah i thought if   yeah as this is uh normal if the if it is going  to be normal physical capacity we can go with five   if team is going with eight story  points we can go ahead with it   okay so your point fair point uh but yeah  anyone who has given it what do you think about   uh the thoughts that shankar is having  since it's manual kyc will it be five or anyone who can go when you can  now share the thoughts why it i think uh yeah may go ahead yeah  yeah please so i think yeah uh   so the use cases that are really needed  uh to be tested and also to be developed   here and also the testing efforts also could  be more because we need to ensure that the   existing regression impact is not there much  uh based on the new changes that we're doing so   i think considering that the efforts  are a little high towards that end right yeah i do agree so yeah  shankly are you fine with that   yeah yes okay then let's go ahead with  eight uh okay see if you can update   eight i'll open this one and uh we can move  to the next api and uh what i'll do is i'll   talk to the meanwhile i'll talk to the center  of excellence team i'll try to arrange the   call on that video implementation  really appreciate that shelby thank you okay so the next one says as a regular fintech  app user i want to contact customer care service   through my fintech app so that  my queries are resolved so so the acceptance criteria says that user can  log into the mobile app the user can click   and contact the customer care be it email call  or chat the user can talk to the customer care   executive for any concern service request  can also be raised from the app and there   is an email to document and validate the concern  so this is very important step uh team because   when the customer care actually  uh picks up the call and normally   there is no there's nothing documented  so the next time the customer calls back   they have to explain the entire scenario again  so we need to avoid that in our current app   so we want this to be documented on email as well  as in the in our app so any questions on this team   yeah i see lots of hands raised so yeah you can  go first sure yeah so kitty is there any timing   to contact the customer support through  calls no we are available 24 7 currently   so that's the plan that's that's what we are  we have discussed do you want me to add it in   the story so there'll be no timing validation you  can add here an acceptance criteria like okay okay folks yes yes thank you thank you okay you may go next so always the response time  is tracked here like how the issues are resolved   and how it will be tracked like any pre-loaded  questions will be like in case the customer is   reaching via chat uh or anything like that instead  of calls so always that track any preloaded   questions into the database or any questionnaires  that will be listed so that part i need to   process yes a very good point yeah so um we are  planning to have a basic set of questionnaires   for the app okay for the chat thing so that um  the users can actually get the answer readily   available and as an uh when we are getting  the questions uh recorded more and more in the   database we are going to add it but that is part  of the next feature upcoming feature so we are not   uh including it now the recording and the ai  part of it so we will be taking it up uh later   but currently this is what we are planning to  have okay so we can provide our service like any   feedback is there so if we are not convinced  with the solutions whatever is provided so   it will be like any form kind it will be available  for us to submit our service or anything like that   yeah so surveys will be taken but uh as i told  that currently we are just building on the mvp   so we are currently um because it will then exceed  mostly it will get become more and more complex so   we just want to have this one initial draft  of it so currently we are not catering that   so thank you a very good point yes thank  you so i will put that in user story that   currently surveys are not part of this you want me to add it i  call you good okay thank you okay well uh uh sashank you have anything yep  uh so i was just thinking uh like how we have   ivr for most of the banks or the credit  card services that we have so are we also   planning to have any ibr service because uh  it will be easy for uh the customers to direct   through a certain procedure so that they can do  it by themselves instead of waiting for on-call   support you know right sometimes the on-call  support because of the bandwidth or the traffic   uh they take some time for a customer  service to attend to a customer so yeah that's the plan actually we really wanted  to have this in current sprint uh but do you   all think we can accommodate that as a team um  so ivr was definitely on the wish list of the   stakeholders as well as uh everybody involved  in the project and that is a definitely a goal   uh but uh do you all think we can accommodate  that if yes then i can just add it in the story i don't think so we can  accomplish for this particular ivr is again altogether a different ballgame right  yes yes we have certain uh statements or a certain   uh standard lines or a template that we need  to follow in every step there are n number of   uh sequences or flows that we have based on  the request of the customer yes i understand   that that is it that will be a kind of another  different story yes yes so we are trying to have   that feature later in the uh cycle yes you can  add that in the backlog yes thanks thank you maybe you can go yeah it just thought  uh like nowadays uh back some banks are   providing the written call facility  so won't it be an added advantage   uh yes so uh when we are calling the customer care  and let's say suppose they are busy or the line   is busy for more than three minutes then maybe a  callback can be arranged yes that's a good point right any any more questions from anyone though uh i just thought like though even they're  not just for you uh team i think this story looks   straight forward uh but there are too many  things on to it do you think it's a good idea   if we can you know break down now it will be a  good approach if we can uh split into the task   yeah it will help you guys with estimation yeah  yeshank you have anything to add yeah that is   what so uh i think it will be easier for us to uh  do a better planning if we try to break down into   subtasks this user story so that uh because there  are too many items what one person cannot work   on the entire story so we need a collaboration  of team members here so i think it will be a   good approach if you can do we can add the  uh child now so we can get an idea or get a   vision as to how much effort yeah great great  point and i see uh so kitty maybe what we can do   now since the last story right that we have yeah  last time maybe i'll send the team in a breakout   room and they can just discuss among themselves  and break down the task for this industry and   then we can come back and then we can estimate  and see if there are any more questions or not cool i'm putting you guys into tricks uh so hey guys uh i hope you are all there i  think thanks for joining the breakout so yeah so   i'm just sharing my screen guys so let us take  a quick peek at the user story let's discuss in   detail and uh let us ask the subtasks there so we  know uh what are things that we can add right so   all right so this is these uh story that we have   and what do you guys think so what  what also tasks that can be added here it is regarding tracking the status  of the call log or any histories like   what time the call i have been received or  it has been dialed so that kind of uh stress   like providing the status details of the call   or if you have raising incidents i mean to  say service request uh how that is tracked yeah thanks uh yeah good yeah   the second one can be lock the call status we  can uh like lock the call status that we are okay uh thank you i don't know what  you'd like to do next uh yeah um   we can implement the resolve status for the  service request so that the status of the request good validation kind of thing we can include in us as  a sub task right because that would be required   whenever anybody is logging in in the application  they need the validation right particularly so what is it login login screen  validation you can put it okay login screen   i think login screen violation is already  happening as part of other stories as well   right so what do you want i think she's talking  about the user authentication yes yeah credential   verification either credential verification i'm  talking oh okay got it got it okay so can we say   verify user credentials that we can give user  credential verification like verified make sense if it is implement result status for  service request then we should have to have   cancelled requests for service requests as well  right yeah right that makes sense yeah yeah   thanks for being here number five uh i've been missing out anything  else guys so do let me know any other thoughts   that you that comes to your mind right now  would there be any feedback from the users uh   like there should be a feedback link or something  should be sent right would that be applicable yes but the fifth point says now the surveys  are currently not part of the easy story right so i think that will go into the other  table that we were discussing on the other day   so we'll just wait for the teaser story to  come so maybe we can add those information into   related to that table yeah cool thanks  again yeah what about the language   i mean if the user is of different language you  cannot speak english whatever how do how would   the call diverts anything about that regarding the  language i think we can get a confirmation from tt   uh is it any uh region specifically specific uh we  can you can make a note uh so once we go back to   the actual room from a backup breakout room let's  uh get that clarified with the keemthi uh i think   that we can add as uh the language preferences  i i let's let's get the ipad i think i think um hours or the estimates that you would like to  give yes so so how much time do you think it   will take for tracking the status list it can be  four or five hours okay sure let's give it five how about this one log because it is  six hours six is sufficient i think can you increase the an r yeah because the dependency also right  if the server is down or something like   take some time some kind of risk we may face  when we are validating the user's attentions   right make sense good points and how about  the last one days uh what do you think for   cancer uh i think it will not take much  time so four hours is sufficient for   half of the result status for service request  so cancellation will take half of them   okay cool make sense yeah so we are  just replicating using the same company is that call recordings are part of the story  that would be a different story i think that's   a different story sure yeah thanks so are we good  guys can we jump back to the room or you have any   other questions at one point or regarding the  language we will uh get clarified once we are   back to the room uh any questions i know we  are good we can go awesome yeah we are good   thanks guys so let's jump back to the room yeah  i hope you're waiting for us yeah let's go back hey hi guys welcome back so i hope you had  a good discussion yeah yeah yeah sure so we   had a good discussion there and let me quickly  share my screen again here in this room so we   will see we can show you what uh science to style  issues that we come across and go to your added   and we added these uh child issues that  is track bus data stylist is nothing but   the sub tasks so track the status uh which we  have given an estimate of close to five hours   and then log the call status which we have  to give an estimate for six hours based on   the dependencies the risks and challenges right  so based on all the factors that we have given   uh implement result status for service request  close to eight hours now uh and uh because we have   for the result status we have taken eight hours  we have just the cancellation status we are using   the similar components uh so we'll be taking half  of the time so we're saving time there and verify   user credentials comparative because it's uh it's  related to security so it takes some more time   uh it also depends on the server and other  impacted and other items as well right so   we have given 10 hours here yeah so i  hope this is good and with that i think   with this uh hourly estimates of these child  issues guys so uh so what do you think uh   yeah i think we can start estimating for this  story right in terms of yeah yeah yeah sure and   before that i'm just assuming that you guys  uh thought through all the risk dependencies   while giving the hourly estimates and creating  the task that's what i call a mature team okay   accuracy you have any questions uh with  the trust breakdown that your team has done yeah no no we are good actually yeah it's  a good breakup so we are good yeah okay   for the language oh yeah my  bad so yeah i had one question yeah so is there any uh common language like uh  english is fixed or like some other languages   also should be used right uh if somebody is  familiar with other regional languages it   should call should get diverted to that particular  language and all uh language localization is what   we are targeting at currently we will just  go ahead with english for now english and   hindi that's it but local local language is what  we are going to have in the upcoming features as   i suggested this is just the mvp so we need  to have the functionality in place first yes do you see any change in the  architecture or anything if we   uh have it in the later  cycle or we are good for now yeah localization is what is needed maybe but  in the upcoming sprint space any questions uh   before we make the first week starts allowing us  to start estimating from the story now shashank good conversation uh okay before we go to  the estimation for this story or just a quick   remind quick reminder uh for the task whatever  estimation your guys have given these those are   like effort estimation right and you remember  that story estimation factor the factor in   multiple things it's not just effort estimation  but as well as the risk dependencies and then   the complexity of the user story right so just  just keep that in mind because you guys just give   the effort estimation so i don't want you guys to  be confused and take think just about the efforts   okay uh with that being said let's uh  do a story submission for this one on   the count of three again show me  your first of five one two three okay i see a few are giving five if you are yeah  if you can go back a little it's eight right   okay eight eight eight eight  okay most of you are on eight so   i think we're good right but i'm  missing anyone everyone is eight priya you have not voted eight you are also right cool unanimous  decision this time i think uh the breakout   session helps time so uh since you are sharing  the screen maybe you can just update the boot okay great uh kitty what all the five stories  that we planned for today's refinement or is   there anything else that you want to discuss no no  we are done uh really good session team thank you   yeah good good so i'll just quickly  do a recap okay so out of uh   who was sharing or someone stopped sharing  maybe we can go back to the portable pc for uh shall we we didn't get you  you want uh the screen yes yes okay one minute wait wait wait um just a second yeah you want the stories backlog i'll  just do a quick recap and uh this will help   so as we discuss the first user story it's  good we have estimated story points and it   is good to take up in our next print or  if you decide that it's a higher priority   uh the next one uh fma you three uh there are  open questions for which kt is going back to   the business and that clarity and then maybe we  can take this up in our next refinement list yes   and the other one fmau4 uh so uh as uh we decided  that arun will do a quick spike on this one   and uh based on the outcome so irons had given  give us a commitment that uh he will be having   something uh some outcome by tomorrow so kt you  me and uh will catch up see what is the outcome   what is more feasible and then we can take this up  again in the next refinement along with the team   yeah sounds good uh then the next one the menu  five uh so we have already taken out one of the   acceptance criteria that is the video  implementation so we'll create a separate   user story for that and uh as discuss i'll talk to  the people from center of excellence team and find   a point of contact who can come and guide us and  help us with whatever they have implemented so far   and again that new user story we can uh discuss in  the next refinement if possible you can decide the   priority of that okay and yeah uh taking that out  or this user story the team has estimated at eight   points so this is again good to be taken up in uh  the coming of sprints and the last user story fma   u6 uh the task breakdown has already happened  though it looks uh quite uh quite a uh like   effort wise it's quite a big story uh but uh we'll  see in this during this planning whether it can   be taken up in a single sprint or not so anyone  want to add on top of it if i'm missing anything no shavik i think you have covered everything i think we are good with the current backlog  refinement and adding some more we made lots of   changes to the current acceptance criteria and  we we made created some spikes as well so this   will really help us for the next sprint planning  i think uh i think once we get the prioritization   from people during the next planning i think we  can we are already ready for the next items yeah   okay yeah our team i'll just discuss  with the stakeholders about all the   queries which i have noted down in  the comment section of every story   so i'll just get back uh by next  week or so with all the answers cool i think we are good then uh  thanks everyone thanks for your time   and one more point like sometimes what  happens is out of the meeting we have some   realization about this user story so if you  have any other point coming up in your mind   at a later point feel free to get in touch with  me or tc you can again have a connect right yeah sure thanks thanks everyone for your  time we had a great decision thank you   thank you everyone thanks everyone okay guys so welcome everyone uh in this second  session of our estimation uh masterclass last   week we have seen the basics of estimation and  uh this session is more on a hands-on thing   so we are going to present a kind of real  life scenario where we have a small team   they will obviously going to  goof off you will get lot of   learning like how to tackle the things  and all as a scrum master as a team   what sort of question you might ask to the scrum  master to the po and what is their own role and   responsibilities so all those things we try to  cover and we will try to be uh more interactive so   if you have any queries please put it your queries  in a comment section we will take it at the end of   the session please do not unmute if you are not  a team member so yeah this will be over to you thanks so let me quickly share my screen and   give the access to the scrum  master of the first use case so hope everyone is able to see my screen yes can you do f5 it will be good yeah   okay so first of all uh thanks everyone for taking  out your time so last week uh sunanda is already   given a quick intro of how we have handled  the last session so last session we   talked more about the estimation and how we are  going to estimate it and all the scenarios basic   concepts of the estimation so we thought as we  committed in the last session itself that we will   be doing a small role play uh just to understand  what are the real use cases that we will be facing   uh in the estimation activity so we have a small  team that got formed up uh to do this role play so   there will be two use cases for the role play  that what we are going to uh handle today and   i'm not going to talk about the use cases right  now let's let's ma you make it as a suspense till   we actually get into those use cases so the  first use case and i will request the scrum   master of the first use case to take the session  from there okay yeah good job to you please   hey hi everyone hope everyone is going good so  i'm working as scrum master and i have a happy   team actually okay we are going doing really good  so let's take up okay so as a facilitator uh i'm   just proving the story so this is the first use  case where we are coming up and we will be trying   to understand what are the requirements so we  can clear them and so if so once we have all   the understanding then it will be good to pull up  in the sprint as well so over to the product owner   yeah hi everyone so i'll be just walking you  through across the new requirement that we   have received from our stakeholder so if you in  case you have any question feel free to ask me   so the requirement is we have to develop a login  page for one of our e-commerce website okay   and it simply asks you for a username and  password where you have to enter username   password and there is a check box where if you  select a check box it sort of remember you and   your login so that your session will be stored in  the cookie and next time when you try to just come   to the website next time it will automatically  let you log in and the second functionality is   when you are not just checking that big box then  it will ask you to uh log in next time or whenever   you just browse next time to the website okay  and also uh some of the user-friendly messages   should be displayed on the ui uh if you are  entering some incorrect password or something so   this is the basic requirement that we have so  yeah so any question anytime just let me know   uh otherwise please let me know your input on this  when can we just uh deliver this to the end user   so the essence is like we need to understand the  risk factor of the story the dependencies which we   have the complexity then the amount of work as a  team which need to be done and the business value   so these are the few parameters which we will be  considering and then we can pull up so over to   the development team hi amit thanks punjab thanks  alet uh for letting us know about this requirement   i have a few queries like i can see that you are  able to explain us the functional requirement of   this uh story point so i would like to deep  dive on a non-functional requirement as well   that's the one the second things uh  which you have you know said that   as munyan was mentioning here that in terms of the  business values so if you can just uh let us know   what is the business priorities or a business  value around for this original story point   that would be my uh second questions uh could be  and the third things which i would like to know uh   moreover about this requirement is that um overall  is it a user story or is it moreover the epic   because uh uh like do we need to you know make a  assumptions the back end part ui part and other   stuff so if you can able to you know just give me  a clarity over it so these are the three questions   okay so i'll try to take up yeah thank you so  i'll try to take up your question one by one   so the first you asked about some non-functional  requirements so as of now we don't have any   non-functional requirement for this your  story second one you ask for the value of   priority of this user story so yeah this is quite  a valuable and i think this is on uh very much   on the priority because we want to make it live  till the next cell on our website goes on okay so   we are expecting that this to be released maybe  by uh the end of this sprint okay but in the next   release i'm going to say so this is of quite a  important uh requirement for our stakeholders okay   uh yeah i think okay and you ask about the epic  all right epic this is epic or is your user sorry   so in my opinion uh this is a user's story because  uh i don't see uh this is i mean on a broader   level okay so this can be handled maybe by the  development team so i think it's quite clear and   it can be easily handled by the team so i don't  think uh this is going to be epic on that bucket   thank you over to you sylvie if you have any  questions uh yeah uh rather than question amit   thanks you have put out all the questions one  question and one dependency i just want to raise   uh for this user story uh lalit the question  to you is like are we looking for any kind of   security aspects for uh to be implemented as part  of the story yeah so talking about security but   yeah we uh actually we don't want to compromise  on any of the security aspect of the website   so whatever you say let's say denial of surveys  or sports process scripting or brute force   i think it should handle all the security  aspects of the website okay thanks   and uh i just want to raise a dependency i think  both in our development team members sunam and   amit also will be in the same page we just need to  get the access and make the port enable for this   to be implemented so we just want your help on  that to resolve the dependency before we actually   get into the planning phase so if you make a note  of that and help us with that it will be great i   sure shall be i will be keeping it not and i will  check with the concern team as well okay hi guys yeah i have a one again query for example when  you mention incorrect password right so do we   have some uh sort of uh conditions for password  to be in correct and for example it should be   eight character long or should we have some  special character because nothing has been uh we   cannot make out anything from this uh requirement  so are we have those sorts of checks in place   and uh yeah and second thing which i want to  highlight as mentioned by shelby the port but   one more thing is regarding the firewall thing  i guess we need to open a couple of firewalls   so gunjan i think you need to work on that part  as well because in the past we have seen a couple   of issues with the firewall so this time we  should be more uh careful with that part yeah okay so i'll take up the first question  where you ask about the password criteria   valid password or invalid password so yeah  so it should be the password should be a   alphanumeric password and it must be a strong one  and it should allow your special characters and   one uppercase letter should be there okay so  this is the basic requirement of the password   to make a password valid if other than  that then it's an invalid password and   all the messages should be displayed i  mean the respective message should be   displayed on the ui okay can you add that in  uh acceptance criteria when we have a fully   uh functional user story in front of us yeah  sure listen yeah definitely i'll add just after   the call or maybe in 5-10 minutes after the call  i'll update you and let you know so i'm keeping   all the notes for all the requirements so once  the call is done i will be working with the bo sure okay thanks testing team do you feel like any sort of  dependencies we have or we need to come up   and we need to highlight it now so from testing game uh we need to know when  this the items will be finalized and when can   we start testing and we'll be getting the entire  access or user id password everything is set   uh this type of questions we have once the  things are done we will start testing from around so really what is what do you feel on this this was uh can you please come up  again i just missed the part so uh   from the testing end we are asking that when  this the items will be ready and when can we   start testing before we start testing we  should have the entire hand of details   where i can start and what is the expected  and how that needs to be worked uh okay   so i think this question is for the scrum master  and you are talking about when it is ready for   testing so mean the development should  be completed and testing should start   yes okay so maybe this question goes to the  development team who will be developing the story yeah just to answer on that uh lalith and prime uh  it is actually more like we are just refining the   user story right frame so we will be estimating  now and it again depends on the priority that   lalith has mentioned to us that it came from the  stakeholder and he explained about the priority   and again it's gunjan's call because he needs  to pick up the other items like capacity of us   and think about the other stuff before actually it  should be get into the planning mode so right now   we will try to uh understand the uh requirement  what lalit has shared to us and from development   team side we have shared the dependencies and  we don't have any further questions i think if   we are clear then over to you and for the further  steps okay okay so yeah i will be working on the   team capacity which we'll be having in the next  sprint and how many stories we we can pull up so   i feel like we are good with all the requirements  which we need to have up okay so yes okay so yeah   yeah please please okay i have very interesting  question uh someone just posted so though i really   don't want to take this right now but the question  is uh what what tester are doing right now   and why we are using the word testing team again  and again so you can see guys that this is a   typical anti-pattern we never use our tester or  developer in uh in normal uh agile way of working   we our work as a one dev team and whenever we are  going to do any sort of estimation we will give   as a team and estimation include everything  starting from scratch to whatever you are going   to put it into whatever whatever is mentioned  in your definition of done that should be part   of our estimation not only the dev or testing  effort it can be your documentation it can be   any multiple things so let's not get into that so  this is just to showcase like this is a typical   nd pattern which we should avoid okay yeah  thank you guys let's go to the estimation part   yeah so before estimating this is  the story i have two questions one is   what is the timeline for expiring that particular  user account and secondly how many browsers we are   targeting to complete this user story okay i think  that question is for me so i'll take this up so   talking about the expiry of the user so if a user  is not logging in to the website for 90 days then   it should be declared as a expired user and  number two about the browser it should uh   allow across all the browsers available in the  market whether it's opera or chrome mozilla   any browser you should support yeah so we should  know all the browser because this impact the or   our effort effort because if we are targeting one  browser then definitely it will take less time   but if we consider more browser then definitely  it would increase the effort that's why i asked   this question yeah thank you yeah all right  so team i just want to make one thing very   clear here that uh we want this to be released  in the next release okay because we can't afford   that this can wait for some more time  as we are targeting this for the next   cell of the season and we are expecting a lot of  transactions to be happening on our website so   please make sure that this goes live in the next  video so as a scrum master i i'm not sure again   we need to discuss within the team like how they  are going to handle it maybe it's a uh in we can   deliver in the same sprint or it's not possible  again so let's come to the team in that case so can we come on the effort like how  much effort team is uh willing to put   on this or are we able to achieve it in  the current sprint in the coming actually so from a developer point of view my equations  could be punjan because like uh we are you know   talking about to deliver into a next sprint  right until this we will we won't see the   complete backlog it is a very difficult for us so  what we can do is that we can estimate this user   story point as of now and once we'll uh progress  little you know ahead and once we have a clarity   that what are all things are coming into the nexus  sprint then along with uh this we can you know   bucket is that is it really doable as a complete  set one at a time or can we you know break this   into a some smaller subset and deliver it happy  with other developers you know viewpoint as well i am fine with the suggestion namit okay so let's do the estimations and then we can  see what is the team capacity for the next print   and how many story points uh we need to achieve  or we we can achieve in the comment sprint okay so let's i hope everyone is okay correct or  we need to have some sort of other requirement   discussion as well or we can go to the estimation  part yeah i think we can progress right here from   my side okay so we are going to use fit of five  okay so as i will be saying get set go everyone   is going to come up with some story points  so we are going to use a feminized series so get that go okay so just to count again  amit is with 80 story point   soon on this with five uh salvi is with eight  uh nathan is with five and prems against with   five okay so it's really good we have a different  story point so we can again come up why there is   a difference actually okay so let's start with  salvi actually yeah up to you yeah uh the story   i feel there are no much dependencies we have  identified those dependencies and we are pretty   much sure that uh it won't create a problem for  resolution before we start the actual planning   phase so i feel dependency wise we are pretty much  clear and we are unable to see any complexities   involved in that it's pretty much a very uh  clear story where we don't have any uncertainties   and we are not seeing any risk as well so the  amount of work side it is required that we are   fine with uh proceeding with this information  of one story point this is a call from my side ramit my thinking is quite  different what we have talked about it means that it is a login page and it could  be or you know as a landing page itself at a   home screen so the ui part is also very important  for a look and feel then the coding parts then the   authentication part and the back end where the  you know passwords will get stored or the token   will get stored so i think at a surface level  whatever it looks like beneath it there is a lot   of the work which you need to do but so hence  that with that considerations i think so that   it is a large chunk of the work in terms of  the complexity and you know other components   which we need to develop into hence i uh  you know i stay with my 80 story point okay and what about paim sagar you also said  eight points uh i came up with five okay sorry   okay so so yeah so yeah the thing is as  uh i'm adding two points with this lv   she told that it's not complex and now it's not  having any dependency so once the things are   finalized it will be very easy for us to test  and share our uh results that's the only thing   i'm just posting up it's it's nothing uh  complex work for us since it's an existing   one we can make it as soon as possible from our  end okay so uh salvi the the point which amit has   come up with so what do you suggest on that  what is your viewpoint yeah i just want to   revisit on my on the story points whatever i  have shared punjan first of all thanks amit uh   because you clarified so many technical details  to me which actually i have not thought about   because i was thinking for the complexity and  there is no non-functional requirement it should   be very simple but after listening to amit i  got some different overview so i just want to   re-estimate on the statement whatever i have  made and i am with eight story points now okay   good actually so we so we are to a uh final point  i think i think everyone is good with that good okay so coming back to the requirements like  what are the dependents which we have like the   security exp access and the service ticket okay  the security code which we need to do so i will   be working with the po and we will be creating a  story which will be again a zero point story and   uh i will be asking the team to create some sub  tasks and i will be working with the network team   to come up with the challenges so once the that  is being done then ideally we can pull the stories   also in the next sprint as per the requirement or  the the current velocity which we will be using okay so are you going to do the rebooting or   yeah so yeah again like let's do  the rebooting okay so now get set go so looks like we looks like  we have a happy team actually   thank you guys thank you so i think we are  done uh so pro from the product owner side   do you have anything uh no it's good to  see that we have agreed on our estimation   and i'll be happy when i'll see this live and our  stakeholders get the happy faces and definitely   yeah okay great yeah thank you thank you  i think we are done for the first story   okay so let's quickly check some of the questions   uh before uh moving to the question uh shall  we conclude on whatever we learn from these yes   yes so uh as we have seen this first use case  you all would have seen we have made this uh   words like testers effort were not considered  as part of estimation this is the same question   even sunand also was picking from our chat because  always there is one team that is development team   for whom the whole effort should be considered  and there should not be any category like testers   developers this is what we want to first of all  make it a kind of role play just to share the   information that there is no concept of separating  the team members in the category of development in   the category of testing it should be everyone's  effort should be considered so few things   a few anti-patterns also which had occurred one  is this and another one is like uh there are some   questions we were putting related to the  priority and timeline related information   actually uh other than scrum master no  one can actually plan for the sprint and   without the capacity we cannot come up with the  things that what we will be able to deliver for   that particular sprint so the priority can be  set by the pvo but again after the refinement   the stories will be in the refined state  with estimation values in the backlog   and once the sprint planning day comes scrum  master will will be already having uh the   capacity plan for that particular sprint for the  particular team and they will be able to pick   up the first set of priority items what has been  said by the po and push it to the sprint backlog   so until and unless these many activities are  not then maybe pvo always has a priority set for   their backlog item but it is again depends on all  these factors whether you have the team with that   much of capacity whether it is completely  refined whether all the dependencies now   in this team for example we have raised a couple  of dependencies and already the scrum master has   told that the dependencies will be created in the  current sprint backlog as a placeholder item which   is a user story of zero story points and the  relevant tasks whatever the tickets that he or   she will be working will be taken care as part of  that story and which will be taken for closure so   until and unless all these things are not taken  care we cannot actually think of picking up that   user story in the upcoming sprint so these are the  things uh i just want to conclude from this story   uh from this use case whatever we have taken over  to you thank you yeah thank you you're good okay   let's move on to i think the second one and let's  only we'll uh take everything in the last i guess over to you nitin yeah hi guys meeting where is a technical depth so in this user story  we have to refactor our code uh in which we did   in the past few sprint so we have to refactor our  code with respect to search criteria so here in   this search criteria we have to change our logic  so that we can display our search wizard within   10 second time frame and we have to work on the  export thing so there is because in earlier sprint   developer did some work where they fixed the  particular issue with workaround so now we have   to refactor all the code so first we'll start with  search criteria so this is the overall user story   so basically is related to technical depth so our  uh view will explain more on this so what to do carry on yeah so thanks to then uh so hey team  uh before coming into this call uh together uh   it was not a you know a good time which we spent  along with a nickel because we had a lot of you   know discussions going on around that should we  take it as a spike or a technical date so here   i would like to give you the background all about  it so what has happened is that certainly uh when   our stakeholders complains about the performance  issues then the ops team uh deep dive into it   and they also you know uh generated some of the  logs and even invested it and they also found that   the loading of the pace is uh more than a you know  10 seconds it's approximately coming as a around   18 to 20 seconds around and that's why the pace  is lagging and uh whenever the data is getting   uploaded right it is taking uh too much of time  and in between of that the system is also you know timed out which which is not uh uh you know  as per the standard as per the standard it   should be around of the 25 second so all these uh  issues which they have highlighted it seems that   it's it's a you know giving uh uh through the  you know code if stabilizations as a root cause   so hence i want your approach or i want your view  on this without open mind that what could be the   issues how you would like to you know come up  with the solutions but on the time frame i am   very clear along with the pure or even i am  also you know in line with our po that by next   sprint this needs to be prioritized guys  this needs to be implemented so what do   you uh you know a team for your discussions  or just give me your suggestions yeah and uh   sorry team so sorry for interruption so before  uh understanding or this start discussion we   i have mentioned i want to mention few  point here so you have to measure this   story with respect to few points so funny one is  whether this user story is very defined or not you   have to measure in this way and second point  is acceptance criteria is proper there or not   and second the third point is what type of data  you require to start this work so you have to   measure or discuss on majorly on these three  points only so over to ud yeah please go ahead hey guys sorry i'm just a pressure just joined  this team recently can someone tell me what is   this lazy loading concept uh so uh why can't  this can be you know answered by one of the   you know developer the senior developer and uh  help you know our uh one of the new team members offline uh in detail and i'll be uh i'll  be asking you to work on this code as well   uh since you you will be getting some exposure  uh since we are in a uh call we have to   spend spend some time here with  the po and the other team members i can help actually it will take hardly a minute  maybe and then the stream sucker can take it on   the further note okay later on so the lazy loading  is some something like where the page is loading   for a lot of long time actually and the customer  has to wait so just to overcome uh with that issue   we are planning to get something else where the  loading will be late and taking less time and   it's not the waiting time where the customer is  just looking for the records to be showing up so guys is it okay like if uh scrub  master will explain me all these things   i was expecting my technical lead or  maybe my architect will explain me this i'm what we can do is that since uh with this  agenda we have to you know do the estimations   but like the overall this uh lazy loading is  uh something to do about you know you know uh   how the pace should start displaying the  contents and all so uh concerning the you know   the agenda and we are we have to do and arrive  at some kind of approach on a solution in this   time box can we take it offline uh soon and  i'm promising you if you are not getting a   sufficient you know satisfactory answer please  reach out to me i'll be um myself uh blocking us   some time with you and uh we'll explain to you  in a detail is that fine simon yeah thank you amit i have few questions because you explain  these points like we are doing the refactoring   on the search and the export but i i feel  there are certain analysis we need to do and we   won't be in a position to estimate it  because uh lazy loading concept because   now we have pagination how are we moving from  pagination to lazy loading whether our technical   current technical stack of the application will  it allow it to do and the next one is the exporter   data should happen within 25 seconds that's one  more ask that we have so right now we need to   get the logs from testing team and understand  what is the exact time that is taking i think   without analysis of all this information and  understanding what can be the best solution   i think it should not be taken as a technical  depth from our side why can't we pick it as a   spike and if you give some kind of guidance to me  and frame can also help me out with what can be   taken care from technical side in from development  side and i can give the spike outcome and then we   can proceed will that be a good option yeah  i'm fine with this options uh selfie but   like i would like to you know hear some of the  approach from a frame before we conclude this   because it seems so that currently we do not have  a very concise answer how to you know implement   this and what would be the best suitable method  to you know having these solutions on the ground   so let's hear from and then we will conclude it uh  shall we is that fine yeah that will really help   yeah okay now before we proceed i want to know  what is the existing system and how it is working   can testing team look on that and share their  inputs so that we can uh decide what can be done   okay so currently uh somewhere around 20 to  25 seconds waiting actually and you need to   and this is the time in which the data  is loading actually okay so ideally from   the customer point of view it's a long time and  they do not want this time to be a lot actually um then uh we'll be looking in decoder and we'll  see how this can be moved to a separate module or   i will be doing some sort of analysis then uh  what can be done uh we'll be designing it is that   fine for you sylvie yes yes that will really help  yeah we can pick it as a spike and we can do all   this analysis and i will definitely take some  support from gunjan for taking out these open   points whatever we have because he will be able to  support from the current staging environment which   is mimic of the production environment whatever  we have so we can pull out the logs from there i will also you know uh second my developer  because the kind of the technical analysis   which needs to be available which we do not have  newton so i think we should be considerate about   you know spike this i have told you offline also  but since you are you know you are pushing to take   it as a technical depth and i promise that we will  hear back from the developer viewpoint before we   conclude and uh it seems so uh moreover we as  a team we are finding it to take it as a spike   so that we can do some kind of the experiment and  analysis and then we can proceed ahead hope uh   if that approach will find fine to you  ni then yeah definitely because if we   are means requirement is not very much clear  so we have to work on this user story or epic   so we have to finalize what type of requirement  we need to cover all the acceptance criteria   so definitely yes as you mentioned we have to  work together and mean provide all the detail to   development team or to you so so on the basis of  those information we will finalize the acceptance   criteria so currently this is not a workable user  story so we'll move next to the story here thanks   nathan for understanding it over to you thank you  thanks yeah so what's the duration of this fight what will be the duration of this spike  this from master would like to take as a you know look at you yeah go ahead so being a you know uh scrum team what we have  followed uh sunanda in the past is that um we take   uh as a spike of two days uh in one sprint this  is what a wall of reference or you know in a past   this is the one of the  pattern which we have followed okay so we'll spend two days on this particular  requirement and then we come up with some   solution solution a solution b and then we are  going to present that solution to our business   stakeholder and then they will choose and based  on that we will create our user story right   yeah right so have before starting work  on this user story we have to finalize   the prerequisite work so once it's done  we'll finalize acceptance criteria for this okay so any question thought on  this so basically this is not a   user story is more like a spike right right yeah  that's what we are concluding in the last okay yes okay so we want to conclude this yeah so uh  thanks everyone so uh the team that converted   initially with the use case here what we wanted  to demonstrate is uh the technical team they have   seen some kind of issues coming up quite often  from the production and they want to refactor   that particular area like search and export to  enhance the productivity and they don't want to   get into a trouble from the production system so  already uh what testing team is doing they are   trying to mimic a similar environment and creating  locks when the issues are coming so already the   architect has gone through some level of analysis  and trying to come up with certain uh solutions   that can be implemented but the catch is a team  is not much aware of the analysis yet and still   there are there is some more analysis which is  pending like what is the current uh thing that   is being used in the display of results area is  the pagination concept where first time there will   be 10 records which will be displayed and when you  click on the next page it will be going on but now   there is an ask like why can't we implement lazy  loading concept so like a fresher like a person   who joined in the team that sunam has talked about  a pressure so that person has no much idea still   and what is why we are doing that concept and what  what is existing and what why we are first of all   selecting lazy loading why can't other options so  these all things are still open so we have some   couple of options in our hand and we need to first  decide on what option we are going to pick it up   and we need to get certain questions answered  for the betterment of the analysis as well so   whenever there are some kind of options available  in your hand and you need to pick up from the   option and you are unable to decide on a fly and  you need some time to analyze and pick the option   you will always go for a spike so spikes will be  always with uncertainties and it will be always   in need of some clarification it will not have  a clarity where you will be able to estimate and   go for the implementation it will be something  like an open point where you will be unable to   estimate it because of the uncertainties it holds  so you will be just in a position to analyze it   and come with a spike outcome that's all so right  now here from pagination we have one concept of   lazy loading we may actually during the face  of doing the spike we may come up with one more   option which may fit better for the technology  stack whatever we hold so that will be also given   as a outcome at the end of the spike which will  be called as a spike outcome document which will   be shared to the team again and the stakeholders  and the business people and to explain them that   this is the analysis that we have done and with  the spike outcome whatever we have uh captured   the upcoming sprint or the future sprints we  will be creating one user story and we will try   to implement it with this kind of option what  we have came up with and one more catches the   spikes is not required always it should give some  positive outcome it can also be a negative outcome   like two options you have it is not necessary the  two options may work during the spike time you are   able to understand and see that both the options  have some flaws and you are unable to proceed with   both the fl both options still it's okay you have  a document you will attach the document as part   of this pipe and you will say that the spike is  done and we cannot pick up any user story further   to make this as an implementation item so that is  also possible so the key conclusion points from   here is when we need to pick up the spike when  we have uncertainties and when we cannot estimate   when we have lot of questions and when we are in  a position to decide on certain factors we will go   for a spike and as it has already uncertainties  we cannot be in a position to estimate it   so uh spikes generally it depends on the team  and the organization where you work you will   set a kind of reference that something like two  days you will spend for the spike because as it   has lot of open points and uncertainties we cannot  uh make it also open like with estimation we can   keep on working on the spike it cannot be that  way so we will fix it like two days you take the   time entire time come up with the conclusion if  two days whatever you are achieving that is the   spike outcome so we cannot expand extend  the time much more than the two days to   work on the spike okay so these are the things  we just wanted to come up with this part of use   case so spikes cannot be estimated because  of the uncertainties it holds okay thanks   to you and thank you so much team hey thanks  everyone so yeah thanks again sally to some   in a very nice way okay so uh let's see couple  of queries we have a lot of queries over here and   guys uh whatever you see right so we intentionally  go for couple of things we intentionally uh come   up with a lot of queries uh which is little bit  navy also now just to showcase you guys uh that   our intention over here is like how you can  handle in this kind of scenario if you're a   scrum master or team member what is your role and  responsibility so that's the intent because i can   see couple of remarks in our chat so the intention  is a little bit different over here yeah let's let   me quickly take a couple of queries if it makes  sense and we'll see we can answer them okay so i   think bala is joined from outside uh he's asking  uh nfr's team also can contribute yes it's not   sole responsibility of you of course anyone can  contribute a non-functional requirement because if   you are as a working as a developer or i mean any  other team member you are working more closely to   the through the code or to the functionality right  so it's everyone contribution is not only the po   or the architect is the one who it can be from  anyone right but yeah it's always good to go and   check with the business like okay this is what we  have identified do you want this to be included in   uh whatever the requirement which you have given  to us right because maybe their priorities might   be different uh yeah there are the set of the  the perception which they have with respect to   that requirement might be different so it's always  good to come up with the this sort of discoveries   yeah anyone wants to write anything sell in this  the question is nfr team also can contribute it's   not sole responsibility of you yeah yeah sorry  to interrupt you i have a small thing about   this yeah can you put your name yeah naveen you  know and your webcam is not there yeah yeah sure so basically enough for there are there are  two ways to deal right so first of all it   can be added in the product backlog either  way it can be added in the dvd as well right see again it's uh depend uh what nfr we are  talking about okay so maybe if something for   example uh again again it varies from team to  team in project to project for example i have   some kind of requirement just take an example  from this that all my uh report should run   within let's say 10 second of time or the web  page refresh should be let's say three seconds   okay if we are working on some webpage right so  it's going to be applicable for everything right   within the whatever the same similar kind of user  story we are going to pick so obviously it will   be part of definition of done but it's something  very peculiar very specific right then it has to   be mentioned in your user store yeah sure thank  you okay okay so let's go to the second query   uh creating you user to access this page is part  of this story question one uh manoj what is this query creating user to access this page is part of  this story yes no i think nathan has given us no   yeah so this is just an example uh there might be  n number of things you know which we might have   missed in this particular scenario right so yeah  there are n number of question which we should ask   uh the idea is like ask some questions which you  feel really make with relevant to this particular   user story or the requirement which is given  to you so as many questions as possible to your   po verify never go with any assumption that  this will be there or this might will happen   because i have done something similar in the  past so it will be there do not assume any   things clarify always rephrase your uh  understanding always right never assume   anything if there is something in your hear just  speak out do not assume anything okay everything   should be written over there in the user story  okay it should be that's what never be in doubt um i think the user and the password might  have created already before another story   yeah we have no idea whether  that's the case or not but   yes it's a actually so as for my  understanding he wanted to ask me from where we can create the user so this  should be a separate story or under this   user story we have to cover this scenario so  user creation thing is uh included in this story   or not that's right so i think we have missed this  important question i think we all have missed this so it's not me and you you can answer right  it's a pure responsibility he will chip in and   he will clarify all these doubts right so so you you want me to clarify yeah no  that's okay that's okay we're just kidding   nothing else yeah so uh so the questions are right   it's just like the the idea is like to whom  we should approach with this kind of questions   and the intent is like okay po should be there  he should be in right position to tell you   and this is like very common sense it makes  sense right so if someone has missed something   please highlight that's the idea please highlight  because maybe don't feel like you are a fresher   or junior or you know because might be those 10  people are busy with other different things right   maybe this thing's a small thing but it might  slip or maybe they know that it's already there   but that not to be the case right so always good  to go and verify okay what is whatever is there   okay interesting and most asked question  what will tester do when develop is going on   yes can someone help me with this i can help  on this so when the story is created by the   product owner so development testing thing  is going to create the test cases actually so   it will be in the any sort of testing tool like uh  test link or any other sort and they are going to   create the automation scripts as well okay  so the script will be prepared the uh the   requirement will be scattered by them it will be  written in the test trail so once the story is   already there and the development task is  done then they can pull the data they can   understand and they can run it they can test it  and again we already have prepared the the the   blueprint of those test cases in the automation  so we can just implement it over there actually   okay anyone wants to add anything selfie  or anyone else good thanks luncheon yes   so generally once the sprint starts the first two  to three days the developers will be very busy   with their design and uh starting the work in the  development but that time testers will be actually   concentrating on the test cases as gunjan rightly  mentioned so the test cases will be shared for the   review for example test cases will be written  against the acceptance criteria what pivo has   shared in the user story so acceptance criteria  will say what is the need of that what is the   confirmation part that i am expecting from that  user story it it won't say how you will be testing   what is the test set you need to have what will be  the test data you need to prepare there won't be   any other information so now it is tester's call  to come up with all those use cases create the   happy path scenarios and the negative use cases  everything and come up with the test case set and   share the test cases for the review for the entire  team so that while preparing the code some of   the test cases also will be taken care by the uh  developers during the course of their development   so that we are covering it is like a kind of like  review is also a part of static testing right so   it will be also helpful in the way that you when  you are reviewing you will automatically get some   kind of use cases which are going to be helping  you in your development also so once after that   there are there is a very good practice that what  most of the uh scrum team should follow is you   should get some intermediate build you should  share your intermediate build and you can also   share your design part like it's not necessary  you will have all the things ready and call your   tester hey like this is the build you do testing  no you can also share whatever the bits and pieces   that you are doing because this person is also  part of your team and you can also take his or   her support during the course of your development  phase so you can very well uh share your design   this is what i'm preparing so that they will  have an early offline review and say like hey   i think there is a loophole on this maybe  this will fail in this particular scenario   are you covering up this use case so like  that you will get some kind of comments and   some kind of suggestions from your tester and this  intermediate build concept is really a good one   because you no need to push your entire things  getting delivered on the eighth or ninth day   of the sprint and then getting the feedback it  is always good that bits and pieces you should   start sharing if you have a apa ready please give  that information whatever the uh parameters they   need to pass and all those information so that  they will be able to do a quick check with the   postman and say like how it is working and  when you are having the layout of the screen   just show it to them that this is what i am  going to say then they will say like for example   there is a mandatory field that needs to be  checked and then you need to enable the button   those things and all they will be able to capture  and give it to you the heads up in a very early   stage rather than giving it the end so it is all  about the best practices that a team should hold   so that you will be able to effectively use  everyone's time in their team yeah okay thanks   help me for this little explanation okay so now  next query is what do you mean by one story point   in terms of size time complexity uncertainty  or including everything bala right so what do you think about  this tell us your process first   yes actually i was i have gone  through the previous recording also   so yeah it includes everything so uh if you are  telling one story point means yeah it it includes   maybe a simple one to implement in terms of  complexity so to answer this this again this one   story points uh varies from team to team my one is  40 point they're going to equal to your one story   point maybe for me one story point effort i'm  just mentioning the term effort i'm not going into   infant for the complexity or uncertainty but yeah  we or everyone should have their wall of reference   and when i say wall of reference um it's hard  for me to explain everything over here but   when we say wall of reference it consists  of all these things it should be like a   reference where you can go and check that this  particular uh user story lies between which   story points and all so to short answer is like  one is story b cannot be you cannot say that is   one straight point equal to eight hours one and  all all those things it varies from team to team   individual project to project so and you have  already sum up that it's one story point not   equal to effort as many of the people still  feel that one is totally point or equal to   eight that's absolutely wrong so story point  consists of as you mentioned about the size   time complexity dependencies risk all those things  should be factored in into story point yeah my   doubt is like so when we are giving that number so  are we going to get clarity on okay uh one story   point means in terms of complexities less or in  terms of dependency it is more are we going to   also discuss those factors uh uh coming up with  that final story so if we have some doubt so   for example the pressure maybe i'm not used to all  those terminology because these people are already   the way we done the role right so the  good thing is might be someone might be   show me that just check this wall of reference  here you can undergo that okay we have already   jotted down that okay login functionality it's  simple form for us as a team because we already   have gone through so many times in the past so  for us maybe something will come something similar   it will be very easy it may be three story  point for us okay based on the complexity   the experience which we have the effort which  we are going to put right that is always there   the case that's the reason it's a wall of  reference you can always go back and check   if something is new is coming that  is entirely different you can always   um update that over the period of time it's not a  rigid document right so you got your answer hello   yes sir then one more thing is when we include  stakeholders in this meetings obviously they will   generally uh immediately jump into that question  okay uh how much time it may take so how to avoid   uh i know just know i think uh just now i think  salvia mentioned this in detail like uh right   so timelines uh we cannot commit on timelines  until unless uh the user storage has been defined   properly and based so how you will commit right if  you know that okay your half of the team will be   go on your diwali vacation or christmas vacation  right we cannot able to commit right until unless   you will as a scrum master will do your capacity  planning and team will do the commitment that yeah   let's take this as a spend goal for next print and  let's commit to this particular sprint goal right   then only you can say and go and tell  but yeah on a higher level based on your   past experience with your past velocity you can  just give some high level of understanding but   you cannot commit anything and that's the  reason it's estimation right yeah but here   i heard the product owner saying that okay i want  this after the sprint that's andy means two weeks intentionally that guy is asking i want this next  week so as a scrum master he or she should go and   tell product owner educate product owner mentor  project product owner that it should not be the   case so whatever you have seen is most more like  a anti-pattern sort of thing which we have played   intentionally uh as a scrum master you should  educate him or her that we cannot commit anything   just now in the refinement let's uh come up with  the planning session and maybe there only we can   give some kind of commitment right sure yeah if  it depends on the team's input if they couldn't   able to deliver at the end they can split  it into multiple stories right yeah yeah   thanks so is it possible to have an  orphan story not linked to any feature wow what is this question amir can you give  us some example what is orphan story i mean you there left yeah uh hi actually i was talking about sorry  yeah yeah sooner i actually in the first use case   uh there was a requirement for that login  but uh uh i wanted to understand was it   uh was there a feature for that or  it was just a plain story for that   so wanted to ask that is it possible  to have a like standalone stories so see there is uh nothing wrong in that like  we can have a stand alone stories but i am   not able to think of any uh there are i have  seen but i am not able to recall any specific   example but to answer that yes we can  have a stand alone but very very specific   not seen honestly but higher level obviously all  those user stories should be attached to some   feature or an epic or you know something like that  okay shall we you think of any example uh where   we have a stand alone user story uh even i am also  not getting any example as such uh but anyone else one thing i can only think of that by mistake  that the people would have you know forgotten   no nothing like buying something i'll i'll get  back to you on that okay so there are conditions   but then i'm not able to recall just on the fly  right now okay so it's kind of i mean mandatory   that a feature has to be there yes even if  you pull it in any tool it will ask for that   also okay yeah but you can have a story um  so if you go to uh jira or some somewhere   you can create a user story without any epic it  will allow you but ideally it should be part of okay uh summon right how about the reference user  story the point how about the scrum master having   a general agreement with the team about their  understanding of the one point story to reference what is this question we have discussed  this if there are no estimations summoned you there can you  explain this what is this question uh uh uh hi sana yeah actually i actually  joined in late um so i think uh with what   you've been explaining all through  i think you've actually done that   uh my thing was that because you said there is  actually someone in the team that is actually new   and they were actually kind of doing estimation so  i was like does the person have the clarity about   what they actually referencing the story in terms  of estimation too like if somebody is joining the   team and the way the estimation was going uh  everybody was estimating i was of the opinion so normally what i'll do when someone uh new  join my team uh obviously i'm going to give him   whatever uh the best practices which we are  using in our team and it can be anything   there are many like right but one of this is  uh this estimation part because that's most   uh complex thing honestly for someone who is  just joining new so he will sometimes be left   out and it's a very practical scenario because  he's not aware about what you guys are talking   and po is talking or and senior folks are talking  right and you can see right these people have just   shut me right uh so because i'm just a fashion  and they just told me like okay we'll take it   offline because these people already know but as a  fresher i am not aware about what these people are   talking about i mean it can be any requirement  right maybe for them it's pretty easy right   so uh if i'm if i'll be the scrum master i will  uh tell like day one or whenever we have this kd   session that this is our wall of reference this is  how we have come up with this one story point or   three story point and five story point spend some  time on that come up with your queries because   until unless you will be clear on that part you  will not going to give estimate right and if   someone has mentioned right that we are thinking  to give you that user story to work on now the   icing on cake is i am not even able to estimate  this user story and i have to work on that user   story right and then people are giving some kind  of commitment that is it is two story points or a   13 story point right but i am i'm not there right  so that's the thing so yeah it will be little   challenging in the beginning when new team members  are joining but that's where the role of scrum   also came into picture to help them guide them  um yeah mentor them in in the right direction okay okay so outcome of the spike  is only a documentation or   implementation of the requirement given there so the question is uh i think by bala i  think so bala silly already answered that   and uh on this like outcome of that spike is  only a document or implementation of requirement   given there so based on that output only we can  decide right whether we are going to implement   this requirement or not as mentioned by a selfie  right that it might be the situation that you   might have come up with two approaches but those  two are not feasible right so you are not going   to implement anything out of it doesn't mean that  your time is wasted you already implemented your   efforts your and you have learned something  out of it right so maybe this learning will be   useful for you in the future or any upcoming  projects or similar sort of projects right   this is like in in a ways kind of  investment which you have done on your team   all right so that's that's the  spike part okay i think we are done anyone has anything else can you hear me yes we can hear you  yeah yeah so i turn on my camera   yeah my question is like uh actually it was  everything is mentioned right so if i search   less than 10 seconds okay if you export it should  be better than uh second something like that   so you should do this this particular concept and  you need to do that code effecting so if that many   clarity is already required then how come  it can be categorized by generally if you   do spike then the outcome you can mention  okay i can be it can be feasible so fast to   disguise you to all of you okay i think you not  heard uh sylvie properly what she has mentioned uh   what she has mentioned is like you know uh these  people are still not clear on that part that lazy   part whether this will be the only approach or  they might have different more approaches okay   so that is not the clarity till now in this  requirement so they want to explore that thing   so the moment you have something to explore  the moment you will have something you know   to spend some time investment then we require  respect another important thing is sometimes i   have seen this entry pattern that people just take  that respect for two weeks or one week that should   not be the case okay otherwise there is no purpose  of spike as mentioned by sylvia right spike should   be short as the name suggests it's a spike so you  have a normal your spin and then a small spike and   this like this you have seen the heartbeat right  that's a small spike so spend some less amount of   your efforts maybe two hours or four hours or six  hours or eight hours it should be defined in your   definition of ready or wall of reference somewhere  that how much time you are going to spend and then   stop it hard stop whatever you have discovered  by that eight hours or 16 hours of efforts the   showcase to your stakeholder that this is the  outcome and because if we continue dragging   it then this not no longer be a spike right then  it's something which i think a technical architect   or you know someone has to deep dive into it  because for developer is spending two weeks in   one spike doesn't make sense then he's not doing  a development development actual development right   and we are doing our capacity planning for the  actual development not for this sort of thing   that is more on a ba part or a  po part or a architect part right okay i think uh this time we have finished on time  10 minutes more but yeah i think your own time   so i hope like you guys have learned something  new today i hope and yeah anyone want to share   anything or uh can i say something yeah please  sir go ahead okay yeah this is more or less like   a question i was actually talking with someone  is a scrum master too and he actually came up   with something and i've not to me though i've  not actually witnessed that before so i'm just   trying to like ask anybody here actually he said  in his team they have this warranty user story   so he said the warranty is the story is basically  if they actually did something and that thing is   actually deployed to production and um probably  they have like 30 days or 92 to 60 days they're   about and if there's anything within the  production uh after it's actually been deployed   so what it seemed actually does is  they actually get that fixed and   that's what they call warranty user story  and they don't estimate for it it's just uh   within their working agreement so  to me i've not had that before and   it's kind of new to me so i had the intention of  asking people who have actually probably got more   experience you can actually work with anything  like warranty is a story i've not heard it before i'm not sure whether i understood it uh  fully uh anyone can rephrase this for me   shall we or okay let me let me try and let me try  and be simpler yeah i said i had something from a   fellow scrum master yeah in his team they have  this user story they call warranty user story   warranty user story warranty user story yes okay  so he said what our warranty user story means is   that if they have anything deployed to production  you can actually work on any particular user story   and it's been released to production and during  30 to 60 days that has been released to production   if anything happened to it so they call that uh  they call that where they have a user story you   coming up with because warranty is a story and our  answer story they don't estimate it well to me i   believe if everything is released to production  probably there is a bug right you have to write   uh a you have to write something for it and it  has to be estimated and it has to uh kind of be   prioritized right but uh this is more or less  of an experienced scrum master telling me this   and i'm not okay i got your answer now uh i got a  sorry question okay let me answer this so uh simon   so uh i cannot comment what is your fellow uh  scrum master is telling you but i can tell from my   experience okay so when we are putting anything to  the production right yeah so uh i mean obviously   we can expect some kind of uh bug and obviously  those bugs should be of highest priority and cvit   because it may going to impact your production box  and it can do anything right so sometimes all the   stakeholders are jump at that time on to us and  we have to fix it right now what will happen to   our normal sprint which we already have planned  and which our team is already working on right   this is why i keep on telling uh to all my fellow  scrub masters that whenever we do our capacity   plan right first of all we will always pull a  user story may be 70 percent of the capacity or   60 of the capacity or 80 percent of the capacity  based on my experience of my team if my team is   relatively new i will just pull 60 or 70 percent  of the capacity uh user story so let's say even   though i'm able to finish 100 users points  right still i will just pull uh 60 or 70 not   not more than that and i will keep this buffer 20  or 30 for all these unforeseen kind of conditions   just forget about the normal list normally also we  will get some production incident here and there   and someone will pull us into that thing right or  maybe we have deployed something three months back   or six months back right and now something is uh  weird happened in the production right so we have   to fix that urgently right so that's the reason  if you you might have seen that when we prioritize   right we have something called must have should  have could have kind of rotation technique right   uh it can be anything like okay so the idea  is uh we will put let's say 60 to 70 percent   of must kind of user story into a given sprint  and then should have and then only could have   so could have is like good to have if we have  nothing production issues nothing like that   we can uh continue working with those user story  but if something like this will come up right uh   production issues or something then we have that  team member extra capacity with us and they can   start working on those production issues right  and i will also suggest we should also identify   in the beginning itself that if you already  know that okay something happened in the past   we should identify uh in our planning itself  that okay maybe one senior guy who already   have experience with this kind of thing and his  capacity will always be half or seventy percent   because most of the time the senior folk and that  is always there in all the teams right some some   senior guy will be there so his capacity always  take like 70 or 60 percent i would say because   most of the time either he's helping other  team members right that should be also counted   into his effort and then certainly something like  this happens some production incident will come   right so i cannot give that production incident  to some junior fellow who just joined to my   team right uh that guy should be able to handle  that kind of pressure right that urgency right he   should understand the functionality the technical  details and all those things right and i cannot   put all my team members into the production  incident at the same time right so we should   have all these things should be well planned in  in advance that okay something will happen this   is the senior folk who is going to pick this if  you require some kind of help yeah the other guy   the b person should rem whoever is working on  that user story he will park that and then he will   continue working with the other guy if required  right that sort of planning we should do uh in our   planning session yeah and that warranty thing is  uh again i mean nothing like is is obviously there   in all the software we have this warranty of 30  days or 60 days obviously we have to fix after   that that is not our problem that will be then  come under different altogether production support   you know bucket but if we are putting something  to the production yeah obviously it will come to   come back to us in next 30 days or 60 days it  again varies from company to company and team 2d   uh you got your answer sir thank you suna  yeah i got it thank you okay okay guys uh good okay thanks everyone and  i have a nice long weekend thank you thank you for the session  yeah yeah thank you very much okay okay thank you guys bye  bye thanks everyone thank you