 All right, my name is Vishal, I will be your facilitator for next roughly 90 minutes. The topic is driving engagement with user stories. Anyone who has not worked with user stories, if you can raise your hands, you all have good. Some basic, basics about user stories is good. The best way to get in touch with me is through LinkedIn and this QR code usually will take you to LinkedIn, but because it is a projector screen, I do not know if it will scan or not. It will scan on my laptop if you want, there will be one QR code towards the end as well or you can just search for Vishal Prasad I N and you will get in touch, all right. Just a quick agenda of the things that we are going to do and it is going to be a slightly fast paced session because there is loads of things to do just to give you an idea. This is actually a one day workshop that is condensed into 90 minutes. So there might be certain times when you will be running out of time, do not worry about it. That is when you take care of the time box. So I will keep on telling you when your time box expires. The only request is the law of the facilitator, so please listen to me otherwise you may miss out on certain things and I do not want that. And also if time runs out and you still have some things that you want to discuss, then there is a parking lot that I have created right over there. You can just put your points and put it on the parking lot towards the end of the session, we will take the parking lot. Also a good thing there is a coffee break after this. So two things might happen, either you will have time to speak with me or if you are sleepy you will get coffee, ok. So both are good outputs, let us work towards that. The entire session is divided into four parts and I have something that you also need to pay attention to. If you see over here at the bottom, I do not have slide numbers, that is actually the time, the time when we are supposed to end this particular slide and this is going to be on every slide. So that we are on time and we finish by 255, so we will still have 5 minutes for any questions or any wrapping up parking lot stuff to do, ok. So in case I am overshooting, keep me accountable and tell me whenever it is happening, alright. It is going to be an interactive session, ok, so be ready for it. So four parts, we will do, each of the parts are up to 20 minutes, we will do part one, we will do some unlearning, so that we can start learning the new concepts, then we will get into some refinement of whatever we have learned. In the third part is when it might get a little advanced for a lot of folks, if you have not done it before, so we will get into specification by examples and then towards the end, we will end with some general guidelines that you need to keep in mind. It is not to say that you have not been working right with user stories, of course you have been. These are concepts where I personally feel that it is a very powerful tool and we under utilize it quite a lot. So the entire session is around how you can use this tool to interact with any stakeholder that you want. It can be anyone from the CEO till your team members and you can utilize these tools to engage them and then see how you can build products around it. Sounds good? Beyond time? We will go ahead. Everyone has post-its on their tables, sketch pins, post-its, at least a few. You might want to join some other table because we need at least three people on each table or you might get someone from another table so that you have three. So let us move on to part one. Someone who wants to speak up something like expectation setting before we dive in, any requests, anything you want me to keep in mind. So let us start with the very first thing. What is user stories? It is going to be a time box activity. So I will give you two minutes to discuss on your table first according to you what do you feel are user stories and then we will discuss over here. All right? So two minutes only for you. Go ahead and discuss what according to you are user stories on your tables. Get to know each other, ask your names first. No, as long as you discuss it is fine. I will ask you anyway. You need to be on the same page before you talk to me. All right? Pense down. I am assuming all of you on the table are in sync. Like you agree on the table what user stories are. Fair? Let us hear it out loud. What are user stories? Anyone? Yes? It has got a persona which starts with and it has got a template which you have to write. So there is a template to write. It is the smallest unit of work. It has a Y. Smallest unit. So it has got an MVP part of it. It is an incremental order. Smallest increment. And it has to be vertically sliced. It has to be vertically sliced. So that it covers all the layers of the component based. All right? It is not component based user. From a component feature perspective. It can be. But it is not. Okay. We have different way of looking at it. Why? It is just a conversational requirement. It is a conversational requirement. It is a conversational requirement. That adds value to the end user. And it could be at any level. Okay? You could say that user story is at a high, very 50,000 feet over view level. Yeah. Which could just be like in a save game. I want to have a things processing. Why I want to have things processing? All that can be just as a conversation. It is not something that a business user can understand at the same time. That same language developer can also understand what is being needed. They can go ahead and make more formal out of it. But initially it is just a conversational requirement, which adds value. Okay? So it is a conversations starter. Yes. So it's a conversation starter can be at multiple levels can get the highest level till the deepest level One more thing you said that other information can be added Fair let's take one more and then we proceed a single piece of functionality So vertical slice that brings value to your customer one single piece of functionality None of those are bad descriptions. Okay, so at some level all of these are accepted How many of you use a project management tool? Use let's not name Perfectly fine, but there are some that we use Do you see any harm in using any of these tools what? They try to move your mindset with the wordings that they are using in their tool. So like his Our tables description is it's a conversational starter Which is fair right but because I use a certain tool in my tool. It is said that it is the last level of Granuality from the requirement stage. So I think it creates a perception in the person using the tool that this is what it is supposed to be fair so kind of molds you into some kind of a template and Maybe at some point of time You start using their vocabulary Like I'm I'm pretty sure there are a number of folks who call out Jira stories I have no idea what that is because Jira is one of the most widely used tools. We end up saying Jira stories. It's fine There are typically two things which I dislike, but we'll come to that a little later Here's my definition of a user story. I'm saying in a written form It describes a functionality. That's valuable Either to a user or a customer having said that this is what I'm saying in a written form What you said sir is that it is a conversational starter How do you differentiate the two the written form and the conversational start if you have Conversation So the way I look at it is it's a placeholder for a conversation to happen So it's a placeholder that you write something on a piece of paper then the conversation happens after the conversation You usually tear off the paper Tear it off burn it put it in the dust You do it, right? Yes. No. No, why not? Because you usually have a tool and the tool has a story to you of everything that you have been doing So yeah, you don't do that Think I will see what to do about it But for now I am saying that a conversational starter or a placeholder is probably something that after the conversation you can discard So even if it's a story you can discard the story So whatever happens like production you said whenever the time comes tear it off throw it in the dustbin It's not needed any more We don't usually do that Let's take a simple example, how did he find the food describe it a bit which things did you like? Okay Okay, what is it? He had more desserts today Last day nice Had a bad job of beloved I want to be invited next time That's a good conversation So somewhere on a sticky I may have written. Let's talk about lunch. We have spoken about this I can tear off that sticky and throw it away and move on to the next discussion It's a conversation. It's a placeholder There is going to be an end and something new is going to start You will have to keep the context in a different way And we'll come to that also. We'll address that as well in the third section. We'll discuss Good example for parking lot. Let's put it and we'll discuss that But a fair point. Okay, so we have historic view. We don't usually tear off our tickets and we don't throw it in the dustbin By the end of this talk or this workshop, I Hope that you will start doing that even though you have Jira and I don't know how much that will work out or sprints so But let's say that is the intent of this entire workshop to see if we can slowly move towards that Let's do the first activity You're going to get three minutes three minutes per table or group of three however you want to do it Someone said that there are templates The story has a template you need to put certain values in those templates. That's pretty much the exercise You have post-its with you. You're going to identify as many components in the template as you can When you are writing a useful utility All right, even if all the tables have some duplicates, that's fine. That just reinforces our belief in it and Whatever you can think of everything from the narrative till acceptance in scope out scope You are whatever you can think of for your team to develop your software the components that you add in a user story Simple exercise all good Three minutes I I I I I I Good so start saying what did you find the shout out Start with the persona, okay journey Acceptance criteria Estimates Assumptions Just mention the component What and why we are doing Extensions Estimation, okay What matters moments that matter okay The parent feature all right middle table anything Part conversation confirmation, okay dependencies Okay, I'll help you out in scope out scope rates Mosco, okay, Mosco What more I Don't worry about being right or wrong at this time just say the components come on Fix version Is the original story of spring story, okay all of you now pay attention to me Okay, if you give me so many components in the template Tell me what is the difference between any other requirements document functional specification use case Technical specification whatever you must have thought of and users to use what's the difference Nothing is more organized than a long That's why there's no difference that's a problem right then why create one more thing to do But you just tell me a difference between use cases and what you have Alternative flows we have what preconditions someone said alternate Someone said alternate flows he's saying all that clothes are not there. That's fine. You have it in your stories. That's all Okay, so Probably the difference We Have been taught or we have accepted a way of working in our Organizations in such a way and we haven't questioned it for a very long time and that's why there is a difference There's definitely a difference. We just don't know what the difference is And even if we know the difference because we may have written we may have read some book We don't implement it when we go back So let's call it up Ram said right there are three things that we want to focus on when it comes to user stores There is a card a card that you can tear off after the conversation is over The card is the thing that keeps it small. That's another thing that I do not like about tools Because the description field of the tools can help you write a book So a card that means it's small. It's forcing you to be small It's a conversation starter. So once you have written something on a card, you go to someone that someone can be anyone Anyone from the CEO to the CTO to your team members. You have a conversation around it And if there is an action Associated with it as I think Ram you mentioned if there's an action associated with it We need to confirm on what that final outcome is going to be So there are three things that we need to consider the card conversation and the confirmation confirmation Basically are nothing but tests Something that most of the team members do not write or do not identify While we are working with user stories. You may do it during development but not beforehand and you'll see how we can get there That's a confirmation part So in short The user stories do not have a structure As long as these three things are fulfilled You all may be using a template called as a I want so that no good There's nothing bad in using that template having said that it's just one way of writing stories A story can be as simple as three words. That's all You can also simply write one word as long as the entire team understands There's a concept called metaphor as all as long as the entire team understands what it is That's a conversation starter. That's your story One sticky on the wall. So the first thing that we need to unlearn is Start putting all the information that you have defined as a part of the template Template is there to help you not for you to add in mandatory items Now I do not I won't say that it's your fault because there are a lot of Organizations that would create these templates and tools and there will be certain sections of the tool which will be marked as mandatory Just put in any value that you want and move on it Don't spend your time on worrying about it as long as you have these three where So we go on time so far Little bad, you'll see so let's do this Okay We gonna write a story Now that you know that there are only three things that you have to consider when you're going to write a story Think of the card Think of the conversation you want to have and I need some confirmation as to how you're going to test This functionality is done or not card conversation confirmation. Okay Three minutes in group of three So if you have four is also fine But if you have a good to group of three, that will be nice because we'll utilize this again in the next exercises The three pointers are here to guide you if you want to just pay attention to the screen once The three points over there are to guide you so begin with a goal What is it that the user wants I kind of have mentioned it that you want to view your emails That's a good goal to have Have a conversation as to How you gonna view that what's gonna happen? What is this entire functionality that I have to build and then come up with some tests It's three minutes. You won't get everything. That's fine. Whatever you can do in three minutes Fine Go for it. You're writing it in group of three is group of threes Okay, four is fine Okay, pay attention now I have a change request Folks pay attention. I have a change request You can So depressed what wait? Not more than two stickies your entire story Not more than two stickies. I'm giving you a leeway not more than two stickies. Okay, not more than two stickies Hey pens down Hold your conversations Please confirm you're listening to me. Hey come on law law of the facilitator. Look here Folks don't fight. It's a workshop may I Keep those stories safe because we are going to use it for the For one of the next exercises. So keep it safe and show that it's not Getting lost in conversation Translate let's move on to part two Okay, so what have you learned in part one quick recap three C's And have all the templates also in place, right? The template should be kept properly. Who said That's the whole point get rid of your templates Remember three things has to be as small as it can be written on a card. In fact, if you are starting your You're starting with stories And if you have a tool It's better to first start writing things on a card and then putting it in the tool Over time you will build that necessary muscle memory to start doing it directly in the tool But just to build that muscle memory first start writing things on the card and then moving it to the tool Right. So three C's as long as you remember that we can go to the next section. So why stories? Fine. We said it's one more way of getting your requirements in place. You have use cases you have Specifications functional documents. Why stories? What's so great about story storytelling is the right Yes, I think it it's good to say that writing is pretty much the last thing that you do a lot of things that happen in between But you still have like what four questions over here that I've written, right? Why even change if you're not using stories Why even move to stories? Why write it on cards? Why hold conversation? Why not continue writing requirements document? Okay, so it absorbs change better It's incremental delivery No one reads 200 pages, okay We are good at understanding stories. The absorption is better Okay, we'll do one conversation at a time You're slightly better time to clarify. It's a flow One second Sorry, it brings in more engagement. Okay writing. Okay It clarifies certain things, okay, I don't know I'm kidding. So let me ask you a question at this time because I have interviewed like many many people and this is are you usually Ask them what's your process about working with requirements? Many a times I have heard that they say that hey, there are some BRDs which are written They go for a sign-off with the customer the customer signs it off then the documents come to us Then we split it into stories and give it to development Have you heard this before? Yeah, have you done it? Hmm if you're going to adopt something Need to stop something else Otherwise you're adding more to your process. It's not going to help So if you want to make your process lightweight by utilizing a lightweight method Then you have to get rid of those which are not lightweight So if you say that you're going to adopt user stories, it needs to be user stories across Now that brings other questions as to how do you get sign-offs and everything? Unfortunately, this is not the workshop for that but there are ways of doing that But let's say that's one of the reasons like if you're taking a lightweight method you need to take your lightweight method throughout Okay, so fine. We have stories. It's one way of doing it having said that Can we be agile with use cases use case documents? You can be Okay. Yeah, so if there's any hesitation to say that you cannot be agile with use cases the The notion of stories are a promise for conversation Came from Alistair Coburn. Who's the signatory of agile manifesto? And he's also the one who's written the book working with effective use cases in agile teams Patterns on use cases. Okay, so he is known for it So no one is saying that if you are an agile team, you have to move to stories That's not the intent but if you're going to work with stories then you need to embrace the entire aspect of it So that it is more effective. So I do have a video for you over here We'll see that video and then we'll have a short discussion. You may have seen this before You're not making any sense. Sorry you ruined it on purpose. He knows how to make one What's up the internet? You know what? I'm hungry. I could really go for a peanut butter and jelly sandwich Do you guys think you can write down some instructions and teach me how to make a peanut butter and jelly sandwich? Yeah Then do it. I knew we were gonna do this. I heard dad talking to mom Choke yourself on my hand Sometimes they do what you tell them Step one get two pieces of bread out. Got them Get a butter knife and get some PB. Take one piece of bread Spread it around with the butter knife. No dad with the peanut butter. I'm just doing what it says It says take one piece of bread Spread it around with the but with the butter knife. Hold on get some jelly Rub it on the other half of the bread It doesn't say to do that put the breads together on top of each other take a big bite I had to I had to make it extremely specific. Oh good. I'm starving Take two pieces of white bread out of the bag Take the lid off the jar of peanut butter Get a butter knife and stick it inside of the peanut butter jar with the knife scoop a bit of peanut butter A bit means a lot In my world spread your scoop of peanut butter onto one of your pieces of bread with the knife All right There we go doing better than before though open the jelly jar squeeze it on to the other piece of bread Done closer Get two pieces bread get some peanut butter take the peanut butter knife open the peanut butter put the knife in the PB Get some jelly open the jelly Squirt the jelly onto the bread take the butter knife with the peanut butter on it Wipe it all over the piece of bread. That's blank take the butter knife rub the jelly all over That's all over Put the two pieces on top of each other Take two pieces of white bread out of the bag Take the lid off the jar of peanut butter get a butter knife and stick it inside of the peanut butter jar With a knife scoop some of the peanut butter out of the inside of the jar Spread your scoop of peanut butter onto one of your pieces of bread with the knife Squeeze some jelly onto the other piece of bread spread the jelly on the bread with the butter knife Put your two pieces of bread peanut butter and jelly sides together done Get two pieces of bread get some peanut butter get some jelly open the peanut butter get a butter knife put the butter knife in the peanut butter Take the butter knife out of the peanut butter Take one piece of bread and take the butter knife that has the peanut butter on it spread it all over the top of the piece of bread That's the top Squirt some on another piece of bread take the butter knife rub it all over the top of the piece of bread You want to take your sandwich with you I'm glad I made that for you Yeah, go take that one to mommy Take two pieces of white bread take the lid off the jar peanut butter get a butter knife and stick it inside of the peanut butter jar With the knife scoop some of the peanut butter out of the inside of the jar spread your scoop of peanut butter onto the face of one of your pieces of Bread with the knife squeeze some jelly onto the other piece of bread Spread the jelly on the bread with the butter knife put your two pieces of bread Peanut butter and jelly sides together done now eat it Not the best. Well, you made it. I think qualifies That's a win Well, Evan and John did that go as you expected? Yes, I expected to win Well, you sort of won, but really I feel like we were all losers Is that fun at all? Yeah, there were there were at least a few points where it seemed like Evan was kind of having fun What do we learn from this video not write stories? Thank you for coming for the workshop. I'll see you next time How to not write user stories, okay? They could have shown how to make this is what you want So a developer will know what to make if another developer makes it and gives it to them Probably okay ask the customer what they want, okay? Sorry Details you need to get into the details Ask for feedback, okay? So actually a few months back this video started popping up everywhere on social media with the tagline that You can only you have to be extremely detailed with your requirements Otherwise, you will not be able to build whatever you want. So your stories need to be precise in Details in short the job description should say you need to get a few people who have OCD They need to write your requirements and give it to the developers. Otherwise the developer is going to be like Josh I'm going to say I'm just building whatever you told me to that's crap You're not supposed to dive into the details on paper I rethink this entire thing All Josh wanted was a peanut butter and jelly sandwich if the two of them would have sat in front of him and Told him step by step what they expect they could have basically made it in at least not in six minutes It could have been in what a minute maybe Made and given to him. See usually when we are working in teams Usually when we are working in teams, everyone has different roles okay, so Our developers are useless. They are in the habit of taking things on the plate and then giving it back to the product owner You don't write goods. I I hate my developers. How to validate our stories are complete So, let's do that. Let's write a story Together the customer gets the peanut butter and jelly sandwich when they order it Here's the acceptance criteria What's the difference between what you read versus what you saw what you saw was someone explaining the steps of how you need to do Something in the video what you have here is the outcome that is expected I don't care how you make it. That's what we call as tests The first one says your sandwich is gonna be three inches wide four inches long Objective tests. It cannot be anything beyond that Nothing less nothing more Thickness is missing. Okay, we'll refine the story. We are always open for discussion Sandwich has to be exactly two pieces slice one slice two slice one has hundred grams of peanut butter Slice two has hundred grams of jelly The customer doesn't get peanut butter and jelly on their hands. That's a non-functional requirement. I'm not saying this is a perfect story Probably if you give this to your developers They might still be able to make you a sandwich If you want them to make the thing to note is The belief is that we need to be detailed You don't need to be in fact Have you ever complained that whoever writes requirements in your teams? Maybe your PO maybe your BA whoever They are bad because they don't give everything in detail. You hear You get lots of details if they don't give you details will you complain? But if they don't give you details, they're actually the best ones to keep that's not open-ended. We'll talk through it Yeah, availability is outside the scope of this workshop But yeah, I take your point work towards reducing the so The first thing reduce the details have more conversations because you already said it's a conversation It's a place hold of conversation next one The creation steps are to be left to the people who are skilled to implement You can tell the chef What do you want you can't tell the chef how to meet your requirements your story is whatever it is It is telling you what you want with some objectivity behind it. That's when we call it as tests You can't give the details. You can't give the steps. How many of you have seen stories where it says The screen loads. There are two text boxes on the screen when the button is clicked Something happens. Have you seen that story? cool Bad stories to have too many implementation You will still need tests for that. We'll come to that later Finally the acceptance conditions must be provided and They are to be provided by the customer or the user of the system If you are not getting the acceptance tests and the acceptance conditions from the users You will always face a challenge So keep this in mind if you want to make peanut butter and jelly Moving on. Let's spend a few minutes. Have you heard of invest? Maybe not five minutes a little less because we are running a bit late heard of invest We're not going to do anything with invest in this workshop But just what have you known what do you know about invest? It's an independent piece of functionality. It's negotiable, which means you can slice and dice it as long as it's a vertical slice It's valuable to a user It is testable Estimatable, it's testable So many of us miss out on the testable aspect of it. We focus more on the steps We focus less on the testability of it. That's precisely where we want to move towards Ultimately, your stories need to have tests because if you don't have tests Then you will not be able to fulfill what you do. Everyone okay with invest anyone who's not heard of invest All of these slides are available on convention. There is also a bunch of references in the description. You can go and check out the So let's move on to an exercise and this is where we come to part three specification by examples more precisely specification as tests When we work with requirements, especially when we are working with huge documents There's a lot of emphasis on the steps Moving away from it towards scenarios There are scenarios that will occur when your customers are working with the system What should happen in those scenarios and every scenario has a test case that needs to pass In order to be accepted. That's your acceptance test So specification by examples It's a single source of truth It doesn't matter what your role is Can be a CEO you can be the CTO the VA the developer the tester whoever Everyone understands a test case It's a scenario. It's a single source of truth for everything You define the expectations objectively, which can be validated Test cases are always objective, right? You have test data associated So it's objective if they pass the story is successful if they don't story is not You assure the teams and the business stakeholders and the software that is built is being built for the right purpose Because your test cases fail that means the software is not achieving what it's supposed to achieve and the entire aspect We also discuss rates earlier, right? Rates and other things that you might add into a story A story is not ready Until the time you have the test identified if you have the test identified it is ready for development You may not have all the test identified if you have assumptions and other things in which case you cannot develop that story You can slice it so that you can develop a part of it if it still gives you a good value Gives the customer good value Otherwise if you have assumptions and you don't have all the tests in place you can't so your stories are not ready So let's take this a step ahead. How do you identify the test cases? That's where the three amigos come into These are the three aspects or the three viewpoints that you require for any requirement to be built There is a business viewpoint There is a development viewpoint and there is a testing It doesn't matter who's playing this role. You need the three viewpoints For the ease of it. We just assigned roles to it. So you have individuals who are doing this regardless as long as these three perspectives are being Concerned You are fine. So we'll do a small role On each table you will be in a trial So just assign yourself a role can it's fine. It's not going to change your job description assign any role to yourself Okay, so someone has to be business Someone has to be developer someone has to be So I'm just going to call out and raise your hand who you want to be it's not like a group table activity You're gonna be over here at every table group of three Anyone who wants to be business each table at least one each table at least one two is fine Remember your roles. Okay, business business. Okay, remember your roles because you have to speak after this developers every table at least one testing Every table at least one Okay, every person needs to have a role. So if you don't have a role Then we'll have to get into some other kind of exercise afterwards fine So we are doing a role play you need to pay attention on the screen everyone here Some things on come up in the screen. I'm not going to say what I'm not going to give any cues You'll see your role. You'll see some things written over there. Don't worry. The text is perfectly fine that you can read out loud You just have to read through nothing else but loudly so everyone in that role will basically shout out loud Whatever you see on the screen Louder and in sync We have three types of parking lot Okay You Okay You'll have to be slightly louder at least The room should be louder than me Okay, so let me help you out There's two last two slides are exactly the same You don't remember it. It's fine. There are conversations that happen. This is an example of a conversation that they went through the entire thing or not What is important is what you see on this screen Three folks who have discussed a few things about a parking value problem They've identified some examples and now those examples are something that they are going to put out here This is test data. You park for 30 minutes. You pay $12. You park for three hours. You pay $12 You park for five hours in one minute You pay 18 And if you park for a week, you pay $126 No seconds in this. Bad programmers Okay Can this be a story or is this a story in your viewpoint? This is a story for me Reduce it. It's fine We started with templates I'm saying this is the written form of your story If you have this, you know what you need to achieve At least those who are going to program know what they want to achieve This is a story. You don't need a template What you need are tests There's also something known as behavior-driven development Heard of it? A person named Dan North came up with it And the philosophy behind behavior-driven development is that you're capturing the behavior And the behavior that ultimately gets captured is as a part of tests Now over time, there is something known as Gherkin's scripts That we have started using These are the keywords Using these keywords, you can determine how you want to build your stories But there's a catch Just by using the keywords, you're not writing good stories You still need to know how to write good stories Writing is still the last part. How to utilize stories So to give you an example, you can still write Given the page is loaded on the screen When I click on a button, then the movie starts It's not a good story because it has steps Can you convert that into tests is the question When someone wants to play a movie, there are many things that can happen Maybe your server is not reachable. What happens then? Maybe your bandwidth is low. What happens then? Will the resolution change automatically? What happens if you go offline? Those are the tests that you need to catch So, you had written a story in the beginning Take a look at that story After two slides, we are going to come to it But before that, how many of you write stories for user authentication? User name passports To view your emails, you need to log in first Probably user authentication is the worst story that you can have But we are still going to use it for the purpose of the workshop The reason why I say they are worst stories to be discussed or had Is because you all have cell phones You got your email applications on it Will it be a good experience for you if every time you click on your Gmail application Or whatever you have, that prompts for your password That's why SSO is there So if you write a story that talks about the user name is captured The password is captured User name password does not match what's my error message Or something is blank, something is not blank Yes, they are test cases that you have to consider But there are different ways of utilizing those stories An authentication screen in itself is of no use It needs to take you somewhere So what I have over here is an example Of their authentication can be used Since you mentioned SSO, SSO is there This is a user story for authentication Not the entire authentication but a part of it This is how a user story will look If I am utilizing DDD or Gherkin to write Even before I reached to this point to write We did the three amigos The three amigos is the exercise for identifying these test cases Everything that you see in double quotes is basically test data And everything that you see under examples is test data as well These are just two different ways of writing it Scenario outline is like a template We discussed template earlier So you can put your templates and you can give the test data Which is a bunch of test data like the valet example Or you can write something in double quotes And that will still be valid as a test case This is a user story I am not forcing you to use user stories in this format When you go back as long as you have the test identified That's specification using tests or examples Earlier when we started we said That you can tear off and throw it away Then where will you find the requirements in the future If you want to go, someone had that, you have the question Your tests are your specifications You don't need to show the specification to someone who is a CEO A developer needs to know what has been made Or what was done or what was discussed Your code and your test are specifications Clean code and tests That's what you need That's the reason why we said That you can tear it off and throw it off Because you have taken care of it once you have put it Now the story that you wrote earlier This is my version for it Similar? What's the difference? As a difference between what you wrote and what you see here But still it has a certain kind of branding It's not a complete story Very specific, isn't that good? Again that point that it gets too detailed How is it detailed? We started that, you said not put so much It's more technical The labor and management Anybody can understand Anyone does need to understand Three amigos need to understand Why? In a group you only don't have people with technical background Sometimes your BA is sometimes You don't get into things, you do certain realities That is the reason I think Sometimes gherkin language and gherkin is simple You can use So let me come to that by saying that It doesn't matter whether you use gherkin or not If this is something that your team is not able to identify Your teams are always going to fight on what was actually We can have it as a part of the acceptance criteria Or test data and all that But when we are putting it as a conversation starter This is not a conversation starter This is the end product of the conversation This is the end product of your conversation Most likely the conversation starter is just this There is a small question, how does it develop for us? This is in web, but it is in app So I can view in different ways Your stories need to be reusable because the outcome is not changed You can authenticate yourself through text Through biometric, through voice, through an access card Your ultimate thing is still going to be the same As long as your ultimate tests are the same It doesn't matter We do this kind of But it will be an acceptance criteria This is the answer So in gherkin you have description in one place And then acceptance criteria These are acceptance tests Correct? These are tests How many times has the developer come back and said This is what was written? Here is an example of getting rid of those discussions If you have tests which are objective Those are the problems that go away But there is a much bigger problem that goes away Which we will cover in the next section Not a question I think a lot of people use this for their development But even for the product owner or other the business When they realize this is done This is complete, we cannot work to the next We are simply saying that this is a language For you to develop a software If you don't wish to go till there It's fine But this kind of answers all the problems that we have Yes? This is just a quick example I want to understand that this is a one big story Where we keep every organization pushing to both A smaller level, smaller story, smaller story around it If I keep this to one developer to work on I am just giving an example He will take a month or so to complete this I am just giving to understand that When we split this what challenges comes out So then my test cases have been split around it So then who will test together Then repeated work will be there Every team is going to have a different definition Of what is bigger and what is smaller Your team can say that I have a weekly sprint So this is too big So big and small is relative You find it big, go ahead and split it There will be a limit to what you can split Till the time it becomes larry But you wish to split it, split it Now you made us my conversation starter So I used the conversation I arrived here So when it's splitting, we all talk about vertical slicing How can you give an example to slice this in a vertical Parting lot afterwards We will split this See I am not here to convince you that Go back to your organization and start doing that I am just giving you an example of how your problems go away That's the entire intent So let's do some housekeeping discussions Here we are here, you had a story written I had a different variation to it Both of those stories will have some aspects to it There are still some things which we want to consider as good stories Let's go through that list Start with a bone, goals are good to have Ensure that invest vertical slice We already discussed that, many of you mentioned it Write close stories How do you write close stories? Tests The tests basically make it close stories This is from a book by Mike Kohn That was written way, way back I am not even saying this At that point of time Mike Kohn said You need to put constraints So in the earlier story you may have seen I said that the page loads in 100 milliseconds That 100 milliseconds is basically a test case Which is automated So if it fails you would come to know Keep the UI out As long as possible Your stories need to be in a way where The person or the people who are going to implement it They get to decide what is the best way to achieve it It may be UI because that's usually the way How we develop applications It's not necessary that that's the only way to do it So keep the UI out as long as possible It won't be forever As long as possible You are going to have stories that talk about How your screen is going to look The stories become too descriptive From a viewing perspective There are better ways to show that You can create screen designs and mockups And make it available to your teams You can still convey the same message But in a much better way But what you will cover on the story And on the testing end Are the test cases that apply on that UI Having the UI in the story does not No, I am not keeping it separate These are still supplements These are supplements Another story to integrate No, we don't need another story to integrate it So usually the old training years How we say you start to do the hamburger technique So the UI has to be integrated Even if you do the workflow techniques Very simply put Very simply put You are not going to write another story for UI That's not the intent Once you have your test cases You may have someone who is creating the UI Or discussing the UI You are just going to get the UI designs from them That's all, it's not going to change your story The story is still going to be the same Which is a part of business The three amigos discussion You will have it as supplements It will not be written as a story It will be supplements You don't need to write that You need to click on a certain part It will be as a part of your supplements It will be there You are not going to write another story for UI That's not going to happen You need to have the user roles Instead of users There are loads of supplements that come There are UI guidelines that you have to add There are some compliance docs And these are always available These are usually applied to the complete system So regardless of what you are developing That's like the underlying rule That's always going to be there That does not change One card is written for one user And an active voice You don't have more than one user Being covered or one functionality being covered And it's still a promise of a conversation As long as you keep these things in mind It's perfectly fine Do you have a definition of done? What is that? Let's first bring something out of the table A definition of done is for the entire system Not for a story But you still need to know when the story is done If all of your acceptance tests are passing With automated tests Your story is done So quickly to go through It's a set of automated tests Which are passing May or may not be applicable to individual stories Because definition of done is more at a system level And finally, it must be executed after every count That's a part of CI You'll come to know if something is failing or not It will be immediate At the same time We also discussed definition of ready We already said Your three amigos Identify the tests together If all the tests are identified That fulfill the purpose of a story You are ready for development Which means that if you have assumptions You're not ready for development This is not a sign-off process This is something that your team is deciding And your teams will have much more test cases Than, let's say, a CEO of the organization So it's not a sign-off And definition of ready is also in some sense an anti-pattern The reason why it's an anti-pattern Is because you will identify more tests When you start developing If you identify more tests You're going to go and add during development So your story is never really ready for development There is an ongoing aspect to it If you believe at a certain point of time That you have everything that you need In order to build a story You can go ahead and start building the story But the biggest thing that I get from this entire process Is a zero-definition policy You can actually have zero-definition in your system If you take this approach Do you believe in that statement? No No? I've heard So let's take an example I haven't seen it ever so But you haven't done this kind of story as well Okay So let's see what happens In a typical context A bug comes in production It comes with the development team The development team does a triage What's the purpose of that triage? First identify if it's a bug or a change request Because scope team happens Then see if you fix now or fix later So even if a bug comes during the end of the iteration And let's say there are two bugs You might say one is minor One is major, minor You push it, major And you fix it, something like that And these are usually the things that we do during triage The clue is That we can sit in a room and identify If the bug is minor, major For a user It's a change request Whatever it is For the user, it's something that's not working Does the user really care about your definitions? They don't If the user comes and complains Hey, this is a bug This needs to be fixed And you say, yes, it is low in our priority Because it's minor bug Maybe that person does not agree to it Sure, that's the reason why we have product owners And they prioritize everything But the point is that you're not supposed To have bugs in the first place And the ethical software development teams That we are We actually take money for solving bugs That usually does not happen in other industries So if you buy a car And the car is defective At least in the warranty period You get it replaced for free But if there's a bug in production And you're fixing the bug On a weekday between 9 and 5 You actually get paid for it Ethical business, right? It's a joke Don't worry so much Don't take it hard But that's what we're trying to do We're trying to get into a zero defect policy The idea of a zero defect policy Is that everything as a requirement Is a test And the tests are passing So if your tests are passing Then the functionality is complete If ever in production A bug is reported That's simply a missing test At any given point of time It's always a missing test It doesn't matter what you call it You call it a missing requirement You call it a change request You call it a bug It's nothing but a missing test When you think from that ideology That's when we come to something Known as a zero bug promise Which means That when you are building stories In iterations or in sprints And if one of the test cases fails That story does not go into production You don't need to discuss If it's a major bug or a minor bug It's a bug It does not go into production Till the time that bug is resolved Or in better ways to say it That test case is addressed And when we do that And we fix the missing test That's the only way to call it out That we are a bug-free system This is again not a philosophy That I am stating This was stated many, many years back If you go on ConfinGen The details of the page You will find this talk The talk is currently there on Aja and Alliance This is a way of working When you work with tests As with specifications Then the tests ensure That you do not have bugs The biggest takeaway of everything That you can do If you move towards acceptance Test review and development As I said The QR code may not scan Because projector But you can connect with me On LinkedIn And these two We do have six minutes So any pending questions I don't see anything on the parking lot But any pending questions Even challenges Perfectly fine Shoot Keeping UI out Anything around that Why shouldn't we have UI in the storage And we are saying that Keep it as long as possible Not however Yes When you say keeping UI out You refer that You want to have a template Some filter UI around that Use that for reference To create a story I didn't get that question No, you said that Build a template UI template Something how the base looks like Or something like that Use that to That's something that Your designing team can take care of Yeah, that's what Based on that We are expected to create a story I'm just asking you Your stories are your tests So there will be some tests That you need to fulfil Okay So let's say that The tests that you want to fulfil Just as an example Is user registration Now when you want to Perform user registration You need to take care of Your mandatory data And you need to ensure that Any Any Test data that is going to Fail or pass Is your taking care of Fine Once you have taken care of that You can decide How that UI should be represented Then you mentioned It can be a website It can be a mobile app It can be anything Your test case is not going to change So first decide on the functionality Once you have decided on the functionality Then decide what is the best way to do it When you decide on the best way To do it The answer might be A UI But what kind of UI So that question of What kind of UI comes Much later in the conversation And that's the idea Of keeping the UI out For as long as possible First start deciding What is it that you want to achieve And slowly and steadily You will move to that You're not saying keep it out forever But defer it as much as Don't start with that Don't start by saying I need a website Start by saying What are we going to achieve And then later on come to that So this time the same question around It's UI part The sliding part comes from I have a UI I am building a story Around the test cases Around that UI I want to slide this into the model So I am UI Developing my UI Creating my same work Under what functionality That's around that Now every developer Every people are asking me How to slice it Can I use it Create a mock UI Then add a new API around it In the back end So it kind of There will be some context I'll have to understand from this Very simple I wanted to understand In your example How can a slicer use a tool Your story When we talk about vertical slicing And it's easier Said than done At times Is because When we look at textbooks And we talk about vertical slicing We usually explain Through the terms of UI So when we create that vertical slice Cake Picture that you see It shows a vertical slice means The UI is covered The middle layer is covered And the database layer is covered That's what we have learned Theoretically that is correct Take that In a different aspect If you would be writing software for Alexa There's no UI Will your story be vertical sliced? So the idea of a vertical slice Is that it needs to go through An entire piece of functionality In all the levels So if you have different teams That are doing different job And you take a part of the story And give it to them That would be wrong Because the story stays In the same place With all the test cases And the teams need to come together And figure out how to build it So think of vertical slices Ensuring that every aspect Of that functionality Is covered and it's not missed That's all So that's the idea of vertical slice I know textbooks always tell us UI, middle layer, and database So that's how we have learned it A vertical slice simply is Your functionality has to be Going across the system I understand my point In your example I see that as a bigger story Which is the email one How does you slice that That's the only thing I want to understand But let's say you For me that is a perfectly fine story To implement That's why I'm saying that The context will differ how you slice For me that's very perfectly fine Okay you are saying that one developer Can do that complete story in Esperant That development team can do it I don't care if it's one developer or not I think that's probably the missing piece Because looking at it as one person Working on it There's a much bigger aspect of Software development that we need To talk about from process time This is just a tool Basically a tool or a method That you are going to use And context will matter Every organization team will have A different context I find that I add on purpose So practically Me and my team are given this In this story and if it does take Let's say just one developer Not being able to do it in one sprint It's okay What am I intended to do I'm intended to deliver business value And I'm delivering business value Even if it is taking me longer Cycle time and then a sprint Nothing is breaking Go for it What gives you comfort of developing it To the business need That's more important So I think from a definition standpoint Where that might become concerning is When we talk about invest And the S is for small The definition of small is It can be done in an integration So yes If it cannot be done in an iteration You will have to split the story At the same time there is a limit to the split If you can achieve it good for you If you can't it's fine There are times when you will have to say This story cannot be split further It's not going to be done in an iteration And that's okay There is no agile police who's going to come and question Ultimately you're going to deliver something But yes From a definition standpoint You want small stories So there has to be some effort to ensure Your creating stories that are done in One iteration one script I'm saying for my people this might be Just one thing For one thing it may be okay For another thing Okay I see a few Parallel discussions happening But are we good Yes You have a question Okay I'll answer your question But the tea time has started So those who want to have tea or coffee Or if I have actually shaken your Persona quite a lot Then stay back and I'm happy to talk But if you want to have your beverages They are served outside For any questions I'm happy to answer Thank you once again For attending the workshop And do stay connected I really like it