 Thank you for coming in and thank you for making such a big sacrifice when the semifinals are on, we are at such a crucial stage. So I'll make sure that every minute of your sacrifice is worth it. So in next ten and a half minutes, we are going to discuss about a wonderful technique of ensuring how to build the product right, or how to build the right product per se. So during this ten and a half minutes, we are going to cover in detail about this technique which is known as specification by example. How exactly we adopted it and what exactly worked for us. Well, walking you through that, I'll also take you to what are the challenges that we actually faced while adopting this practice. So before I take a deep dive into it, let me quickly brief you about myself. I'm Ankur Sambhar. I'm an agile developer working with JP Morgan. But today, whatever I'm going to speak, it's completely into the individual capacity and none of my views are going to get endorsed by JP Morgan. So in the last 12 years of my career into the IT, I have been mostly engaged and involved into building telecom products, financial domain applications, e-commerce platforms, building startups, doing R&D, filing patents. So in a nutshell, I have been pretty agile in adopting various flavors. And honestly, I really loved that way. Coming back to the building the right products, let's quickly go through some of this product and try to identify, do we recognize some of these ones? This one coming from Apple MessagePad, the bus which couldn't create much bus, Web TV eventually became into MSN TV, pulled out the plug in 2012. G4 Cube, which proved that only the form factor and aesthetics cannot run the product or cannot make it successful. Window Vista, I don't have words to describe that. So let's keep it aside. Zune, another big attempt to take on to a very famous product, the iPod. Videos, they tried to make an impact but couldn't do that, so they bought their competitor. And one of the biggest experiments, Kin, Microsoft Kin, which was a billion dollar experiment and which got off the shelf in 40 days. So they had to retract in 40 days. So if we just look at these, so the first thing comes in, what is so common about them? We already know that they all failed or rather they all failed badly. But what was the reason that these products which were coming from some of the best technology companies, most innovative companies have developed but still they failed and they failed badly. So the reason was that the products were not right. By that I mean there was no market demand. There was no real user need that they were able to serve. They were not able to entice the user to pay for the service or to buy this product. So they were not able to take out the money from the from the pocket of the customer. They failed. And there is, without a shadow of doubt, I can say that these products were built rightly. In the sense, the quality was amazing. Okay, Vista was a separate example. Let's keep it aside. But apart from that, all of the products were certainly built rightly. In the sense, some of the best technological brains have worked on it, still they failed. So we need to clearly understand what is the key difference between the building the product right and building the right product. If we look at it, when we go for adopting the agile practices, most of the time our focus is more around building the product right. We try to ensure that a whole of our quality and everything should be perfect. But we cannot, and certainly it's very important, but at the same point in time, we cannot lose our focus from the main goal which is building the right product. The product which is going to get users, going to serve some business needs. Let's look at this magic quadrant which is created by Gauchko Adjek in his famous book specification, by example. Over here, he has tried to show between what is built right and what if the product is right in itself. So clearly if we see if the product is neither right nor built rightly, it's going to end into the useless crap. No one wants to add any stuff over there. At the same point in time, if the product is built right, but the product itself is not right. So I can keep emphasizing on that the quality has to be, but if it doesn't meet my business demand, certainly it's going to act with the business failure. Again, it's a sheer waste of money. Now another interesting quadrant is where my product is right. It serves the business demand, but I have badly compromised on to the quality. Now what will happen? It's going to give me sleepless nights. The reason being this product is going to get used by the users. Users have paid for it. Certainly they're going to come back and it's going to bite me very badly. So it creates a lot of new sense. So the simple mantra of the success is build right product rightly. Period. Nothing more, nothing less. You cannot compromise on either of these. So for any business, no one wants to add into any other quadrant rather than that success quadrant. So what is that that is needed? And how can we ensure that I am building a right product? One of the simple solution is by leveraging specification by example. By specification by example, SB is a process to define the business goals and requirements by specifying the examples. The users are the SMEs. The end users are actually going to tell you that how the product should behave rather than we making an assumption that this is how what we think the product should behave. Let's try to understand that why this is so important. But before I do that, let us take a minute to understand what exactly has in last one decade while we had opted into the agile transformation, right? So in last one decade, we had gone from this year-long waterfall models to the small deliverables, which is very bite-sized. And with that, we are ensuring that whatever the changes is actually needed by the business, we should be able to embrace that. Now with that small iterations of deliverables, what is needed that everyone in whoever is at the stakeholder, everyone should have the same understanding of what is needed by my end product. It is of utmost importance that be it a developer, BA, QA, end user, POS, everyone needs to be on to the same understanding page that what is expected. You cannot cut short on any aspect of it. At the same point in time with the SB, the another key aspect is it helps you define your specification very precisely and it let you validate that consistently. Now with the very well-defined the output that I'm expecting out of my product into the end result when it's actually going to hit my domain or of my production area, it sets a very clear expectation around my acceptance criteria. So I know how this product should behave. And again, it has to be very efficient. It also acts like your living documentation. By living documentation, what it means that to understand any functionality that what my product is doing, I don't need to go and look into some monolithic 200-page document, which could be completely obsolete than what exactly is I have in Playpen Network is running in my code base. So with the living documentation, it always goes and validates your functionality against the code that is lying there. We got it that why the SB is needed, we understood. But what exactly it is? Is it any kind of a magic process? Certainly not. It's a very well-defined process set with a detailed set of steps where each step has a very specific role and perform a validation to the SB while defining the specifications. This is like one of the examples. So let's say this is top of my story where I'm trying to say when I need to reorder the inventory. And on the, on the, this two left-hand side things are my basically inputs to it. And this right outside is my post condition. So if these are my input conditions to my product, this is how my product should behave. Very simple. No ambiguity. It's not talking about that if there is some sale, then the order should, there should be a reorder. Or if there is a large sale, there should be no, it has to be very specific. If the reorder limit is 10, if as soon as it goes below 10, you should do it. Now the another variation could be in this right now I'm talking about just generic items. Let us say you are running an e-commerce portal and you want to put this reorder limit based on the, your vertical. Say for the books, it could be different. For some of the items, say maybe say mobile phones and that might require a longer reorder period. So maybe for that you would put the limit as even higher. So again it takes away the ambiguity. So the first thing that comes in defining the specification by example is defining the business goal. The guiding vision that got the business money invested into the product development. Until unless you have a business goal, there is no, not going to be any fund available for you to do the product development. We don't do it just for our own sake. Again it has to be measurable for it to be effective. It cannot be vague. I want a flying car. No, that's not going to work. What actually are you looking for a long hull flights? Are you looking for a small, for a short hull flights, right? What would be the sitting capacity? Are you looking for five-seaters? Again, based on that, lot many things might vary. It could be yes, my engines could be different. My fuel types could be different. My fuel capacity would be different, right? Once you have the clear defined goals, you get into defining the scope of it. Exactly what I was talking about. So you need to be precise about the scope. So now you have the clearly defined goals and the precise scope associated to it. Now you can start collaboratively, start defining the examples around it. Again, when I say collaboratively, it's not a one-person job. So everyone who is involved into this process, and it will be again BA, QA, developers, end users, POs, SMEs. Everyone has to be on the same page. Once you define this collaboratively the example, then you again refine it further based on this discussion. So initially we might have started defining the use case for the flying car, but as we got into the discussion and lot many things will come on the surface, which could lead to change in your scope, either it can increase or decrease. Based on that, you again get into the negotiation that what exactly my MVP would look like, my minimal viable product that can hit the market. Based on that, you refine your examples back. Once these examples are perfectly refined, you have the clear scope. You know that what exactly you are going to, what the MVP that is going to hit the market, you start automating all these examples so that you can verify consistently very quickly that what exactly has been already implemented, what is left. Again, as I mentioned before, certainly it acts as a living documentation. Why it is very necessary for me to add new features? I need to understand what functionality is already in place so that I can leverage it to build on top of that. Now the basic thing comes, why we adopted it? Just because it's another buzzword into the agile community? No, certainly not. So there were a lot of factors that basically contributed for us to take a decision to adopt SB and we made it work for us. So first, one of the very key reasons was distributed teams. So in our case, we had a lot of development teams distributed across the globe doing concurrent development on the same code base. So when your development teams are not co-located and they're going to work on to the similar requirement area, it's of utmost importance that they all share the same understanding about what is needed in your end product. So certainly SB helps a lot over there because the source of truth is going to remain the same. Whoever is going to work, it's fine. But again, the source of truth is your specification, by example. In our case, even the SMEs are not co-located. So with that, that was an added challenge to us because now to get the clarification around the requirements, we have a dependency on the time zone. And it becomes a very big impediment, especially in the initial phase when the team is still trying to understand the requirement and there are a lot of questions to be answered by the SMEs. But again, if you have the well-defined specification by examples or the examples in place, then at least you are pretty nimble. It doesn't mean that you will not have open questions while implementing that in sprint, but the chances of surprises reduce significantly. The nature of the business in our case require complex business rules to support various business workflows. Now for all to handle all of those complex business rules and scenarios, it was very handy for us to have one example per business rule or multiple example per business rule. With that, we can always be assured that all the workflows have been taken care of. It's always big motivation to have an up-to-date regression pack that can quickly verify what all functionality is already in place so that I can build on top of that. At the same point in time, when I'm checking in or I'm building up my new features, I should be very sure that I'm not stepping over something which is already in place. So I'm not creeping in the regression. Or at least if something is broken, I should be aware of that. What is broken so that I can quickly go and fix it? Sorry? Yeah? This is making me build product right, but am I building the right product? Yeah, so this is what we are trying to do, that we are trying to address the right product. How are the specifications, by example, is helping me to build the right product? Sure. If you don't mind, can I just park that question for sometime and I'll just come back? Because it's just a 20-minute session, I'll certainly answer back your question. Sorry? Yeah, yeah. So I think you can just note down and certainly I'll keep some time towards that and to address all the questions, right? So what worked for us? Again, adopting any new practice is not a piece of cake. Certainly it comes with its own set of challenges. Can I ask a question now? Who's that? Sure. Is it different something from Martin Flas given when then or it's the same? Sorry? Given when then way of writing the... Sorry, I'm not able to hear. So there is a way in which you can write a specific scenario or a requirement that is given a definition when and then is the result. Is it the same thing? Yeah, but with that you are trying to define the requirement. Right? But with this what we are talking about is the results of it. That is more of a definition around that, right? When we talk about as, when, then that we try to define the requirement but we don't get into the example details. With this we are talking about the examples. So maybe I think once I complete I'll just come back to the example again and I think that will help you to understand it better. So the first challenge for us went to create it. Should it be created as part of sprint zero or should it be handled on sprint on sprint? Should we have a separate box shops and sessions where we can onboard all the stakeholders and create the SB or should we use anything which is existing like the PBRs, which is a very standard activity for sprint? We kept it simple. We leveraged PBRs because anyways all the stakeholders are already part of your PBR session, the product grooming, product backlog refinement sessions. So we leveraged that. Again, for every two weeks sprint we use one day of PBR to define the examples while grooming the stories of future sprint. Who all should participate in? Yes, everyone and anyone who can contribute or is going to use the specification for implementing the feature. So again, BA, QA, developers, SMEs and your end users, POs if they want to, right? But everyone should be included into it. So that's the reason why the PBR works fantastic because anyways all of those are already present over there. By the way, this meeting is also known as Three Amigos. This term was first coined by George D. Windy and the purpose of this meeting are so where three represents the representation from BA, QA and developer. And the purpose was to have the common understanding across these three roles so that they can discuss out the various requirements because previously before we were so agile or lean agile, we always used to work in silos. So developer would start developing or crafting the software with their own presumption about the requirement. QA will test it with their presumptions and the BA would say, okay, I had expected or I had defined something entirely different. So that's why this kind of meeting so very important. How many examples are good if enough? Are there any magic number? We tried a lot. There is no magic number. Until and unless your whole team or anyone who is there in that room during this discussion of what we're defining gains the confidence that everyone got the fair understanding about all the flows and we have covered that. We should keep adding the examples. Again, as part of the discussion, lot many cases would surface. They should be added back into the examples. This is also going to act as your regression framework. So the more the coverage, better would be the safety net. What level of granularity should I have just one example per feature or feature slice? And what kind of data should I be putting in? Again, granularity completely depends on what kind of feature you are building. If the feature is not too complex, you might have just a simple example. But if your feature is too complex, then you might have one per feature slice, maybe one per flow. It completely depends on the feature. The type of the data, what we identified study data I mean any data that is not going to contribute or is not going to impact the workflow under test. So if I am trying to put in testing a password, the strength of a password, over there if on my pre-condition, I am trying to put in the user ID, a variation of user ID, it is not going to make any difference. What I am trying to test is that whether my password is good or not. So this data should be removed. Again, while defining the example, we need to treat them as good as we treat a production code. So if you find similar example, they should be removed. Otherwise, they will create the maintenance cost. Who should who should author it? I am sorry. Who should author it? Certainly the end users who are in the best place to author the examples. The whole team should participate in this discussion, but certainly the end users or the SMEs should author it. The reason being they know the requirement best and it will also put them into the driving seat to ensure that they are defining the behavior what is expected into the outcome product. Now, towards the end, let's quickly check where exactly it fit into the agile or scrum to be specific. As these are crafted during the PBR sessions, so certainly which is a very standard activity, it becomes an integral part of each sprint. Again, it has its own place into the definition of ready. Now with the definition of ready, if you are already adding into it, so before a team pulls in a new story into the sprint before for implementing, it's ensured that if you have a specification by example, that the understanding around the requirement is very clear and you have a very well defined acceptance criteria. So again, it will take away all the ambiguity around that. Reduces the surprises during the sprint and it also finds its place in definition of done. Now, you have a very well defined acceptance criteria. Once that acceptance criteria is met, so you are not going to treat the user anymore for the testing of the product. So right now what we do, we just push it to the customer or as an MVP and say, we will adopt it. You let us know what the changes. But with this, we are trying to save on to that part whether I'm building the right thing, what is that you need it for the end product to be in and I'll do that. So if my acceptance criteria is met with the definition of done, I'm sure that tools SP is nothing to do with the tools, but certainly when you adopt any practice there are going to be something that you need to leverage. For the conversation, again, if you look at the SB, the whole idea revolves around the conversation. The conversations across the parties that are involved and how well they build up the common understanding. So for all good reason, whiteboard should be the key to use for the conversations. They are the most effective. They foster the culture of conversations across the parties to put in the ideas that can come on to the whiteboard. You can rub it, you can refine it, you can do a lot of things. But again, we all have a challenge over there. So again, if all team members are co-located, it would work better. If not, then what? The spreadsheets can be used. Again, these are more around the defining of the examples. Nothing is going to make or break it. But for automating it for regression, you can leverage on any of the available framework. The benefit of leveraging any of this framework is that you can keep a check on to the regression once you have integrated into your CI environment. So let's say you have a Jenkin, Hudson, Bamboo. So you can just integrate with that. All the examples would be verified after each check-in. So as a developer, whenever I'm checking or I'm making any change, I can be rest assured that I have not broken or introduced any regression. So what is broken so that I can go and fix it? So with that, I would like to close the talk and I'll open the floor for the question. But I hope you will give it a try and we all will ensure to build the right product rightly. Thank you very much. I think you had the question, right? I'll go back to the example again. Yes, please. Yeah. Yeah. Based on that validation only you can identify whether you guess in this case it is a guess that this feature will be good for the customer. But only when you verify with the end users, then you can say this is the right thing to do. Right. So that's exactly we are trying to address, right? That building the right product in the sense we know that what are the features that are going to be. So let's say how you conceptualize any product. So even say the product owner is someone who is sitting in the organization. In true product environments what they do is they do some survey of say end user. They try to understand what is the feature they are looking for into the end product, right? The major problem right now what we face is the impedance between what the developers or the development team feels about the product and what is exactly needed by the product owner as an outside product. Yeah. Sure. So those awesome any other approaches are coming into the picture like link startup where basically you define your idea. Yeah. You basically build it and build the MVP. Yeah. Those into the production end user and give the feedback based on the feedback you can say whether your MVP is working or not, right? Right. Sorry. But again if you look at it how will you come even to the stage of an MVP. the stories that has been worked upon by the team. Right now if you see, sorry, right, so right now if you see that even that the rejection of the story at the product owner level is much higher, much higher. There is a big impediment and that is why we always get into that, okay. Now we will adopt it. You give us a feedback, we will adopt it and we will quickly work on it and in the next print we will deliver that. That is costing us. That is what we are trying to eliminate. Certainly the MVP would be the end product, but this is how we will build the MVP. Does that answer your question? I think we can have more conversation, but if you look at the key specification around this is this end behavior. So what is I am expecting out of my product and this is what we all define together, be it a business guy or be it a developer. Once that understanding is correct and if whatever I have developed, if I can verify against that, I should be good to go. Sorry? Sure, sure, why not please. Okay, thanks a lot. Sorry, you have a question. Yeah, please. Kind of technique earlier in wherever I have worked and I found one big issue. Yeah. If I may say so. Please. Sometimes the entire development gets restricted to the examples given there and if the example does not represent all the flows, it does not get developed at all. It goes exactly by the example. The word example is forgotten and only whatever is given in the example is done. I completely agree to that. I completely agree to that. Yes, but I think there will be more of a learning curve where you start. So once you identify that maybe next time when you will refining the example, you will try to think through all the possible scenarios. Because again initially we have also faced that. So as the gentleman was rightly saying that how is it different from defining the user stories? Sometimes when we start defining the user stories and then we get into the examples, initially we think it's very much similar and we miss out a lot many things. But I think as and when we go over, we start analyzing and that's why having multiple heads in the same room works very well. Just one follow-up. Does it mean that the document has to be, has to have all examples possible for that? This is the document. This is the document. Yeah, what I am saying is the specification. Yeah. Then it needs to cover all possible examples of that flow. Yes, if there are multiple flavors then they should cover it. Any variation should be verified through an example. What about negative scenarios? Then you expect negative examples also? Yes, if they are very specific, yes, they should be. They should be. Then I think the documentation will become very onerous. But again, if you look this documentation, this is the live part. You can quickly verify. So, anyways you are going to do the coding for that, to ensure that. So, if you have the something to verify against, so that we can act as to fall back upon. It's also beginning to sound like a test pack in that case. Yeah, but the only thing is it's driving your development.