 So, my name is Tarang Bakshi, I'm a project manager and business analyst with ThoughtWorks. What you see here is a bunch of case studies that we would be running hands on. So you would have on each table you should see a set of yellow sticky notes and one marker. That's because everyone in this room is going to be participating writing things on those sticky notes and actually trying out what these case studies are about. This topic is based on real life projects. So the case studies that you see are based on real life details. So we'll get started and we'll have to keep questions to the end or maybe just after each case study we're going to run two case studies just because there's so many people. But if there's anything that's really pressing, just stop me along the way, fair enough. So I just want to get a quick sense of, since this was a practitioner session, how many people in the room have worked with user stories quite a bit before? Okay, pretty much everyone. How many people have actually been responsible for slicing features into stories, breaking them down? Okay, great. So I think that's a pretty good mix of people. So let's start. So actually I'm going to start with why should you really bother, right? Why does it? Why don't you start with academic exercise when we say slicing user stories or is there more to it? So I actually think that, I used to think actually that this whole invest principles for user stories, all of that was academic and in the real world you wouldn't make trade off, some things wouldn't work, some things would work, some things would not be possible. But actually when I started to really slice stories and big features as features got more complex, I started to realize the mistakes I was making by not thinking about those things. So story slice, right? Really some things that I hope that you'll take away from this session and see for yourself is that when you slice them right, you are able to demonstrate evolving incremental value of that feature to the business, to the users. You are able to get faster, more meaningful feedback on what's already built. And just humor me for a second if some of these don't make sense just yet when you run through the case studies, hopefully some of these will start making more sense. Something that will reduce your delivery risk itself. So often we think of this as, this is a business analyst or product owner responsibility, but actually it's not. This is, the whole intention of this is for people to do this in a group with everyone, developers, testers, user experience specialists, because all of this goes towards reducing your overall delivery risk. You'll also see that story slice, right? Support continuous delivery. Even if you're not familiar with some of the practices that make up continuous delivery, we'll talk about that once we get through the case studies. And you'll also see that just slicing it right results in a lot of savings on effort, on cost. So just minimizing the waste that can happen in a typical software project. We'll come back to this after the case studies to see whether you've been able to get these from the case studies or not. So let me introduce the first case study. I'll be giving you handouts as well. We'll be working in groups. But just before we do any of that organization, I'm going to introduce this case study so that you know what we're talking about. After I run through the slide, feel free to ask questions if you don't get what functionality this is about or what feature this is about. And actually let me pause here for a second. Any burning questions? Anyone completely unclear of why they are here or what we're going to do now? OK, I don't see any hands. All right, so let's start the first case study. This is intentional that I'm not giving you too much context on how we should split stories or any of those. I wanted to try it first, and then we'll all learn from each other. And then we'll run the second case study where we can apply some of those learnings. So the first case study deals with a feature that all of you probably have used, check-in for a flight on an airline application. In this case, what you are tasked with or your team is tasked with is building an iPad application for a major international airline, and the feature is check-in for a flight. This iPad app is intended to be rolled out to users in 12 countries. And the iPad app is going to run off business logic that resides in a bunch of APIs that are already used by the current website of this airline and other mobile apps that are already in the market. Clear so far? OK, so what does the check-in flow look like? This is not necessarily the simple check-in flow that you might have seen with airlines in India. You initiate your check-in or choose a flight. You provide traveler information. So in the US, if anyone's traveled there, you would have noticed that there is some secure flight information that you have to provide for every flight, like your date of birth and your full name per your passport. So those sort of details, you choose your seat or you choose an upgrade if you had economy and you wanted business. You check-in baggage. Typically, it's not really free anymore for most airlines. So you might have to pay for some. You choose some paid extras. So if you wanted Wi-Fi on the flight or you wanted a meal that you wanted to pay for in advance, all of those extras as part of your check-in process. Then you pay for upgrades. You pay for them. You collect everything that you want to buy, your upgrades and your extras, and then you pay for it, because that's not included in your ticket cost. And lastly, you get your boarding pass. Familiar enough process? Flow? Everyone's been through this? Or at least most of this? OK, so let's start with if I have two of my colleagues who graciously agreed to help me, Anusha and Dawal. They'll come around to every table. Each table is a group or a team. You'll have one handout for the group. Look at the handout. It has all the details that you see on the slide. And just discuss as a group if that feature is the one you have to break down into stories such that you can start development tomorrow. How would you go about doing it? Use the yellow sticky notes to write just your story names, so one story per sticky. And you can break it down. Because the sticky notes, you can move them around and change the order or scrap some stories, write some new ones, modify some stories. So some just some more information. So the initiate check-in step, there are three different ways you can do this. One is that if you got a check-in notification saying, oh, it's 24 hours to your flight, and you can now check-in, you can just tap through on that on the iPad application, and you can go ahead and check-in. The other way you can do this is by just going into the application searching by your PNR and last name and saying initiate check-in, it will allow you if it's in the eligible window. Or you can log in to your account, look at your set of trips, and select the trip that is available for check-in. When we say input traveler information, there's a lot of complexity here. Depending on the countries that you are covering in your journey, there are different kinds of mandatory pieces of information that you must provide. So for example, as you would know if you fly international, you would have to provide your passport information. There are some special display and input variations for travel in countries noted here, Germany, Japan, and Brazil that are known right now. We don't know about some other ones. We'll have to talk to those countries and find out. So these variations include things like, oh, in Japan, they always put last name before first name. So when you input the name field, it must be last name first and then first name if the person has chosen Japan as their country of domicile. Those kinds of things make that piece complex. You can also, as I said, you can change your seat or you can include a class upgrade, check-in baggage. Different flights will have different free allowances. You choose paid services for flight. This includes priority boarding, insurance, meals, Wi-Fi, and then you pay for all your extras. And you can get your mobile boarding pass or you can get your boarding pass in two ways. Either a mobile boarding pass delivered to your device or you can say email me my boarding pass. So a lot of options, a lot of complexity in the feature, lots of countries to support, lots of variations. So let's just see how you're able to figure out how to slice this up so that you have playable stories starting tomorrow morning. I do need one thing from every group. If you can identify one person to play the customer for you, if that person, one person per table can step forward and come to the front, I'll give them a brief on what information they can provide the group as customers. So one person per table as customer. In the meanwhile, the others can start going through the handout and discussing how they would split the stories. I missed out on this. OK, so what we're going to do now is at least two groups. And if we can, if we're still running on time, three groups, we would like you to just present how you approached slicing this feature. Maybe just run through the first two or three stories that you got out. And we'll try and get some learnings distilled from what people are talking about. So which group wants to volunteer first? OK, first hands, we end up here. Well, let me just give you a microphone. Yeah, so. Hi. So we sort of, again, the way we approached was the high level, the epic was maybe a side check-in. Second one under that feature was an initiation. Then we started breaking down the stories. The easiest one, what we found, which we can do it in one week or less, was actually about the search by PNR and last name. So what our easiest story was as a user of Delta Airlines, I would like to enter my PNR number and press Go so that I can search for my itinerary. So would that be your first story? Search by PNR, tomorrow morning, that's what you would have your developers start on. So the easiest one, again, I'll just have a display field and play with number Go. Second one was because there is PNR plus last name. So second was, again, was just an iteration over that, which is enter my PNR number and last name and click on Go to search for the itinerary. OK, so next, then we went into the Traveler info one, which was, again, a feature. Under that, we broke down into a story where the user, so as a user for Delta Airlines, I would like to enter my passport and visa details and save the information for further processing. OK, next one. So I think we have a sense of, so you've approached it by looking at the different steps in the flow, which steps seem like they can get done faster or are in the beginning of the flow and moving through to the end. Right, so our intention was not to cover all the choices for initiation. It was just to provide a basic, simplest flow of initiation, traveler info, choosing the seat, and then work on the other iterations or choices. So approximately how many stories later would you end up with a user having completed check-in? Completed check-in. Approximately. Well, yeah, we didn't go that far. OK, but at least five or six, more than that? More than that, because we studied in a small group. Let's try another group. Any other group that has different? OK. So what we started out with, the thought that we'll give customer the business value. So we'll take up the minimalist happy path, all the way from top to bottom. And we started out with Search by PNR as a first story. Second is initiate check-in. And it's a pretty small story, yes or no option. And then that's how we moved forward. So but the basic principle that is, do the happy path, kind of flush out the architecture as well, end to end. And then we can provide all the frills. OK, so I'll ask the same question. Approximately how many stories later do you reach a completed check-in? We have five already identified, but probably plus or minus three more, yeah. OK, fair enough. Any other group have a very different way of splitting it? OK, this group? It's quite different, but it's quite similar to what they say. Check it out, a vertical split touching across all these stories. We have a vertical story which we'll start off with a simple. We assume that the link is already there to log in automatically to the ticket details. So we have the, we start working on the click-in check-in notification, so if they have a link, the customer gets a link, they will just go into the PNR details. And then one of the basic things we can give next is probably the security details. So we get the security details. We have read it on a story, which the next thing is to give the value. So the first story would be click on the notification link. No log in, no nothing. OK, where would it end? Where would your first story end? Next, it will end to the security details where they can provide the security. OK, so your first story goes from clicking on the notification and to the page that displays your traveler info. OK. They can move ahead. And next, probably they'll choose a seat afterwards. And then because we needed some value for the business, so we probably provide some free, not free, the paid services. The first thing we probably means, or Wi-Fi something, we have a small option that the customer can select that and then move on to the next flow. Approximately how many stories later do you get to a completed check-in? We have, I think, one story we can provide end to end flow. We can get some value out of it. OK. OK. Fred. So we were thinking we can address some of the clients of customer so that you start deploying stuff. So ship first. So after three stories, a user can check-in. No frills, no check-in baggage, no paid services, nothing. Then after that, before we get to more frills and initiate check-in or otherwise, we start deploying paid services because that's what generates revenue. OK, so we'll stop here with the other groups. We'll get a chance at the second case study. So I'm an especially this group I know wanted to speak. And I'm going to go in the back as well for the next one. But just in the interest of time, we're going to move ahead. I think the gentleman over here, I think, really hit the nail on the head. The reason I kept asking, how soon do you get to a customer having completed check-in? Because that's your basic value, right? Being able to successfully complete your check-in. Now, yes, there are lots and lots of options and lots of complexity. Japan does things in five different ways. There's lots of paid options. But you would have heard from the customers that actually there is a default available for everything, maybe with the exception of your traveler information. But your seat is already pre-assigned. If you didn't choose one, you'd just keep your pre-assigned seat. You don't have to check-in baggage. Your default can be zero and you can move ahead. And there is a send a boarding pass via email, which does not need that potential complexity around getting a mobile boarding pass on your device. You can just assume that that's something that you're just sending something saying, hey, email the boarding pass to this person. And once you can successfully confirm that that step has happened, you're done. So one key principle I think you touched on, get to the end of the flow as soon as possible. So now what happens is once you've gotten to there, even if it's two stories, three stories later, the stories that come up after that, you are always validating that, oh, no matter what I changed, the successful check-in still works. But if you find out 10 stories later, maybe that's three iterations, four iterations, five sprints later, that actually successful check-in does not work because the kind of information that you have spent a lot of time doing does not work properly with the API and you have to redo your work. That's where waste comes in. That's where you have a problem with potential, if you intended to get this out to the market really soon, that there happens a really difficult conversation with the customer. Any other quick comments from anyone else in the audience who hasn't spoken yet? But our customer had a very different opinion. He wanted the revenue as soon as possible. In the first release, only he wanted to have money. If you go with the scenario, what we discussed, no free nothing, then no revenue will generate for him. Good point. So the question was about revenue. So yes, we had indicated to the customers that revenue was really important. But the revenue, can it happen without successfully being able to finish check-in? It can't, right? So you've got to have that check-in completion, your base first. So it's not suggesting that you can go live with your basic check-in, like this group talked about. You probably can't go live. But you can demonstrate it to your business. You can potentially have end users try it out, give you feedback, saying, oh, this doesn't work for me. I didn't understand what the next step was. I didn't understand how this email thing works. All of that feedback comes through. And as soon as that's there and working, then start with your first paid option. Maybe your paid bag is your first thing and still prove that your completion of checkout works. So potentially with payment, that could be complexity, right? Your developers might tell you, hey, integrating with the payment gateway potentially is difficult. If we can't do it in a week, it could take time. There could be lots of things that could go wrong. Do you want to hold back something from customers in all that time that it takes? So that's the idea here. Any other one last comment before we move to the second? And I'm going to go to the back of the room for this. That gentleman there. But we might be probably defining or looking for the minimalistic feature set that the customer wants at the very start. But say if we do not look at all the possible options that the end customer might want at the start, then there might be a failure when we try and add certain features at the latest prints, right? So it's best to define the product backlog at the very start with all possible stories. And then so that we are easily adapting and adding new features rather than realizing at a later point in time that we have to change drastically to add new features. So it's best to define the product backlog and then have the minimal set defined, which is probably easy to adapt rather than doing something which is working now and breaking later. So fair point. So there are two parts to this, right? One is defining what your story breakdown should be. That's not necessarily something that would need to happen right the day before you start your first story. You would have spent some time with your customers, understanding the details. All of the details you saw on the slide would have been discussed and you would have started. But the idea here is how do you think about breaking down that feature into stories, even if you're going to play it over time. It's not that you would have to not think about all the paid features, not think about the Japan variations. You might have to think about that, but you don't need all of that information to be known upfront. Also, the way you're doing it by proving that your check-in works, let's say something happens and the Japan and Brazil variations don't work and our release date is tomorrow. It's not working, not happening. Can you still release your product? You probably can, right? You can say that, OK, we won't have any special support for customers in those two regions. But because everything else still works, you can still release your product. Same thing, let's say you were not able to get paid baggage working in time because that API wasn't working properly. OK, so other paid options are still there. Those are working. Paid baggage does not work. You have to tell customers that if you have baggage to check in, please go to our website. All of those options are possible, but it does not hold up your release. That's the principle. Sorry, we'll have to correct. Just the stories and potentially what you might play first, but you don't have to know today exactly what sequence you will play the 40 stories in. You're approximating that, oh, we will probably start with this and this, but as you find out more, you'll change it, right? If the customer gave you feedback that, you know what, just the baggage revenues, I'm fine with that. Let's focus on that. But I have a call from the Japan business owner saying that his feature must go in. Otherwise, I could get fired. You might pick that up first. You might not do the other revenue-earning things, right? OK, so I'll actually need to move on just because we'll run out of time. I did have just a very quick suggested solution. I think it's sort of already covered. So I would personally, in this case, start with my first story that I'd try and see if work with the developers and see if it's small enough to play is check-in for a US domestic flight from MyTrips. You would have noticed that my login and MyTrips is already implemented as a feature. You don't have to worry about the check-in notification. You don't have to worry about searching by PNR, any of that. That's your fastest entry point at this point to get your check-in flow started. So I would personally choose this step, saying it doesn't. Even if we didn't bother worrying about the eligibility 24 hours before, and we said, you know what, user, when testing, we will manually take care of the fact that the flight is within 24 hours. That's the first story I would play. I would say it's for a logged-in user so that there is no input required for travelers. There's a save traveler that was there from the website that I'm going to use. I'm also going to have all the default choices, so no seat selection available, baggage you can't change from zero, and boarding password, email. Maybe my developers will tell me this is not going to happen in one week. We'll make some trade-offs. But this is what I would personally go for as my first thing to play, because at the end of this first story, you have a successful check-in. And you have a successful check-in for a real-life scenario. There are going to be users who will not choose any of the options. They will just default everything. There are going to be users who are going to fly US domestic only. There are going to be users who will initiate check-in from my trips. And there will be people who will actually say, just send me my email. I don't want it on the device. So it's still a real end user flow. You can show it to a user, have them test it out. The customer can recognize it, versus a first story, which says, search by APNR. OK, the customer can see I'm getting that. But OK, when is my check-in going to be complete? When are you going to actually prove that you can integrate with my check-in API? After this, I'll probably go to, again, this depends on inputs from the customer, inputs from the dev. So this is just one potential split. I'll probably go to check-in for flight after searching for a trip, because search by APNR just adds nothing else changes. Just an extra option to search by APNR, but still complete the rest of the process flow in the same way. And a single passenger, actually, is something I forgot. I don't want to worry about multiple passengers and lots of information, as I'm going to still keep that. Now I'll add on multiple passengers. Then I'll add on pay for bags during check-in, because my customer said revenue is important, and bag seems like the simplest revenue-earning thing that I can do. Then I might move on to select seat during check-in, because my devs told me that the seat map, to show a seat map is potentially very complex, could take a lot of time. We might have to have a really fancy UI for users to play around with a seat map on the iPad, could take a lot of time. So seat map is another thing I might choose. Then I'd go on to, OK, once I have search for trip, then do it from check-in notification. Check-in for flight and get a mobile boarding pass. Get that started as early as possible. Purchase paid extras while checking in. So once you've got something paid working, and you've proved that your payment gateway integration works, the next step is relatively low risk, because once you've proved that one product works and money can come through, next one can come in, and so on. There are obviously many, many more stories involved here, but you'll notice I didn't get into any of the details around traveler variations for different countries, what kinds of paid products are available. That one also just says a single paid extra that you can buy. So just getting through the flow as soon as possible. All right, we'll move on to the next case study. We should have some five minutes at the end for more questions, so I know you'll have questions or comments. We'll take them at the end if you still have time. So the next case study is a lot more complex. Actually, I'd intended to do three case studies with increasing complexity, but I don't think in this size group I'm gonna run through three case studies, so we'll keep it at two. But this one is a very different kind of feature. This one deals with data analytics. You'll get a handout soon. Let me just walk through what this is about, and then you can look at your handout as well. The client here is an NGO that is trying to get transparency to the public about the Indian government contracting information. So any contracts that are given out, even it is something as simple as buying a bunch of chairs for one minister's office, all of those contracts going all the way up to defense contracts, to petroleum contracts, really big ones to small ones. But the government has made all contract information publicly available for the last five years. Who was the vendor who got the contract? What was the rupee value for it? Was it an open bidding process, or was it just something that we call for tenders? For any of those, all of those details are already available. What they want to do is because they want transparency, they want to let anyone on the internet, any Indian interested in knowing how government money is being spent. They want a Excel pivot table-like feature, and I'll explain, for those who might not have used this feature, I'll explain what that means as a visual as well. But let me just move on briefly. Some more context. The data covers all of these contracts issued by the central government, its ministries and departments last five years. There are already five million transaction records. So each time, even if I had a contract with someone who was supplying chairs, but over five years, I told them, okay, 20 times, give me five chairs, more six chairs, more seven chairs, more than I made a payment, that's a transaction. So there are already five million transaction records, but they are expected to grow by 15 to 20% every year. So there's potentially a technical challenge here. Today, everything goes into a MySQL database. MyDesk tell me, I'm not technical, so I don't know, but MyDesk tell me that that's probably not going to work for this feature. It could work for simple queries, but it's not going to work for this feature. Probably the architecture of the existing website is not going to hold up. We'll have to think about something very different in terms of how the data is structured, how the data is read, presented, how users interact with it. And the customer is also concerned about the table load times. So just to give you an idea, each contract, row for a contract, has 150 attributes. So you're talking about five million records, each record having 150 attributes, not all are filled in, but up to 150 attributes, and someone wants to do this with it. So what would happen here? There are some contract, critical contract attributes that we want to make available to users. So they will see they have all of these options. They can make any of these a row attribute, and they can make any one of this a column attribute. So let's look at this specific example. So what have I done here? I have said, show me for every state in which a contract was executed, which was the ministry that gave the contract, and which vendor did they give it to? And what is the rupee value across financial years? So that's in Excel, a pivot table would mean if something has 100 attributes, you can choose and drag any attribute that you like as a row or a column, and it will get all of the data, the cell level, and show you for a particular row value, what the column value looks like. So this is actually based on a real project, on a real feature, that's why it's this complex, or have a look at what the result looks like. The result looks something like this. So when I fired that query, it showed me that in Andhra Pradesh, the Ministry of Agriculture gave contracts worth, or gave money of 20,000, zero and 140,000 to alpha private limited. For this company, this is how much they got in each of those fiscal years. Another company, now that is all, no more transactions done in that year by Ministry of Agriculture, but Ministry of Civil Aviation gave so much money to the same company here. In Arunachal Pradesh now, Ministry of Petroleum gave this company so much money in every year. So it's just a lot of data-rich information, but what people are getting at is rupee values of the contracts sliced and diced in different ways. You'll probably have more, a lot more questions on this feature. Have a look at the handout, discuss that. In this case, we won't have customers. We'll have someone walking around with the mic, just call out questions about the functionality and the value, and I will play the customer and answer them. Fair enough. The question is about, is there a time response time or load time requirement? Well, the customer says, okay, for a complex query, I'm willing to go with up to 20 seconds, but for simple ones, I do want them to compile. I don't want users to walk away from this site when they use this feature, saying transparency is great, but this takes far too long. It doesn't work for me. The other key thing, my NGO is up for funding, another round of funding this year. This feature is the thing that's going to keep me afloat. If I am able to expose this data and it gets buzz in the media and a lot of people start talking about it, I'm likely to have people who will fund my next round. Otherwise this NGO does not exist next year. Actually, so you'll notice in the design that there is a limitation that's been put on how many attributes you can select for rows and for columns. Up to five, up to four or five attributes for rows and one for column, but me as the customer, if you can give me something that does not require that mandate, I would love that. This is something I'm willing to live with up to four row attributes and one column attribute, but ideally I don't want it. Okay, so as we know that the MySQL database might not be able to cope up with the number of entries that are coming in. So we thought that the first we'll try to change the MySQL itself or we'll go with the new, maybe SQLite, we'll spike out whether the SQLite or the PostgreSQL which will work better for the larger database. Then first would be that we'll just change the backend and check whether it is actually changing the load time or not. If it is not going within the limit, then we'll try to index the main important columns of that particular database and try to check whether it is happening or not. So what's your first user story that you can actually demo to the customer or to a user? So maybe we can try with the upgrade of the database and then check. So we haven't come up with the actual user story, but we thought of that, this is the way we are going to progress and then we'll check. Okay, fair enough. Any other group have any different approach to this? So this group I did promise them the last time, so we'll get a mic cube. We did understand that the scalability and performance are issues, but we decided not to address that in the first go. We will address the output screen which you have in the next slide and limit the number of options you're showing on that screen to work with the current platform we have. So virtually, and we don't know the volumes of the data right now, so we said we're limited by state, ministry, one ministry and perhaps maybe all vendors, three years data. Okay. And bring that as virtually a POC for one of these states and be that to be the showcase to the media and everybody else and then build on top of it. So what would you need to have finished for them to be able to know whether you'll have to change direction and architecture or database? So while we do this, we will do the spike in parallel to understand what my platform can sustain, but we are hoping with this minimum feature set we can actually at least put the functionality in live in front of people. Perfect. Okay. And then we build up on the feature set, the filters, in the parallel work, in the second release on performance, third release on scalability and in the fourth release we bring everything in. Okay. All right. We pick up one by one filter that you are putting the performance problems in the first go. Okay. We pick up one by one filter and eventually, eventually let's say, you know, if the project timeline is three months or so, at the end of the goal that you want to achieve, we will have a pivot table kind of thing with all the filters. So after approximately how many stories will I have a table that I can see on the customer, I do need to see what the table looks like after how many stories. For the single state you have right after first story. First story. The first story you have at the table with very limited data. Okay. What are the group in the back that has anything very different from what these two groups have talked about? Or any individual who was working by themselves as well? Okay. This group. Hello. See, one thing we considered is POCs and spikes. That have to be done. This team suggested was to continue with the existing technologies and just to display it. One thing I don't, where I don't agree with this is because this might result into waste at some later point of time. Because what you're doing now you need to redo it if you change the architecture or databases. Yes. So if I want to just display it to my NGO, what I would do is either on the existing database or what is the outcome of a POC, we could have a materialized views just displaying the information rather than dynamically calculating it. This views can be extended to maybe year and state wise, year, state and division wise. So what you're displaying is the information that is present in database and not doing any calculation. So the user doesn't have these options? No. You can't choose. Okay. At initial versions, no. But at the later point, once your output has come from POCs and spikes, you can add in this new functionalities based on the technology stack you are opting for. Okay. Anyone else have any last comments? We saw there are technical forces acting here as well as the functional forces. So we kind of separated the two. The first one was what we did was, we said we'll first deliver value to the customer with minimal one column, one row kind of a thing, but with a limited set of data. This helps get the customer confidence. The next one story was to prove the scalability and the sizing part of it. That's where our spikes and other things would kind of get factored in. And we'll get a feedback from the story as to in which direction we need to steer the technical architecture. So clearly we have one functional then scaling and so on and so forth. Would you like to add some more? No. I think the core idea was that we need to start simple and keep to one attribute in the row, one attribute in the column. And it's figuring out the UI is going to be the simplest bit. It's about figuring out how to actually structure your data to get good enough performance. So yeah, so while we didn't want to do it as a spike and instead want to say, okay, let's ask the customer about one interesting report. If we had only one row, one column attribute, what would you like to see in that and use that to say, okay, does that give you some meaningful data? And then in the next story, we'll add one more attribute. In the next one, we'll add one more column attributes and so on. So sorry, we'll move on. There will be hopefully five more minutes at the end. I'll talk about what happened in real life. This is almost identical to a real feature that we built. So here, what happened was that the dev said, you know what, my SQL database is probably not going to do this, even if it handled the 5 million records today with the growth that you're looking at, it's not going to work. He said, okay, we want to try an Oracle cube. We don't know yet whether that will still work, what would be the ETL jobs needed to push the data into there, all of that. So we have a couple of options, right? We could have spent a month just trying out all the technical possibilities, done spike after spike after spike, done a POC, but the user experience for this was just built by, you know, by the, with the BA customer and user experience person sitting together with some initial inputs from the devs, but nobody really knew whether this experience was possible to deliver. So we spent a month trying to figure out all the technical options to get, you know, approximately this experience, the feedback that needs to go to the user experience folks, it needs to go to the customer that, okay, these are the limitations, maybe these things will work, that would have taken too long. Secondly, we would not have had a table that we can show the customer, so they can start thinking about, oh, people are going to find this useful, or oh, actually maybe this isn't going to be so useful. In this case, you notice that I kept saying, oh, actually everything is valuable, I'm not willing to make any trade-offs. Customers will be like that, right? But, and it's really difficult to have those conversations in abstraction until you can actually show something working. They're probably not going to agree that something less than the end state vision is sufficient. So how do you get something working out there, visible, you can play around with it, see it, and keep layering on till you reach a point where the customer themselves may come to the realization, you know what, I've already spent so many dollars or so many rupees, and what I have here is working, looks good enough, I'm going to release it. Even if they decide they're going to release it to a small set of users, not everybody, internal only, any of those things. So I really like this team's approach of studying with the simplest possible thing. So even if you had to say that, you know what, there were only two attributes available, all of the other attributes were not even visible in your first story, and those two attributes were also fixed as a row and a column, and all the story was allowing a user to do, and no filters existed either, actually. So filters are not mandatory, right? You can choose to have it on overall the data. Just generate the table. You can work with the developers and say whether they want to limit the five million to one million to start with or not. That can be their call taken as part of the story, but functionally, this still works. So if I said, show me all the money spent by different ministries across different financial years, let's say just that was the most important two sets of attributes, generate the table. Oh, it doesn't work. The way we're writing queries is not working. Oh, it works. Now let's layer on the next thing until you reach the point that it's not working. So you want to get to the point that you hit your technical or delivery risk as soon as possible, but you also want that customer feedback to keep coming in. So in the real life case, they actually had something like 25 attributes here, and the customer kept insisting that no, all 25 attributes must be provided to the end user. I need drag and drop. I need six row attributes available. I need multiple column attributes, but they could not even visualize the whole thing, it was so complex. We said, you know what, don't worry about it. This is your first cut user experience. Let's get this started, get it rolling. Eventually, the first release that went live only had something like six or seven attributes here, because when they saw it working, saying, oh, this is valuable enough, I think enough users will like this. I don't want to wait two more months to get all 25 attributes working. Send this out. But that would not have been possible if a table was not being generated and visible from story one. It did happen that we needed to keep changing how the query logic works, because as we introduced some specific attributes that had lots of complexity or the data was not so good, that query would fail or it would time out. But because something was already working, we could keep reiterating. After the first two stories we had to throw away everything that was built because filters would not work in that model. But it was only two stories and 10 days later. It wasn't three months later. 10 days later, you have to throw it away. Okay, that's better than finding out after many months of technical analysis and spiking and all of that, that this thing doesn't work. So this case study was intended to bring out a different facet. Clearly it wasn't a flow of many steps like the last one, but exactly the same principles apply, right? So let's look at what some of those principles might be. Comment? Absolutely, so you could do that as well. So I think this team, the approach is just it is perfectly valid. You wanna try if the developers think there's a possibility of the current approach working, try building something with that while something else is being spiked. But in the real project there, they felt the possibility was so low that it was probably going to be throw away work. So they said, let's take one stab at what the architecture and structure might look like, but let's actually try and make it work to see where that proves out rather than trying to do whole bunch of research and technical, technical data. We'll prove it out as we deliver stories rather than as technical spikes. Okay, so let me, let me move on quickly just see what I had a third case study which I'm gonna skip through, but hopefully from these two case studies you would have seen how some of these apply and I'll take examples from those case studies. Evolving incremental value, in both cases you saw that we were, every time every story was delivering something that an end user and customer could recognize and say, yes, this goes towards my end user goal and you were layering on value as you went along and you didn't need to say for certain that all of the stories will be delivered, you could draw the line when the customer actually said, you know what, what I see is sufficient. Faster, more meaningful feedback. So let's take the example of the first case study. If your first one was only searched by PNR and you would have gotten feedback that, oh, I like how this field works or PNRs, maybe can you allow for some faster way to input it or can you make this button like this? A lot of those conversations then go down to the narrow area that you have chosen to build rather than, hey, is check-in working? Is check-in really making sense to a user using a mobile device, it's an iPad. Are there too many steps? Are they going to be confused? Are they not going to know what to do? What happens if someone changes their mind? None of those questions are being discussed rather than talking about, oh, on this screen, can you show me my search options with this sort option? Can you give me pagination for all the results at my come back? So the lower value discussions happening instead of what's actually going to give you the right feedback for building the best feature you can deliver. Reduce delivery risk. The second example was a clear case. You didn't know what the technology stack needed to be. You needed to evolve it, but you could not find out two months later that you have to throw away everything and build it from scratch. So the way you chose to slice the stories had a direct impact on that. Support for continuous delivery. So now let's say that the second feature, the one with the data analytics, they decided to use AB testing and say, you know what, just the five attributes that we have that are working for a table, I'm going to release it to a very small set of users, only users who have registered with an email address that ends in xyz.com and only release it to them, and I'm going to see how they operate with it. I'm going to evolve my design. Allows for that. Next time you add even one more attribute, just release it into production. You have something users suddenly go, oh, now I can also see a state in which the work was performed. So this approach then allows for that continuous delivery into production, but still supports your ability to only restrict how many users see it if you feel that it's not ready to release to the whole world and minimize waste. So second case study was a great example there. You could have spent two months come up with some architecture, but actually for you find that the customer themselves were not clear about the user experience that they were hoping for. Take everything, throw it away, start from scratch. So the waste that would have happened, otherwise you're allowing for that quick past feedback, you're taking that out. Second waste you're eliminating is, I may think I want everything to be there when it goes live, but when I actually see it, I may decide it's just enough. So I'm going to save my money, I'm going to save the dev team's effort, and I'm going to save everyone a whole lot of pain. So you wouldn't have spent all that time trying to write lots of details about stories that never get played. So any questions on these five? We'll stop at two questions for now. I have one more thing to cover. One of the challenges we come across in continuous delivery is for larger applications which are depending on other applications which they are not ready yet. So we cannot deploy certain one applications stories until that third party applications are ready there. So how would you address those challenges during for continuous delivery, which I think need to deliver continuously, which is production ready, which can be deployed immediately whenever the customer wants. So in the real life case for the first case study, when we were trying to build that check-in flow, that did happen. The APIs that we were expected to consume were being built in a waterfall way and they were not going to be available in line, in step with the way we wanted to play those stories. So we made it clear to the customer that's not ideal, but we then tried to get at least agreement on what the contract looks like. The API contract looks like for every step, saying we know this might change a little bit, but we'll mock out the API with that contract but we still want to actually get the flow working. We don't want to spend time building lots of final features on say search by PNR or a check-in notification. We still want to get to the flow. We may have to mock out some critical steps. Yes, and there will be rework. Potentially the real API looks nothing like the contract, all of that. Yeah, so it can't go, in that case, it can't go to production, right? But then that's not because your stories were sliced wrong. That's because your entire, you know, your entire lay of the land is not quite working in the same way. So the efforts you probably try and make see and see if all those dependencies can also start moving towards an iterative way of working and they don't have to have all those APIs done absolutely right and then deliver it, right? Give you rough versions, you'll get provide feedback. Yeah. Yeah, so I'm just thinking from the reduced delivery risk and the second exercise, what we just did. One approach, which we heard, was about taking one row, one column. What I see that is that you can do that one and then add two, but it's your, I would say you were lucky that you actually got it in 10 days, but what may happen is you can actually do that in two months, like you can, after two months you can realize that, oh, now I cannot add any more columns or any more attributes. So what I was thinking, why didn't you then take a backward approach? Let's say the government were asking you, I want all these 25 fields. Start with those 25 fields, right? Maybe your current architecture works. Doesn't work, reduce that to 20, right? Or maybe slice that to half if you wanna make it quick. 25, go to 12. And then see if it works. Then you would, I would say that's probably, if I just take the algorithmic approach, that probably leads me to the quickest way of finding what's the scalability problem I can come to. Yeah, so there's, agreed. There is no sure shot way of guaranteeing that, you won't end up with an architecture that eventually doesn't work, but what is the option that you can make that lowers that risk? It's not eliminating that risk. In this case, there were too many unknowns. So the reason we didn't go with all 25 was because we were absolutely convinced that when the first release went out, all 25 were not going to be needed and potentially never needed. Customer could not come up with real life end user cases for some of those attributes. So we said, you know what, just because the attribute is available in the database, unless we can even approximate how users will use it, let's not waste our time or spend time trying to make that work. Let's take the six or seven most important ones, try with just two. And after that, you don't need to necessarily restrict yourself to learing on one at a time. If the developer says, you know what, this basic thing works, let's add on the next five or six, let's allow three attributes on the rows and see if that works. So that's that iterative thing with inputs from the developers, how you wanna do it, but the business analysts or product owners still focusing on functional, making sure the functionality is complete. So I have five more minutes, so let me just go ahead. How do you decide on how thinly to slice the stories and what are the guidelines? Sometimes if you go overboard, you end up with the... Yeah, so maybe what I have on the next slide will answer some of that. If it doesn't, I'll come back to it. So I just wanted to summarize some of the, you know, what you might have already learned or observed while doing these case studies. Some do's, in both cases, you notice the focus was on let's trip away everything that's not absolutely required that potentially a small set of users need, but not everybody and get to the thinnest, most bare bone flow that still makes sense from an end user perspective. So there will be at least some users who will use that flow. So even the check-in flow, if you notice, we didn't create any artificial flow that does not make sense in the real world. We said, yes, maybe it applies only to 10 users a year, but it is still a real flow that works in the real world. Likewise, for the second case, even by restricting it to one row and one column, it doesn't mean that that's not, there could be a user who only wants to see across financial years, what was the money paid out to different, by a particular ministry or a set of ministries. So it's still a valid case. So keep stripping out things that, until you get to the thinnest one and that's probably your first story. After that, you layer in the different variables, alternate parts, error parts, any of those things, based on a couple of things. Now both case studies are on purpose, two different things. Even the first one you noticed, I said seat map. The customer never mentioned anything about business value of seat map or anything like that, but there was a technical risk there. There was a UI risk there. There was lots of different types of aircrafts, lots of different types of seat maps, potentially complex interactions. So you're gonna use a combination of these two things to decide what to layer on after that. Revenue obviously was a business value thing, so that's one big factor in choosing the next set of stories. But still, main thing is check whether each user story demonstrates real user flows. Otherwise, the feedback that you're going to get from end users or customers is not going to be as sound as what you would like it to be. Some quick don'ts, I'm sure there are many more. So don't try and avoid if you can, slicing by pages. So if a feature takes seven pages like our check-in flow, avoid making each page a story because the value is not going to be delivered until your seventh or 15th story until you get to the end. Don't slice by architecture layer. So see if you can avoid, oh, first let me do a technical story which will check out the database. Then I'm going to play a UI story which will make the UI look nice. Then I'm going to play some other layer. What again, that will get you is potentially a feature that does not work and a whole bunch of rework at the end.