 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. This is a workshop, so we're going to try and get you guys to do a bunch of things. 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. So if you're sitting at a table, you don't like other people around you, try and find a table where you like people around you. 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? I mean, I just wanted you to take a stab. 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. And then basically you go through your release planning, you add some acceptance criteria to it, then you go through your iteration planning and then you add tasks to it, right? 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. But how do you decide to slice the story in a particular format to come up with that even though you might not capture that in your story? 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. And I'm not gonna do a fancy, you know, whatever, the tree structure, all of those things. 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. Let's continue because I do need to cover a bunch of things, let's catch up. 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. You go to buy a car and you say, you know, I want a car. 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. So again, it becomes difficult to fit in a particular story in a sprint or still that story keeps looking a very big story. 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.