Hello, and welcome to next lecture that is on priority queues and DQ that is double ended queue. So these are the learning outcomes. At end of this session, students will be able to explain priority queue and DQ queue in the data structure. So let us start with the priority queue. What does it mean by priority? So you know what is the meaning of a priority in general. So we have to give some priority at the sometime at the stage of the life. So in that, so we do the things which are more prior to the next thing. In the same manner, if you want to implement the priority queue in the data structure, there are some of the conditions we have to see. Let us see where the priority queue is first seen. So the priority queue are useful in the data structures in simulations, particularly for maintaining the sets of future events. Order by the time that we can quickly let you what are the next things to happen. They are called priority queues because they are enabled to retrieve the items, neither by the insertion time nor by a key match, but by which the item has highest priority of retrieval. So these are the priority queue operations supported. So we have seen the operations in the linear queue and the circular queue. So queue follows the first in first out linear data structure in which the items are added from the rare end and deleted from the front end. So where we do N queue and D queue operations. So while N queueing we see the overflow condition and for the D queue we can see the underflow condition. In the similar manner, the priority queue supports the following operations. First, that is an underflow conditions like this. So is an empty. If the function is empty called, it is used to check whether the queue has no elements. Means if you try to delete the element from the queue, when there are no elements, we have to see that that is an empty. Next, we are going to see that next operation that is insert with priority. Now the priority is given while inserting. Add an element to the queue with an associate priority. So there are two types of priority that is ascending and descending that we are going to see in next. So third operation is what the pull highest priority element means we are going to remove the elements from the queue which has the highest priority and returned it. We are not going to see that that is first in first out. For example, in the live scenario, if the person comes with a injured in a hospital, so the doctor has to attend it first based on the priority given to the injured person. Otherwise, he will be more injured if he is not attended on the priority basis. So the doctor stops all the things and attend to the injured person. So that is known as an priority queue. So that was the most live example while using an priority queue. So in the similar manner, the priority queues are used in the job scheduling in the CPU, CPU scheduling, all these things. So there are two types of priority queues. We are going to see that is an ascending priority queue and descending priority queue. So based on this, the highest priority element that is pull means we are going to remove the element from the queue that has an highest priority. So in ascending priority, we are going to remove the smallest element in the queue. That's why it is known as an ascending priority queue. In the same manner, if you are going to remove the largest element in the queue, that is we are going to dequeue operation. So that is known as an descending priority queue. So in short, we are going to see that the priority queue supports three operations. That is is empty, insert with priority and pull highest priority element. So these are the two types of priority that is ascending priority queue and descending priority queue. Now you tell me what are the advantages of priority queue? So it is easy to implement and process with the different priority can be efficiently handled. So now let us start with the double-ended dequeue. Dequeue is also a homogeneous list of elements in which the insertion and deletion operations are performed from both the ends. As in the normal linear queue and the circular queue, we have seen that the insertion and the deletions can be done from only one end. That is rare and the front end. But in double-ended dequeue, in which we are going to insert and delete operations are performed from both the ends. That we can insert the element from the rare end or the from the front end. Hence it is known as a double-ended queue and it is commonly referred as a double-ended queue. So now let us see the types of dequeue. As there are two types of dequeue that is input restricted dequeue and output restricted dequeue. As shown in this figure, the input, why it is known as an input restricted dequeue? As the insertion is allowed from one end that is a rare end and the deletions can be done from both the ends. That is from the front end as well as from the rare end. So that is why it is known as an input restricted dequeue. Now next that is the output restricted dequeue means what? So here the deletion is allowed only at once. That is from the rare end. So the insertion can be done from both the ends. So when you are going to delete the items from only one end that is known as an output restricted dequeue. When you are going to delete from both the ends that is known as an input restricted dequeue. Only the insertion can be allowed from the one end. So now based on the both insertion and deletions are performed from the either end it is necessary to design an algorithm to perform the following four operations. That is the insertion of an element at the rare end of the queue. The deletion of the element from the front end of the queue. Next is the insertion of an element from the front end of the queue. Deletion of an element from the rare end of the queue. That's what we have seen in the previous figure. That is insertion of the element can be done from the rare end and the deletion can be done from both the ends. That is the rare end front end. And the next is the insertion of the element is from the front end of the queue and the deletion can be done from both the ends. Either next the deletion can be done from the rare end of the queue and the insertion can be done from both the ends. So that is known as the double ended dequeue. So, now we will see one by one, what are the applications of an queue. So we have seen the live examples of an priority queue like in hospitals where the priority queue is used. So, in the same manner the queues are used in the various applications in the data structures such as in job scheduling, disk scheduling and the simulation. So when the resources is shared among the multiple consumer means what? So when the printer that is connected in the network that is a network printer it is called as a network printer means in a lab there are 40 to 50 machines are there and the printer is shared among all the 50 machines and the CPU scheduling or the disk scheduling is what? So whenever the persons are going to give the print from each and every machine of the in the lab so they have to do. So whenever the first print is going to come those are going to give the first print from the machine. So that is why it is known as an first in first out it makes and schedule of the printer from which the printer is going to take the numbers from where the print is going to come here. In the similar manner that is a job scheduling it is known as a multitasking. So whenever you are going to have more than one task going to do done in a computer applications so the CPU starts to do and scheduling of that here. So that is known as a job scheduling here. In the similar manner that is in real time simulations so for example the railway reservation counters. So as we see in the smaller cities the population is less where the reservation counters are very less means up to 5 to 6 reservation counters are there in Solapur city but as we move on to the metro cities like Pune, Mumbai so in where there are 30 to 40 reservation counters. So how they are going to build why they have built so many reservation counters here. So they calculate the arrival time of the person they calculate when the person is leaving from that place. So how much time is required to get the service from the user or the client. So based on this analysis that is done on the base on the queue only. So that is why if there are more number of queues and the person is getting more time to get the service then they increase the reservation counters at the railway reservation. It is same with your when you are going to remove the ticket in your cinema halls. So you have multiple reservation counters here. So based on that only it is known as a real time simulation. So that are the known as an application of an queue. So in short what we can say that when the resources are shared among the multiple consumers that is include the CPU scheduling, disk scheduling, job scheduling and the simulation. So in short what we have studied is that the linear queue which follows first in first out the same thing is followed in the priority queue also but there are some priority given to the data here. So while inserting the data can be inserted anyhow but when you are going to remove that it can be done from the smallest elements are being removed first and the largest elements are going to be removed first that is known as the priority queue. And in double ended queue we have seen that is the input restricted DQ and the output restricted DQ and we have seen the applications of an queue. So these are my references. Thank you.


Hi everyone, Sean with jaskiescasebrakes.com here doing 2020-2021 Panini Prison Basketball. One box, hobby break, three random teams each, number two.  So there you go. This is a one box break, everybody gets three random teams, ten spots total, so good luck. Here are those ten customers from Matt Lieber down to Michael Yamashita with last spot mojo times five. So thank you very much Michael for closing this out and good luck sir. And here are the teams from the Hawks down to the Wizards. Since every spot gets you three random teams, you need to copy this list and double it up or triple it up, sorry. So there's two and there's three. So you can see Michael's last spot mojo spots once, twice, and three times. Dice roll randomized both lists and pair them up. It's working. I did click it. Trying to do it, let's see. Alright, well that went through, so let's check it out. Thank you. Come on, machine. If it freezes like this, then I'll redo the dice roll. Give it another ten seconds. There it is. Three to five, eight times. We really thought about that one. So three to five, eight times. Good luck guys. Please don't do this for everything random roar. Yeah, let's try this again. One more time. Eighth and final time from Michael Yamashita down to Travis Melberg. So eight times on the randomizer, eight times on the dice, and eight times on the teams. Good luck guys. For sure, Joe. Eighth and final time, Washington Wizards. To the Pistons. Eight times on the teams. Eight times on the customers. Eight times on the dice. Negative. Let's make this bigger and go through it. Trade window is open. Michael Yamashita, Wizards, Miles Evans, Spurs. Michael Yamashita, Celtics and Heat. Michael Robinson, Kings. Brian Cow, Grizzlies, Travis Melberg, Mavericks. Michael Yamashita, 76ers, Cavaliers, Nuggets and Jazz. Matt Lieber with the Raptors. Michael Yamashita, Hawks. Matt Lieber, Knicks. Brian Cow, Rockets. Miles Evans, Pelicans. Michael Yamashita, Clippers. Travis Melberg, Magic. Michael Robinson, Lakers. Miles Evans, Bucks. Michael Yamashita, Sons. Brian Cow, Pacers. Michael Yamashita, Warriors. Michael Robinson, Blazers. Michael Yamashita, Nets. Matt Lieber, Thunder. Michael Yamashita, Hornets, Timberwolves, Bulls. You guys can also see who has what. There you go. So the trade window is open. I'm going to go grab myself a little glass of water real quick. Well, we're only seven months away from a free normal attack. 32 now. I'm getting anything over 35. It's a free pack. 35, someone's getting a free pack. That's what we love to see. You have the Baltimore Orioles and a free pack there. What's your name on it? The San Diego Padres. With the Padres here, we are looking for A. St. Kim Is the second one already loaded? Then yes, it is number one. I didn't realize that number two already got loaded. You are correct. This is number one. My apologies. This is three random team number one. You guys get to watch me. So for documentation purposes, I know. I know. One. Boom. There you go. Thank you, Tim. So now you have to see that. Thanks, man. Appreciate it. So not two. Number one. But trade window going once. Trade window going twice. Trade window going three times. Thanks, Chad. Much appreciated. But, that doesn't change which box we are doing. Which is this one right here. No trades. There is our full list. Love it, Chad. Love it. I didn't even realize that Nick had already posted the next one. For sure, Chad. For sure. There were only three spots left. CJ LB for the Blazers. And our first silver is JJ Berea for the Dallas Mavericks and Travis Melberg. You got a Kyrie Irving Red Wave for the Nets. Michael Yamashita. Good luck here. Desmond Bain for the Grizzlies. That is Brian Cowell and Skyler Maze for the Hawks. Yannis-Ansa Tecumfo for the Bucks and Miles Evans and Patti Mills Blue. That is 2199 for the San Antonio Spurs and Miles Evans. And to 25, it's a Mojo Auto. David Lee. Very nice. New York Knicks. Matt Lieber. I think he went to... Did he go to Florida? I remember he was like a crazy high flyer in Florida. Killian Hayes for the Pistons and James Johnson for the Timberwolves. Michael Yamashita. George Hill Red Wave for the Bucks. Miles Evans. Nice Chad. Nice. Tyler Bay for the Mavericks. You can choose. And Kemba Walker for the Celtics. Michael Yamashita. Davis for the Lakers. Michael Robinson. Udoka as a Buki for the Jazz. We've got a rookie Silver coming up. It's a good name. RJ Hampton. Denver Nuggets. And Michael Yamashita. And another nice rookie Sovon Lee Red Wave for the Detroit Pistons. And Travis Melbourne. Aaron Naesmith for the Celtics and Emmanuel Quickley for the Knicks. Matt Lieber. Carl Anthony Towns. And Jeff Green Red. That's $2.299 for the Houston Rockets and Brian Cowell. Steph Gury Flashback for the Wizards. Sorry, Warriors. Michael Yamashita. One of mine is seeing him on the Wizards. Him and Rui Hachimura pair it up. Please. So Mike 6 and 6. Make it only. Only. Yeah, Doc. He's got a couple in here. Okay, so first half in the books. Second half of the box is coming up. One auto to go. Typically, I remember correctly, just for future One Box Breaks, because this will all be from the same case. Typically, mojos, if you get into mojo auto, there's usually multiple mojos in that case. Like the case would typically be hot on those. So that David Lee, might not be the biggest name. He just had a 25 mojo auto. So we'll see what's in there for the rest of the One Box Breaks. 20 bucks a year. You got Terry Rozier for the Hornets and Michael Yamashita. And Doug McDermott-Redwave for the Pacers. And Brian Cow. You got Onyeka Akangu for the Hawks and Michael Yamashita and Sadiq Bey for the Pistons. And Travis Melbert. A couple stuck together here. And Rookie CJ LLB Red I think our auto is right behind that. That's 11 out of 2.99 for the Portland Trailblazers and Michael Robinson. And Rookie Desmond Bain Rookie signatures for the Memphis Grizzlies and Brian Cow. Isaac Coro for the Cavaliers Michael Yamashita and Tyrese Maxi for the 76ers. You got Ben Simmons for the 76ers Michael Yamashita and it's another Mojo. This one's Kawhi Leonard for the Clippers Michael Yamashita. That is 17 out of 25. Nice Kawhi. Elijah Hughes for the Jazz and Darius Basley for the Thunder Matt Lieber Magic Johnson-Redwave for the Lakers and Michael Robinson Kasha Stanley for the Pacers Markel Foltz for the Magic That is Travis Melberg and nice hyper Steph Curry widescreen for the Warriors Michael Yamashita Jason Tatum Retro for the Celtics Michael Yamashita James Weissman for the Golden State Warriors Michael Yamashita Purple Cracked Ice Eric Pascal for the Warriors and Josh Hart Purple Ice for the Pelicans and Miles Evans to finish us off. That was our 1 box break 3 random teams number 1 There is another 1 box break in the store now 10 spots 3 teams each That is it Let me pop over here 2020-2021 Panini Prison Basketball 1 box hobby break 2 random team 3 random team 3 random team 2 in the store now 3 random team Thanks for hanging out We'll see you next time


All right, good afternoon. Sorry you have to see my face again. A lot of people have been complaining, why is that you have so many sessions today? Unfortunately, when you organize conference and speakers drop out, you end up becoming the bakra who has to fill in all these lots. But I'm glad to see so many people interested in this topic. And I know that this topic is very interesting for a lot of people, like many people came up and said they're really looking forward to it. So if you're really looking for golden answers, I would like to set the context right now. You might not get those golden answers, right? What I'm going to give you is some techniques that I have found useful in working over the years in this approach. And maybe that will give you some food for thought that you can go back and start applying in your context. But please adapt to your context and try and see how it works in your context.  And I'll try and balance it with some of the concepts I cover and get you guys to do some things, right? So we'll be working in groups.  I would encourage if you guys can come in towards this side so it'll help other people who come in later to come into this session and people who want to run screaming, it's easier to go out. I didn't know what kind of an audience to expect, so I did have a little placeholder over there to really just touch upon user stories from my perspective what user stories are and then kind of start diving into various different techniques you can use at a high level to actually break large stories and then only focus on splitting as one of the techniques in which we will go and then we will talk about various different techniques within splitting of how you can split the stories, right? But there are other things you could do, not just splitting stories, you could do other techniques which we'll talk about. And then some high level stories in terms of a high level prioritization approach itself which helps you write better stories, right? So that's the agenda, one and a half hours, very ambitious. Last time I ran it, we overran by two hours, so we will see how we go, but let's see. We're gonna start with activity where I'm gonna quickly distribute example and I want you to form groups and in that groups you're gonna try and come up with stories, right? How many people here are familiar with the, as a I want to show that format? Hopefully by the time you leave this room, you should forget that format. You know who came up with that format? Mike Cohen, sorry, no, he's popular for taking other people's work and bringing it to people, which is good thing, but it was not him who came up with that format, sorry. So from what I know, I could be wrong, but from what I know, Rachel Davis was actually the person who put that format together and if you talk to Rachel Davis, she says I don't use that format anymore, right? How many people are familiar with the invest principle? All right, fantastic, that's good because then I don't have to go into some of those concepts. So what we'll do is if I can have a few volunteers, if you can just distribute this couple each table that would help. What this is is, this is a, if you can have one for each table and then we can work in groups, basically what this is is a casual data workflow and what I want you to do is take a stab at how you would write stories for this kind of a workflow. Try and, let's keep in mind the, as I want to show that format and let's follow the invest principle, right? Based on the stories that will come out, then we will decide if we want to go more deeper into the invest principle or go more fast forward into this, some of the slicing techniques, right? So each table at least has one flow chart. I think there were few people in your table who raised the hand, so that will help for you to work. At least there's one person on each table who understands invest principle, yes? No? Anyone in that table who understands invest principle, if someone from other table can join them, it will help them. All right, so basically what I want you to do is look at that workflow that's given to you and then work as a group and come up with a couple of stories in the format of as I want to show that and then keep the invest principle in mind, independent negotiable, valuable, estimatable, small and testable, right? Wow, I did go through that entire thing, nonstop. So we'll time box this to 10 minutes. So I want you to take a stab, 10 minutes to come up with stories you can write which adhere to the invest principle and I return in the format of as I want to show that, right? This is really a warm-up exercise. This is not what you're gonna be doing for the rest of the day. I can see a couple of chairs empty in the front if you guys wanna come in and sit. Yes, I only got 20 printouts because I thought people won't be interested in this. It's not visible at all on the board, on the projector. So basically casual data specifies a good match. The system finds matching profiles. Then the casual data views list of matching profile. Does the person want to refine it? Then goes back, refines the search. Else looks at the details of the profile and then if it is interested, then we'll proceed, else go back and then here you're basically entering an introduction and sending an introduction to the person and then you come back and the system would send introduction to the recipient and on the receipt before sending it would do a check to make sure that it's all valid and then would send it, right? That's kind of the workflow. I see some really smart people taking pictures of it and then using that, that's brilliant. You could start writing one or two stories at least get started, right? Good 10 minutes, yes. It's 10 minutes. So it doesn't matter. This is not a competition, right?  This is a warmup exercise. This is kids play. We're gonna go into a little serious work, right? So I want you, I want at least couple of teams to share their stories, right? That they have come up with. Which team wants to go first? Like share one or two stories. Can we have some mics please? As a casual data, I would like to specify a search criteria so that I get relevant matches. As a casual data, I would like to specify search criteria so that I get relevant matches. So I get relevant matches, okay? What do you guys feel? Is this a good story that adheres to the invest principle? No. No. Boom. All right, I want to make this a workshop, right? So I want you to please share why you think it's not. So just pass, let's have a quick conversation around this. I guess relevant matches is once again, it can be broken down for what kind of matches we are looking for. So you're saying that this is not small. Which is why you're saying this is not adhering to the invest principle, okay? We'll go there, yeah. Yeah, one more is like when you're doing a search, when you're giving a search criteria, it could be a lot of things. So at least something which is very small, like an MVP, we should say, okay, just enter place, age. Sorry to cut you, but you're saying it's not small? Yeah. Okay, fantastic. That's what I want to hear. Like basically it's not invest because I think it's not small. Testable. It's not testable. Why do you think it's not testable? Like it's very subjective. What needs to be- Define relevant matches. What needs to be tested is not clearly coming. But would you write all of that in a story? No, but at least what is that that is going to be tested? At least I should- Personally I think this is testable because we are saying I want to specify search criteria and I want to find matching. Now what matching means, I'm going to write in my acceptance criteria. So I think it's testable, but to their points it's not small enough. Any other thing? I'm looking for some different viewpoints. So it's not small enough, it's relative depending on what technology you're working and how you're doing things. Like if I'd build this in PHP, this is 15 minutes worth of work. So it's small enough for me. So it is technology relevant and which is why I'm saying it depends. But I'm looking for something else. Why I think this is not adhering to the invest principle. So you're saying that this is too technical. As a layman it does not help you understand what do you mean by search criteria. Again, personally speaking, I don't think we write stories for layman. We write stories for the team and we expect them to be up to certain speeds. So I think it's okay to have certain jargons which are specific to the context in which we are working. I think that's perfectly fine to have that. It's not estimatable. Tell me more about that. What could be your search criteria? But that's where your acceptance criteria would come in, right? So when you look at the acceptance criteria, I think that'll give you an idea of what all you're looking at. You might have things around how fast it should be. You might have things around what scale you should be operating and stuff like that as part of your acceptance criteria. This is not negotiatable. It's absolutely negotiatable because I could decide what amount of acceptance criteria I'm gonna take in. That's where the negotiation will happen. That's where as a team will work and define. It's good enough now for these acceptance criteria as we, sorry, these search criteria and as we evolve, we're gonna add more search criteria. The thing I wonder is valuable. Right, so I can search, I see a list, but what do I do with it? I'm trying to search for a match which is falls under a particular age range and particular location. And if I see the search result, that's enough for me to start with and if it doesn't meet my criteria, I can for sure refine that. So it is valuable. I would argue it's not valuable because I wouldn't go to a match.com just to see that there is matching lists, right? What is the objective? Why would you go there, right? What is the real value in part of the story? So if you deliver the story, it is not really deployable at this stage. Why not? You would deploy it. Why not? I see the search, right? That's the first part. You go step by step. Next is sending the request. You might want to deploy it together, but the way to develop it or the way to start it, at least you have to clear this step and go to the next step of sending the... That's an assumption we are making that you have to do this step before you go to the next step. Does it make sense? I mean, we are making the assumption that you have to exactly follow this to be able to do this, right? The only question I'm asking is, do you think it's valuable? If you think it's valuable, great. I don't think it's valuable because I wouldn't go to a match.com to only see a list of profiles, right? Or at least that's not the first story I would focus on for sure, right? But the story doesn't, I mean, it doesn't give me value by just looking at matching profiles. What will give me value is to be able to send an introduction, right? But you can't have it as only part of one story, like, based on the... We are trying to slice prematurely is what I think. We're trying to break it down prematurely. We're trying to focus too much on small and we're kind of leaving out the core value to later is my take. But that is the first story anyway, right? This is the first story. That's exactly what I'm saying. This is not the very first story. At least I would not do this as the first story. Now, we've made a whole bunch of assumptions that you have a massive database of users. So you don't even have a database at this stage, right? Yeah. The point I'm trying to make is think from a value point of view and then start breaking it down. Don't break it down prematurely. The second point I'm trying to make is, basically you might look at the workflow and you might say that this is exactly the workflow we should go in. And that's where I think a lot of slicing techniques will help you saying you don't need to go through the workflow. You could short-circuit the workflow because you wanna focus on value delivery early on and then come back and build some of these things. So that's kind of what I'm gonna go in a little bit later and talk about various different techniques where how we can short-circuit the process and focus on value. One of the team member in our group actually said like before even you can search, you need to feed the system your profile. Your profile alone to be able to find a match. You don't even have your profile and then how do you match a profile? You don't even have an account at this point. Yes. There's so many other things but I guess I was not clear saying tell me what is your first story. So basically I think that might be the confusion but certainly this is not the first step that you would do as a story and this is not what will add value. Again, let's not get caught up. This is just a warm-up exercise to get you thinking in the thought process that I want you to start thinking. Two things, focus on value. Don't prematurely slice things because you might find better ways of slicing. Second thing is, actually that's the thing. Don't prematurely slice because you might find better ways of slicing and focus on the value. Everybody's written from, so did you look at the different personas or is casual data the only thing in this entire thing? So is system a user? Like that's the typical challenge a lot of people have, right? When we write user stories, is system a user? Should I write stories from a system's point of view? Well that really depends on the framework that you're following. If you're following a BDD framework then you can't have systems as users, right? A slack is here, we could ask him. I don't think there's any hard and fast rules like that. But I don't know, I mean my question is that is the system is essentially what, if it was before the system existed there was someone manually doing that, right? Before the system existed someone was manually doing this matchmaking. Can we write the story from that person's perspective? So you can in a lot of cases take the system and look at 10 years ago how was this being done? There might be a Jyotish, a matchmaker or whoever who is essentially doing this and you could say that's what is being manifested as a system, we're basically automating what that person was doing. But when writing user stories you could still articulate from that person's point of view. So the second thing that I wanted to highlight is that it's important when we are writing stories to look at all the different personas that will be in this thing, right? What are the different, forget personas even if we just stick at different roles what are the different roles you would see in this? So we talked about the system or the matchmaker, right? Then we talked about the casual data who wants to send out invite, right? And then we have the recipient, right? There are bunch of stories that would come from a recipient's perspective. And then there is the perspective of the system, the person who's building the system because it's their reputation at stake if certain things go wrong which is why certain things have been put in place like the validations and things like that because it's the person running match.com's reputation. So at the minimum you have four and possibly another fifth persona which is the administrator or someone managing and cleaning up the profiles and things like that. So there are at least five personas and it's important to at least think about what are those five personas, how they interact with each other before we kind of jump into breaking down the stories, right? Cool. So everyone's nodding their head which means they don't understand what I'm saying. The famous format as I want to so that use with caution. The important thing that you need to remember is templates are useless but what the template try to achieve, the objective, the value behind it is kind of important. Like what do you want to hear is who needs this feature or this problem? Who has this problem? And what do they want to do? And how do you justify building this? How is it gonna benefit? What is the justification for building something like this? And that helps us writing the acceptance criteria, right? Because if I understand the justification for why I'm doing this, I'll be able to articulate the acceptance criteria better. Here's a quick example. Like Keen Reader subscribes to a blog would be the title of my story. As a Keen Reader of your blog, I want to subscribe to your blog so that I can stay up to date with new posts. Now this does not talk about any technology implementation. This is very much trying to talk about the problem that someone needs to stay up to date with new posts and it's in the context of a blog and someone who's a Keen Reader of your blog, right? Does this example make sense? All of you must have worked on some social networking side and uploaded your profile picture, but what's the reason we have that feature over there? If you were to write a story for something like that, how would you articulate? Whereas a social networking enthusiast, I want to upload my profile picture so that I can look at it and say, what a smart guy, right? No, you don't upload your profile picture so you can look at it and say, I'm a smart guy. You upload your profile picture so your friends can look and recognize you. This is one story. This could be sliced into smaller stories, but this is one story. This might not adhere to the invest principle, maybe because it's too large. But again, that depends on the technology, the framework you're using, right? Because some technology, some framework, this might be a trivial thing, and some framework, some technology, this might be a hard thing. So what is small is in the context of the team and the context of the technology that you're using. However, this focuses more on what is the value addition. Yes, please. Doesn't this become an epic then? If you're breaking down this particular user story into many, then this essentially becomes an epic, right? Maybe you call this as an epic, right? So you say that this is an epic, and then I'm gonna break this down into smaller stories. But an epic is also a story, right, in that sense. The point I'm gonna make a little later is that stories have an evolution. They start kind of pretty vague and ambiguous and they evolve over a period of time and they become more crystal clear, right? But they start out as a story. That's the image I wanted to show. So you start with business goals, user goals, you go through discovery, you come up with high level stories in a product backlog, right? We've seen this movie before.  That's kind of the evolution of the story. Now, you might have started with epics, those might have got broken down into stories and then when you get into the sprint level, they are iteration level, they might have got broken down into tasks. I think this only gives part of the picture. There's a lot more that is happening when we talk about planning, stories, backlog, all of that stuff. So I don't know if I'll be able to do justice to that, but let's talk about the slicing metaphor once, right? Where did the slicing metaphor come from? Why do we call it story slicing? And something of that sort, but slices from user interface may be a hypothetical example from user interface. But this is a metaphor. This is not real, right? This is a metaphor. And where did this metaphor come from? Cake slice, that's where it comes from. That metaphor actually comes from this delicious cake. Imagine I have this cake and I have eight guests and I want to divide this in eight guests. How would you slice this? That's what we talk. How would you slice this story? How would you slice this cake? Let's say we would vertically slice it because if you horizontally sliced it, some would get the cream, some would get something else, some would get something else and they would not really feel the cake, right? So that's one metaphor to keep in mind when we talk about slicing. That's where the slicing metaphor comes from. It's a reminder that you don't slice. What you were talking about is you don't give layers out to people because that's not valuable, right? There is another metaphor my friend Jeff Patton came up with which actually I like really a lot more than this metaphor is like I have $20. One way to distribute it to three people is to take it and cut it into three pieces, right? I have $20 with me, I have 20 rupees with me and I want to give it to three of my friends over here so I take a scissor and cut it into three parts and give it to them and everyone's laughing. Why? We've lost the value, right? So I think Jeff makes this point really well is that when you take something and one way to slice it is you don't think of the money metaphor, how you break down your money. You don't cut it, you basically try and go to smaller denominations, right? So that's another metaphor to use when we talk about slicing, right? So let's take an example and try to slice, right? So let's go back to the social networking enthusiast epic story. If I can club the two things together. And I want you to work in your groups and come up with how would you slice this story, right? Remember cake and the money, two metaphors, right? Quick five minutes time box. We're gonna work in our groups and come up with how we're gonna slice this story. Do you think we can slice this story further? Yes? Let's do it. This can be sliced into 16 different stories when I worked on a company which built this. So I'm giving you a hint. This breaks down into 16 stories. Let's imagine the social networking site that we are talking is Facebook, which has 16 million profiles uploaded every day. Just to put things in perspective. While I'm interested in the stories, I'm more interested in how did you go about slicing? Like what was the thought process you went through when you went about slicing this, right? That's really what is important. So talk about the stories that you have, the broken down stories, and what was the thought process? How did you go about slicing, right? What led you down that path? So which table has a mic already? We'll start with that table. So to start with, it involves with different options like first finding where to upload the image. So the first story is about clicking where you want to or how you want to start with uploading. So first story is that. Second is selecting your images. Let it be from local drive or your cloud account if the option is given. Third is validating the image. Like the given format, like JPG or whatever it is. So that's my validation. Next is preview. So you want to preview also the story which you have uploaded. And after preview, you might want to edit or crop it or work on that images. The next story can be about captioning that particular image. And the final is saving that. Okay. So yeah, publishing that particular image. So this can be part of uploading the image. All right. And what was the thought process behind how you went about breaking it down this way? I cannot precisely tell you what was the thought process. I cannot precisely tell you what was the thought process. Else I would not be required, right? Else I would not be required, right? So is it fair to say that I have experienced something similar? I use that as in my mind and I just went down and broke it down. Is that fair? Okay. Anyone else has a different approach they use than as a user I've used something like this. So I'm going to model my stories based on what I've used which is a perfectly fine way to do it. But is there any other way to do this? Okay. So what were your stories? How did you break it down? If it's more or less the same, then we are good. Okay. So you also have some cred operations on that like creating, updating, deleting. Is that an acceptance criteria or a story? Why is it a story? Wouldn't that be an acceptance criteria on one of the stories? That would be an acceptance criteria. That would be an acceptance criteria in my opinion. Let's come here and then we'll come there. So this story suddenly become like the entire social networking site. No, but that's after the profile picture, right? First you upload the profile picture and then you add the prints. So this is interesting, right? Do you have your friends first or do you have your profile first? Is there a golden answer? Probably not, but is these, what you're saying are these preconditions to the story? Or are they actually part of the story? No, but that is out of scope of the story, right? Because this was our epic, so. So these are preconditions for the story, right? So let's not try and bring that into the story because then every story will become the Facebook story. Right? Any other techniques you guys have used? I saw someone over there bringing it up. Could you please pass the mic to him? You're coming from the front. So the way we were looking at it was, so I'm posting this, and what do I get in return or what is the interaction I want to drive as a result of posting that? So looking from an interaction point of view. Right, and so one of them was receiving notifications when friends post their pictures, receiving updates when friends comment on it and receiving them via web or mobile platforms and the interaction, so more from an interaction perspective of okay, I've posted this, what do I get in return and how do I use it to interact with my friends because this is after all our social forum. I feel guilty because I think I've set you up for this, right? When I said there are 16 stories now, people have started thinking about what all possible things I can do, right? So I apologize for setting you up. I'm gonna talk about one specific technique that I find useful is basically using acceptance criteria as a way to slice the story, right? So let's talk about if I were to use acceptance criteria to slice the story, how would I go about this, right? So we can compare what we came up with. Acceptance criteria, just a placeholder given when then, given precondition when actor plus action, then observable result. So we'll start writing, you know, what are the acceptance criteria for this? So let's talk about the first one. Given that the user has a valid Facebook account and a digital picture on her computer, when she uploads her picture in Facebook, then her picture should be visible to all her friends in the network. That's my first acceptance criteria for this epic, if you will, or the story. Is that okay with everyone? Right? Let's look at what the next acceptance criteria for this would look like. Given that I am trying to find friends on Facebook, when I search for a person by their name, then their profile picture should be visible along with their name, right? Otherwise, the purpose of the story is not served. Yes? So it has now dependency on another story or another functionality, which is the search functionality. Make sense? Let's look at now trying to frame it as owner of Facebook. I want users to upload authentic profile pictures so that Facebook's reputation stays intact and they don't get into legal hassles, right? And of wrote the acceptance criteria in form of a story just to highlight how you could take acceptance criteria and start converting them into stories. I mean, so when you implement this story, you are running the risk of people I going uploading Amitabh Bachchan's picture and saying, I'm Amitabh Bachchan and creating the profile and then Amitabh Bachchan suing Facebook for that, right? So there are, you have to be careful about other dependent stories or when you introduce this feature, what else will, what would be the repercussions from it? And you wanna make sure that somewhere is captured, right? As a part of the acceptance criteria, sometimes it's not really a small acceptance criteria, it actually ends up becoming a story. So what I'm trying to highlight here as an example is I find it quite useful to use acceptance criteria as a way to slice my story, right? That's a technique, that's an approach you could use to slice your stories, right? Take the big thing and start breaking it down from the perspective of acceptance criteria. Yeah, cause like... But what is the story? We don't know what the story is, right? You can, if you put your name in Bachchan's photo, that is one story and if you put Bachchan's name in Bachchan's photo, that is another story. So coming back to your question, am I slicing the story or am I going all over the place? The point is that I don't know what the story is, right? I'm defining the acceptance criteria for the story and this, that's why it's a big story. It might look like a very trivial thing, but when you define the acceptance criteria, that's when you're defining the scope of the story. So you're using acceptance criteria to define the scope of the story and then you're saying, okay, this is too big because if I look at all these acceptance criteria, it's a humongous thing. I have to deal with so many different things. Now, we've not even talked about scalability. We've not even talked about redundancy and stuff like that, right? Those are all will become part of your acceptance criteria. If people start uploading five MB profile pictures, it's gonna bring down the entire network, right? So you're gonna look at aspects of those and then there might be, those might not be small stories or just acceptance criteria within the story, they end up becoming sub-stories within this, right? So that's one approach to start thinking about how to slice. Based on the acceptance criteria, I've defined the scope of this and then based on the scope, now that I understand, now I'm slicing it, right? So that's one technique, not always that only technique will work, but this is one of the techniques you could use in some context, right? Let's look at another example and see how we're gonna go about this. I've taken something very generic that everyone should be able to relate to is the roles and permissions administration, right? So let's look at this kind of a screen that I have. So I have different users and I have different permissions for each of those users. The pictures are not very visible. Can you reduce the lighting over here, please? So I have different roles and for each role I can decide what permissions they get, right? This is again a very simple story, but let's see how we go about slicing this, right? So how would you go slice this? So work again in small groups quickly, let's do this and then we'll do a recap. So I have different users over there on the left. I can add, delete, I can copy those. I can basically have different permissions for different levels for each role. So just so you understand a little bit more context, right? Let me quickly talk about this. What are things that you could do? Add a new role, delete an existing role, copy an existing role. You could update the permissions of a given role. You could search a role, right? This is more from a functionality point of view. These are the kind of things that you could do on that screen. Now from a technical point of view, you have, you also need to look at, there is a left pane and the right pane. There are two things that you have to work on. There is the client side search functionality, right? When you search for something, it filters. There's a client side search functionality. There's this tree structure for basically viewing the permissions. There is the crud service for the role and then there is the read and update service for the permissions, right? This is what this encompasses, all right? So having known that, now how would you slice this story? What approach or technique would you use to slice the story? Work in smaller groups and then let's discuss again, okay? So you're saying that you abstract out the technical portions and focus purely on the functional aspects. You'll get encapsulated, but do you need to think through your technical aspect when you slice? I feel a lot of waterfall-ish thinking, right? I don't want to collaborate with the technical side. I'm just gonna slice things in ether, right? Absolutely. It might be a bigger story. They might say this has a lot of other dependencies you've not decided, you've sliced it this way, but for this now I have to bend over my back to do this other thing, right? So I think what we're looking for is the collaboration, right? That's very important when you're slicing stories. Don't think that you need to go in ether and just start slicing your stories, because then it could lead to a lot of rework. It could lead to a lot of unwanted, you know, I guess tension between the product, owner product management and the technical side, right? So what I'm encouraging you to is keep a balance, because that's important. You don't want to keep doing rework. You don't want to slice your stories and then go back and say, well, this is not estimatable or this is technically too complicated. It's not possible, right? While don't let technology drive the slicing, there has to be a right balance, right? Which is why I brought the technical aspects into this in this particular thing is keep these things in mind when you're slicing, correct? That might be at the product discovery level, right? At a very high level, but when you're actually working at the story level, you don't do that at the beginning of your project, right? You don't write your stories at the beginning of your project. That's where you would write what my friend used here, the term epics, right? You might write those and at that stage, it's okay not to worry about those. There you're just capturing what is the business needs or the user's needs and kind of articulating them, right? But when you actually start looking at stories and especially slicing, why would you want to slice? Because you're working now at a much more lower levels in the entire plan, right? So at that point, hopefully you will have some. If you don't, then someone use the word spike, right? You might want to spike it out because I have no clue how to do the tree pan because we've never done something like that. And so we might want to spike that out because we don't know if it's one day worth of effort or one month worth of effort, right? I'm saying that not at the finer level, but I actually think at a much higher level that collaboration is important because a lot of times your thought process will shift in terms of how you even want to consider a functionality because your development, your engineering might come back and say, you know what, if it did this this way, you wouldn't have to do those three steps at all, right? So that can completely change how you see or slice the work or even sometimes how you consider the functionality implemented. So you were right in terms of technical is required at the lower level, but I'm saying you bring them up and do the collaboration much higher up, right? Don't leave it to the finer level because at that time majority of the decisions are already made. Yeah, I think that was precisely the reason why I never thought of involving the tech guys in here because to me, this is like a prototype. This is like a design document which has been given and all these technical things would have had been discussed already. No, someone might have done a low-fidelity prototype, just sketched it out and then done some user interaction testing. This would sketch, right? This would sketch and then they would do that, but then at that point, it is good to have the technical perspective because then you might decide to, you know, have a different kind of interaction altogether, right? Something that might be much easier. I actually gonna show in this particular example how we went about doing that. Correct, absolutely, right? That's where I was going. So just reiterate what you said. Your story should focus on what and why to add to that, right? What and why? Why the heck we are building this? And leave the how part to the implementation.  I think the thought process around how has to be there to slice it effectively. That's the point I'm trying to make, right? So let's look at this, how we went about slicing this. So the first thing we did was we basically said we're gonna do a read-only view of the roles and permission. Which is at least to start with, I can see what the roles and permissions are and maybe I could just go in the backend and update those permissions for now. But at least to start with, my first thing I want is to basically have, you know, a way to view this.  For now I just want an easy way to view, dump that information in a decent enough manner. And here I would be required to build a read service. I would be required to build a read service for roles and permissions. I need to display certain things in left and light panel. I need to figure those things out. So that's good enough. It's small, it's estimatable, it's testable. I know it's working. And that's a good enough first story for me or first part that I could deliver which would still deliver value. At least I can see what permissions are set for some users, right? Once we have done that, then maybe we want to provide the ability to update the permissions. We started with read only. Now we want to update permissions. And this is where we're gonna tackle two things. One is the tree structure. The second thing would be the update service for the permissions. And then we would go on and we'd say, okay, now I want to add new roles. So what I had first was view. Second I had was ability to edit or update. Now I'm saying I want an ability to add new roles. And then I would have want ability to delete and do other kinds of things in this thing. So maybe that's one way. I'm not saying this is the only way, but maybe this is one way you could slice it. Taking some of the technical aspects also into accounts such that it minimizes rework and still delivers a value and adheres to the invest principle. Small, invest small part has to take it into account. But just to make it small, you don't compromise on the value. So the invest thing is about balancing all of these things. And that's where you might need collaboration with the tech side to say how more effectively you could slice this such that it is still small and it's adding some value. For example, the product owner might not think about read only. That might be some suggestion that comes from the technical side. But that's where I think the collaboration comes. We should focus on collaboration not moving away from collaboration. Even when slicing stories. Hope not. I know there are some snake oil salesmen who are trying to put that together. Stay away. Yes, please. Because they were too small and the overheads of keeping them separate was too much. So you can combine things which are too small. It's not worth having two separate things. Which one, the client side search? Yeah, so basically it's something very trivial to implement and the development said that's gonna take maybe half an hour to do it. So do you want an overhead of creating a story for that managing the story going through the entire process which might take another half an hour. So to do half an hour's worth of work you're ending up doing half an hour. I'm not sure I understand your question.  But to your question though, we do end up combining things even though they might not be exactly related because the overheads of having them separate is just too much. So keep that in mind. Be pragmatic, don't get dogmatic about it, right? It has to help you not become a hindrance. Hang on one second, yeah. Can you just take the mic because it'll help others. Listen. Keep that separately. Is it not that how part coming into your mind? Correct, that's what I clarified earlier. The story itself will not have the how part but the thought process of writing the story would drive, would take into account the how part. Because the example you are giving now, you are going up to the estimation, you're saying that it takes two hours so I'll combine. This is something. It's not an estimate, it's basically the team saying this is so small, do you even want the overhead of creating another story and managing it? It's not really getting into tell me how many hours, how many seconds, how many minutes. It's more like this is just so trivial. I can do it in like no time. So let's just combine it like no point having the overhead. This could just be a task in one of the stories, right? All I'm saying is be pragmatic so that it's helpful, not becomes hindrance for you. So what does independent mean? Independent basically means it can be independently understood and executed. That is in a story. So a tester should do two kinds of tests. Basically, a tester should be aware that of the English story, I have to delete it. Okay, then you would break it into two separate stories but my tester said it's trivial and so we combined it. So again, it's contextual, take your people, that's where the collaboration will come in, right? Bring in the tester, take the tester's perspective. If they feel this is trivial, combine it. Otherwise it's overhead to manage it, right? Again, I'm just giving you examples. This is context specific. Depends on your tester, different on your team, right? So what slicing technique did we use here? In the example that you just saw? Is there a name for this technique? Did we use a specific technique? Can you generalize this and try and apply it in other contexts? One technique we saw earlier was using acceptance criteria to slice, right? Here did we use acceptance criteria? Not so much. We didn't think about acceptance criteria as much to slice this. We used something else. MVP is an overloaded term. I had a session in the morning. I said it's totally bastardized today. MVP, everything is MVP. This is not an MVP thought process. No, MVP is about validating your hypothesis. There is no validating hypothesis. I know I want to build this. There is nothing to validate here, right? So this is not MVP at all. Just because I slice based on effort does not mean it's an MVP is all I'm trying to say, right? But that is always the case, right? All your stories have to be demonstratable, have to be valuable. So that's always the case. User scenarios, did we go by user scenarios? Again, I'm saying technical angle should be taken always into account, not specific to this case. So if I were to talk about that, basically the approach I'm using here is sophistication. Over a period of time, I'm sophisticating what it can do. So I start with a bare bone thing and then I sophisticated over a period of time, right? The other way to think about this is devolution, right? Or reverse evolution. Take Excel and work backwards and say what is the bare minimum, what is the very basic stuff that I need and then gradually keep making it more sophisticated over a period of time, right? So that could be one thought process when you slice your stories. Is thinking about sophistication or thinking about devolution. They're slightly different, but that's kind of a theme. You could use those techniques. I just talked about an example. Yeah, like the admin screen, right? Is an example of... So the admin screen, we started with just a very bare bone read-only thing, right? So that's the very basic thing and over a period of time, you've kind of... So you looked at what you wanted to start with the fully sophisticated prototype and then you started working backwards saying, how do I degrade, how do I degrade, how do I gracefully degrade? So there's still some values delivered, but it's bare bone. It's bare bone, basically, right? So either sophistication is one way to think about it or devolution or reverse evolution is another way of thinking about it, right? A lot of times you ask yourself, how would people do this five years from ago, right? And then you say, okay, five years ago, people did this this way. So we start with saying, okay, at least we can start there and gradually make it more sophisticated, right? Let it be the user experience, let it be things like that. The user is not gonna define acceptance criteria at this level, right? Now you're taking an analogy of how if this feature, I'm looking at this fully finished prototype, this is how I would want, this is my final state. Now to build the entire thing is gonna take me a lot of time and it's not gonna be simple. So can I basically gracefully degrade the experience in some sense so that I can build the bare bone version and then gradually keep building on top of it, sophisticating it, right? Let's start with the nano, let's put leather seats, let's put a really good engine, let's keep building on top of it such that I have car from the get go. One of the classic problems people have with story slicing is that it's taking the car metaphor.  So you say, okay, how much budget do you have? And you say, I have five lakh rupees. Say, okay, for five lakh rupees I can give you an engine and I can give you a steering wheel, right? And seats and other things you can figure out. That's not how you slice things, right? Because you're not really delivering. You say, okay, for five lakh rupees I can give you this basic version of this car is not very sophisticated, but it does the job. It's still, you know, four people can sit and go from one point to another point. Does it have automatic transmission? No, it doesn't. Does it have a fridge? No, it doesn't, right? Those are sophistication. Those are things I can build later on. So think about that analogy. Yeah. So see, while we are like slicing the stories, see, this becomes very logical that as for the functionality we are slicing a story. We are going to bear minimum required thing. But many times what I have felt or the scenarios what comes up is that, okay, even within that small things, sometimes the different things like auto-taste automation is required or other small dependency, they add up so much effort into that.  Correct, good point. So there, story slicing is not the problem. You should stop focusing on story slicing and look at skill building of people. That's the bottleneck, not story slicing, right? You've already sliced the story, but then now automation is a challenge. Other things are challenged. You might have legacy code base and you have to deal with that. That might be a challenge, right? So slicing is not the remedy. Taking that pill is not going to do away with the problem you have. You need to focus on, you know, maybe putting the safety net, the engineering skills, upgrading the skills of the people. That is the problem there, not the story slicing. That's correct, but just the example what you took, let's say that we have the legacy code that we have to deal with. Sometimes we end up into creating a story that, okay, just deal with this legacy code becomes a one story which does not really add 100% the value or the actual stuff what you want from a story. Absolutely. And we end up creating those kind of stories as well. I would say, yes, that sometimes is unavoidable, but try and think from some of these techniques if you can benefit from that and see if, you know, slicing, using one of these approaches or there are many other approaches, maybe that could help, right? Sometimes it might not help. Let's be pragmatic, right? You have legacy code and you have to deal with it. And sometimes, you know, even doing the smallest change seems like a big task, right? So you have to be pragmatic saying, okay, in that case, that's a story in my context, right? But again, think about some of these slicing techniques. Maybe they will help you, all right? Let's look at one more example before we conclude. This is, again, a very generic thing, like any kind of a report you guys have, you know, most of you must have built some kind of a report so I thought it would be familiar to people. What we're trying to do here is basically we are trying to find out the occupancy in this hotel, you know, and we wanna know what is the occupancy in this hotel so we can make certain decisions based on what is the occupancy. So if I wanna find out what is the occupancy in this hotel, when I say occupancy in the hotel, I mean in the rooms, basically the hotel rooms, right? So what I have here is basically, it's not very visible over there, unfortunately, but I have occupancy type on the top, you know, it's single occupancy, double occupancy. Then below that I have a date range so I wanna know occupancy within this date range. Below that I have the different class of room types, different room type classes, different categories of the room types itself within a category. Then I have whether I wanna look at the full report or a delta report. If I say delta report, then I wanna look for the last three days, like give me the report or give me the full report within that range, right? And I might want the report in different formats. I wanna see it on screen. I want a PDF, I want an Excel, I might want all of those different things, right? And then it shows the details below here. So let's imagine this is your feature that you want to build, is this report that you want to build, right? How would you slice this report? First generate the report for, so first generate the report without any criteria, just do the entire thing, okay? That's a good approach, any other approach. It's interesting because to me this is one feature. A report is a feature. So you're saying generate the report just based on the occupancy type, okay? Fair enough. It would be a lot of rework, right? So you don't wanna do that, all right? Yeah, that's what he said, correct. That's what he said is that I will show all the data and then I will apply filters. So the report is, let's assume that this is a fairly complicated, right? So when you say graphical, if it is only one set of data, then I can understand. But this, like, assume 50 rows and I want all those different rows. And we are saying we don't really want graphical view because these people who are looking at it want those numbers and they'll crunch those numbers. They'll make some decisions based on that, right? So I'm saying let's scope it to saying only graphical, but only numbers, basically whatever the data that is presented, like a grid kind of a thing. Now in that is their way to slice it. So you're saying that the first thing you would do is to basically generate a report in PDF or Excel format. But what report are you gonna generate? Where do you get the data from? The data, I'll be getting it and not displaying it on the table. You're saying not displayed on the table, but you still have the filters? Yeah. Wouldn't that be lot more effort than just displaying it in the table? Is that seems like a sophistication? I've got this. Now I also want it as an Excel. I want it as a PDF. That seems like, you know, added sophistication. But at the minimum, I wanna at least see the data. As of that date, you will only show the data for that date. It's basically what you're saying. No, but I might not ask for today, right? I might be coming next weekend, okay? So this is fair enough. So you're saying based on the request, you might only select the date and view the data for that date. Instead of showing for a date range or any of that stuff and that's what you would get started, right? I know I'm running short of time, so I'm gonna quickly jump into the solution. So this is actually a real world example. The way we actually went about it is we started asking, what is the most common filters people select when they want to view the report, right? What is the most common options people select when they want to view this report? That's a question we ask to the subject matter expert, right? That's a question I ask the subject matter expert saying what is the most common filters? If this is the most common filter, then basically I am not gonna build any of those filters by default I'm gonna hard-coded in my query and just get that and display it. That's my first slice, first cut, right? So I'm eliminating all the work I have to do with the filters, right? I don't even have to build any of that. I'm just hard-coded the filters. I assume that this is always what they want because based on what I've heard, they say that about 90% of the cams they wanna only look at the report of the last one week or the next one week, let's assume, and they only want to look at single occupancy because it doesn't make much of a difference with a single or double occupancy, stuff like that, right? So what I'm trying to get here is one way to slice things in this context would be to look at what is the most common usage and then basically eliminate additional work to at least for later stages and at least give the bare bone which is most commonly used, right? And then gradually keep building things up. So full report, no PDF, nothing, single room full, then you basically go into other kinds of things. Then you add room types, then you add other kinds of filters, but essentially you're going by one step at a time based on what is most common, what is the most, then you look at the 10% variation. Where is the 10% variation in that? That could be based on the room type. So then you build the room type functionality. Then you say, okay, now you've knocked off 95%. In the 5%, where are the variations? The variations could be to do with Delta or full. Then I'll build that. So you could start slicing your functionality based on usage, what is most commonly used? Especially, this is very handy for reports because reports can get fairly complicated and instead of trying to build all of these different, different functionality, livers, filters, all of that, you could actually hardcore start, at least you start delivering value and then gradually sophisticated over a period of time. This is not really evolution in that sense because you're really driving the slicing decision based on usage. So this is usage, using usage as a way to slice your decision, how you slice things. Going down the business value, what is the most common case, which means what is gonna give me the most value and then gradually keep going down? What are the other things that I could do based on the usage? So this is more to do with looking from a usage point of view. And we actually refined this over a period of time because we gave all the raw data and it was hard-coded. And then we refined it over a period of time to make it more. One case we were sophisticating, in this case we were refining. So they're slightly different and we are using usage or we're using value or we're using other kinds of attributes to drive those decisions. There are a whole bunch of other slicing techniques which we are not gonna get to, which I knew beforehand, so which is why I have not put the slides for them. System slice, behavioral slice, ill-ity slice, let's quickly run through that. What are basically system slices? System slices are things like whether you do static or dynamic. Sometimes the example we saw, the first hard-coded thing is all just static or I talked about earlier like a fake feature which I have not actually implemented the feature, it's just a fake thing, it's a static. And it's got me some functionality, it's got me some business value, then I'll make it dynamic, then I will add more livers to it, then I'll sophisticated more things like that. Whether I want to do real-time versus batch processing, that's another way to slice things. Instead of doing real-time, you could say I'm gonna do batch processing for now and then gradually sophisticated the algorithms and things like that that I can actually deal with it in real-time. You know, whether build versus buy, whether I want to build this or whether I want to reuse some other third-party component, that's another way to slice it. You could use that as a decision point. Automate manual differs certain roles. Behavioral slices, again, is more looking from the sophistication point of view, looking from the acceptance criteria point of view, looking at bypassing certain workflow steps, like in the very first example we were looking, you could bypass certain steps and still add value. Focus on happy path or the most common cases first. Don't worry, all these slides will be up. Actually, they're already up with the video, so you will have all of this. No options to many options, like the example we just saw. You had no options to start with and then gradually added many options for them. The last one is basically using illites, which is things around performance, things around start with just a very simple UI and gradually build it. Start with minimalistic data and then gradually increase it. Start with a very bare-bone performance and then gradually improve it. So look at, from an illites point of view, how you can slice things. So there's like so many different tools, techniques that people use. It would be fantastic if someone writes a book on this topic. There is, however, this particular PDF that you can find quite useful because it kind of builds a mind map of these different techniques that you could use. It's, the URL is not quite visible, but when you go download the slides, you will get that along with that, all right? You go back to the description of the sessions in ConfinGen, so in there, the slides and the videos will be available, all right? Some of the, correct. We can only request the speakers, we cannot force the speakers because this is what they are doing is voluntary, right? You can't force someone to say, no, you should upload the slides. As much as possible, we request the speakers. Most often, you will see after the conference, about 90 to 95% of the people will go ahead and upload the slides, right? But at the minimum, what we will do is we'll upload all these videos there. And this year, what we are also doing is we're actually capturing the slides and the video together. So actually what you will see is the slides along with the video. We're also slicing and gradually rolling out functionality. All right, so I think I've given you a very quick run-through of few different techniques. There is a lot more techniques, but hopefully this will get you thinking in this thought process and maybe there is a lot more to learn based on experience. So in one of the earlier slides, you mentioned about the money part or the dollar example, which was broken down further. Now, if you have to take that same Facebook profile or something, how would that come into picture? Will it be the goodwill thing, which you just mentioned, which was one of the examples that I took? How that would come? So the value, the money metaphor was that basically if you tear the note and distributed to people, you've lost the value. The tone money part has no value, right? So when you're slicing stories, use that as a metaphor, as a reminder to say, am I tearing my story this way so that that little story that I've built actually has no value, or am I actually taking the 20 rupee and I'm breaking it into 10 rupee, five rupee, two rupee, one rupee, such that each of them have value, but I've broken it down. So it's just a metaphor to use when you're slicing things. So there's metaphors and then there are techniques. Right? Any other questions, yeah? We said initially that invest principle has to be used, but is it like practically possible to have all stories resulting in following the investment principle? Like? We try to, it depends on the context. We try to have more stories this way, but also it depends on the context like the gentleman over there was saying he has some hard constraints around legacy system, right? So maybe in that case, he might not always be able to slice stories in this way, so it's okay, it's not the end of the world. We've been doing software development for many years without this, and it's been okay, right? So I think it's okay once in a while. All right, that question killed all the enthusiasm, so thank you for being here.


There should be a PostgreSQL JDBC4 jar file which is the JDBC driver for PostgreSQL that should be present. So all you have to do is copy the file right click and say copy and then go to eclipse. So in eclipse we have a project which we had created yesterday. So if you expand that project you will find a web content directory within that, expand it and you have a webinf and there is a lib directory inside. So right click on that lib directory and paste the jar file that we just copied. So once you paste it you can see that the jar file appears within the lib directory. So the next step is to create a class which uses this jar file. So go to file new other and select class. Say next give some name say it can be just a test class. So we created a class. Now we have a sample JDBC program provided in Moodle you can browse to that. So you can copy the contents of this class file of this Java file. Yes it is given as a link in the here in this third step. Yeah the class name can be renamed if you I mean class name is secondary. I mean you can just name it to whatever the file name is. So you can so now here I have called the class as test and I yeah the sample JDBC program paste it on to the test.java and change the class name to test. The class name and the file name should match that's all. So you can go through that program to it's a simple program which first first loads the Postgres SQL driver for this line to execute the jar file that we added has to exist in the library. You have a class the contents of the class should be this file and then change the. So there is a driver manager dot get connection line there enter the database name that you have created yesterday with the university schema. So it's I've called it to do dbms2010 and then enter the username and password you can use any user that you have created yesterday who has access to the university schema. So what is the so you have the file name and the class name as the same after you paste it go to the line driver manager dot get connection I have highlighted it yeah. So there in place of my db so that is the URL that is that is how it knows which Postgres SQL database to connect to. So we are saying local host and we have to give the database name yeah it depends on what you have created yesterday we created a database in pgadmin yes this is the format of the URL so yeah so this is basically the host this is where the server is running Postgres SQL host you can give IP address also yes it can be any it is just to identify where is the server which is running the Postgres SQL database port it uses the default port it knows the port. So for normal usage you don't need to specify the port. So we specify the database name here and then give the username and password first day the one that you created in psql where you pasted the where you created the university schema on the first day you can go back to pgadmin and browse there you can check it from there. So I have given Postgres and 1 2 3 because that's the that's the password I have used in my my machine so no no this is the password for the Postgres user. So this is this is just the example with this in it is the same username and password which you use to connect using pgadmin 3 is the same username and password no no it was there was a command that everyone ran slash password Postgres and set a password so whatever password you gave there that's what you should be using everyone has given their own so there's we haven't stuck to convention there then how did you connect using pgadmin so you can change the password again you can just okay if you have forgotten the password so the the only so what you can do is again change the password reset the password using the manual I mean using the steps that we had given in in yesterday's in day one so in the day one tutorial we had this step for changing the password administering Postgres so you have you will have to go through these three steps and set the set a new password it won't ask for the old password you can just enter a new password for the Postgres user and then you can come back to and then you can use that new password so once so I'll move move ahead and for those who have not forgotten the password maybe I'll come back again so once you enter the username and password you can look at so you can in the program below below that line we have a connection dot prepare statement there's a line of code which says current connection dot prepare statement and passes a SQL query with a question mark so that query has a name university dot student so that is basically saying the schema name dot table name but in our case we don't have to give the schema name you can just say select star from student it will use the default public schema which for it will use the default public schema for the user Postgres user so you can just change it to select star from student where department name equal to question mark so that is that is the end of that is all the changes that are required so now you can once you are done with this you can run this program so you can right click right click on the file say run as and Java application so if there is any error it is not if it's not able to connect it gives an error so I get a message that I have connected so this is the system this is the print line command which we had which we have in our program so once it's connected it's actually asking for a department name so you can enter a department name in the console so once so how many of you have been able to successfully establish a connection okay as soon as the connection is established you get this message here below you are connected and below that you can you have to enter this line you have to enter biology with the B uppercase so it's basically asking for a department name you enter biology and hit enter it lists out all the all the students who belong to that department this is just a toy example where we fire once one small query and show the results so if the connection is fine you will get a list of students from the database yeah so it depends on how much data exists I have a large data set so it shows me a lot of records so if you are able to successfully run this you can now go through the program and try to understand how what the code is what the program is trying to do and maybe you can change change the query and try out some things and there is an assignment corresponding to this assignment 5 so this starts gets you started on assignment 5 so this gets a this gave a sample program which connects to database and gives some results so now you can actually look at assignment 5 and try to modify this program or write so write similar programs which do similar which fire queries and display results so first for the JDBC program itself actually we should have added it in our sample JDBC program but the way we are handling the exception is not exactly very not a very nice way so if you open the sample JDBC program towards the end of the file there is a catch clause catch SQL exception and we are just printing out could not connect so that is actually hiding what the real error message is and whatever the error is it just says could not connect so instead so you can so just you can comment out that line or remove that line and add this line I will type it out so you can say SQL except SQL E dot print stack trace semicolon is it visible till the yeah it gives the error message on top along with the stack trace so this gives a detailed the actual error that is that is happening on the server so please make these changes in changes in your so you can just start I will make one error so I will make a mistake where there is the invalid column name the column DEPT does not exist so here it connected successfully and now it is asking for a department name and when I actually enter the department name it gives an so now it gives a exact error message saying column DEPT does not exist so for any such syntax errors in SQL you will get a more meaningful error message.


Hi, it's Mayor Eric Adams. Internet isn't a luxury. It's a necessity. And too many New Yorkers have been left behind. For there is a federal program that can save you money on your Internet bill. The Affordable Connectivity Program. If your child is in a public school, if you are on Snap, if you receive Medicaid or participate in any federal benefit program, you can get $30 off your Internet bill each month. Thousands of New Yorkers qualify. Go to GetInternet.gov to find out more and save money on your Internet bill today.


Item number SCP-2354 Object Class Keter Special Containment Procedures Lack of knowledge regarding SCP-2354 has made direct containment infeasible. Containment efforts should instead focus on monitoring likely targets of SCP-2354 and attempting to pre-empt the entity. This policy is to continue until more effective containment procedures can be developed. Description SCP-2354 is an anomalous ambush predator targeting individuals who have recently experienced a death or disappearance of a loved one. SCP-2354 is believed to stalk a given subject for an extended period of time, variably ranging from three weeks to six months before luring its target to an isolated location and bludgeoning them to death. SCP-2354 will then lacerate the subject post-mortem, typically by removing a single body part. Most often the hands or genitals. The significance of this process is unknown. Beyond these factors, little is known about SCP-2354's appearance, movements, or current whereabouts. Although initially attributed to a series of non-anomalous serial killings, the inexplicably broad range of SCP-2354 manifestations has made the likelihood of anomalous influence a near certainty. Incident Log The following is an abridged record of deaths connected to SCP-2354 and descriptions of their circumstances. Date Description Notes September 15, 2002 Howard Keitel, 27, found deceased in a forest one kilometer from his home in Berlin, Germany. Feet removed at the base of the ankles, bludgeoned to death in accordance with typical manifestation. Keitel's 12-year-old son, Howard Jr., had recently died after falling from the roof of the family's country retreat in Bamberg. Keitel expressed despair over the death and had recently been hospitalized following a suicide attempt. August 16, 1994 Catherine Smith, 33, found deceased in an alleyway in Trenton, New Jersey, nearly 500 kilometers from her home in Richmond, Virginia, believed to have traveled in an attempt to evade SCP-2354. Hands removed, bludgeoned to death in accordance with typical manifestation. Smith's 12-month-old daughter, Hosanna, had recently died of sudden infant death syndrome. Smith had expressed concern about childbirth but was described as a loving mother. Reported feelings of being watched prior to death dismissed as symptoms of an anxiety disorder. December 27, 1992 Jose Gonzalez, 20, found deceased in his apartment at Brooklyn, New York. Hands removed, bludgeoned to death in accordance with typical manifestation. Gonzalez's 8-year-old niece had recently disappeared in a suspected kidnapping. Gonzalez had begun to exhibit strange behaviors shortly after this event, primarily centering around feelings of being watched, which intensified shortly before his death. January 2, 1992 George Berkowitz, 43, found deceased in an alleyway three blocks from his home in Los Angeles, California. Hands removed at the base of the wrist, bludgeoned to death in accordance with typical manifestation. Berkowitz's fiance, Laura Hoover, had disappeared one month prior and what was later ruled a homicide. Her body was discovered shortly before Berkowitz's death. No suspect was ever identified.


Given by information and communication technologies, our societies have undergone a digital transformation that gave birth to the digital economy and information society. The information society has emerged as one of the main lines of defence against COVID-19. There have been many successful stories which have shown a spotlight both on the vital importance of ICTs and deep digital inequalities between and within countries. In this decisive year, ITU will use world telecommunication and information society to unite the world in pursuit of digital transformation in every area of business and all parts of life. It will be an opportunity to strengthen national strategies on ICT development, implement smart policies and effective measures to encourage investments in ICTs and digital skills, and upgrade our services with new technologies ranging from AI to 5G that are central to the digital economy. This moment in history calls for cooperation and partnerships. I am calling on our members and other stakeholders to continue our efforts to harness the power of ICTs to advance the WISIS Action Lines, ITU's Connect 2030 agenda, the United Nations Sustainable Development Goals, as well as the SIEM connecting the unconnected to achieve sustainable development of the ITU World Telecommunication Development Conference 2021, so that the accelerating digital transformation we are witnessing leaves a new one behind, a new one offline. We want to hear about your success stories, but also about your challenges and lessons learned. Share them with ITU now, and we will give them the place they deserve during the 17th May celebration of World Telecommunication and Information Society Day 2021, another theme of accelerating digital transformation in challenging times. Until then, stay safe, stay well, and be strong.


I'm Adrian Pristis, Corporate Medical Sleep Director for Hackensack Meridian Health. Sleep disorder is pretty self-explanatory, it's just about anything that might bother you for the night or daytime, whether you're getting a bad night's sleep or you feel the effects of that during the day, such as tiredness or sleepiness or the need to nap. People who don't sleep eight hours end up going to the doctor more often, they're sicker, they're in the hospital more, they take more medicine, and they get more tests. The National Sleep Foundation estimates the number to be about 70 million Americans that are affected by sleep disorders. Most of the people that are on that 70 million Americans who have a sleep disorder are insomnia patients, and again, they're among that list of patients that go to the doctor more or sick more, don't do as well at work, they have social problems, relationship problems, and so it's a serious business, and it's not easily treated, and I think that's why it's overlooked a lot. In the United States, people get a pill, they just want a pill to go to sleep, most patients with insomnia should probably not get a pill. There's an entity or a practice called cognitive behavioral therapy, it's a number of sessions with a number of schools of thoughts and therapists and psychologists that help people undo all the bad habits that come along with why they are an insomniac. Hackensack Meridian has 13 sleep disorder centers spread through Central and Northern New Jersey. Monmouth and Ocean County have six centers themselves. The Sleep Center is a physical building where people go to have their diagnosis made on a variety of sleep disorders, and they can be sleep apnea, brain behavior disorder, or other disorders that happen at night that are less common that require an observational study. A vast majority of insurances cover sleep studies in one form or another. Relatively easy to schedule sleep studies, as your doctor will tell you, they'll take care of most of the work at Hackensack Meridian. The patient essentially doesn't have to do anything to wait for a phone call. They're open seven days a week here at Hackensack Meridian. It should be too difficult to do. Most people can get a night they like in about two weeks or less.


There are pyramids on Mars, you know, who put them there and when is anyone's best guess and guess what? We just happen to be anyone. It is probable that in the very distant past that Mars was habitable, that a civilization existed there and possibly had developed relations with the earthlings. There is very little doubt that we had visitations in the past by a much more advanced society. Could they have been the Martians? Perhaps this is where the overwhelming interest is coming from in our obsession with the red planet. Cairo, for example, is the most ancient site on earth in terms of the pyramids and Cairo is named after Mars. So it would seem that this now apparent desolate planet was of major significance in the ancient world. We see renaming of places like York in America as settlers from York now claimed New York as their home. Perhaps this was the case at Cairo where the Martians came and settled in Egypt after their own planet was cataclysmically destroyed beyond habitation. Maybe hieroglyphics was the language of the Martians, the sudden engraving of hieroglyphics in Egypt at the time of the Dynastic Egyptians could be in that of a lost civilization trying to document their history here on earth. We see other such inscriptions like the drop of stones dating to 12,000 years ago and telling a tale of an apparent alien crash landing on the earth where the aliens became stranded in remote Tibet. Maybe the same such beings crash closer to Egypt and were able to establish an empire. The pyramids on Mars are stunning examples of a civilization that once was present on both planets. The Twin Peaks on Mars do resemble pyramid structures like we see at Giza and it is complete with a Sphinx looking object. The debris we see all over Mars is possibly the result of the cataclysm. It is uncharacteristic for debris to be sprawled out all over the surface of something and you need to consider where the debris came from. They must have been built up at some stage in Martian history. Anyway guys, we want to bring news to you of more stunning discoveries in Cairo recently. Again, backing up the idea that Cairo City is in fact the ruins of the gods, the gods being the civilization that came to this earth from elsewhere. Mars possibly wait till you hear this. Archeologists working at a dig in Cairo have found several fragments of stone slabs with inscriptions that could be 4,000 years old. German Egyptologist Dietrich Raou, the head of the mission, said one inscription referred to Atom, an important and frequently mentioned god as being responsible for the flooding of the Nile River in the late period between 664 and 332 BC. Mattaria in eastern Cairo was once part of the ancient city of Heliopolis or the city of the sun. Egypt is pretty much constantly announcing archaeological discoveries, hoping this will spur interest in its ancient treasures and revive tourism, called the lightblood of its economy, which declined following a failed revolution in 2011. Also, French archaeologists working in Lexor have uncovered a coffin and a painting believed to date to Egypt's 18th dynasty, making them 3,500 years old. The coffin is described as being complete and made of wood. It's also said to feature some identifying marks. The painting which is done on sandstone has suffered over time and is missing a piece. The two artifacts were found next to one another. And there is also the hype about the ramp they have discovered at the ancient quarry. Is anyone actually buying into the idea that the pyramids were built using enormous ramps? An example of how ridiculous this can be found in the fact that a ramp to move stones up to the heights of the Great Pyramid would need to be miles long, yet this is the only such ramp ever found. A more convincing theory on this ancient ramp is simply that it was the road in and out of the quarry site. We can all speculate, right? We are just touching base with you guys on this one tonight, and you can let us know what your thoughts are below. As always, thank you for watching. Hey guys, this is Buzz Weaver, the voice of the Lost History Channel. I wanted to take a moment and thank you all for the continued support you guys provide here on the Lost History Channel. And I welcome you guys to visit my channel. Each Friday I release a video covering current events, headlines that are in the news, technology, and happenings in social media. So consider stopping by and subscribing, as your guy's support is always appreciated.