 Hello, everyone. Hi, you have a good keynote in the morning. Fantastic. Great. Awesome. So I think we have a full house now, almost full house. That's great. So let me quickly introduce ourself and Who are these two guys? So Ashwini. Yeah. Morning all. I'm Ashwini Kumar. I am working with region technology as a technical architect more specific to Drupal I'm with Drupal with last six years and In contribution, I'm mostly into organizing Drupal camps Drupal meters hackathon and mentoring new beginners back in India Recent contribution of mine is in Drupal console, which is actually got released for Drupal it and we actually Translated Drupal console in Hindi language as well, and it's around 97.7 percentage and it was completed Last before last Drupal con back in Mumbai So, yeah So I'm Gaurav. I miss one of the business heads at region and I take care of business for US region and some of the plots parts in Asia That's a quick introduction and Before we jump on right to the to the next slide I just want to know how many people are here from the agencies who are running agencies or the part of the agencies That's less than I expected and What about else are these people from the companies clients, you know working in Drupal? Yeah, okay, fantastic Great. So, you know, let me just quickly put Expectation and say that what essentially we are going to talk about, right? We are not probably going to talk about cases when we have a lot of time a lot of clarity in terms of what we are going to make what we're going to build We are not assuming that you have done a lot of requirement gathering a lot of clarity brought a lot of clarity designs With you, you know while doing the estimates It's a it's it's not the place where you have the budgets defined as well, right? And it's very early in the stages. So we are looking at, you know, how do we how do you go on accurate with early estimations? I think if I before before, you know, I was building this presentation For a Drupal con I looked at several earlier Drupal con presentations, and you know, almost all of them talked about Estimation techniques which rely heavily on, you know techniques which require a lot of requirements to be in the place and I mean and as you know that that's not the ideal situation everywhere every time, right? So what do we do when we don't have requirements very clear? How do we go accurate, right? So and you know, this also includes that. How do you sell the whole story? How do you convince? clients or how do you Put the message forward that estimations is not something that you can, you know, just make out in a day or a two It's a long exercise. It requires a lot of hard work into it. And how do you convince clients on to that? So that's the story that that okay with everyone any questions concerns? No fantastic Okay, what are the problems that we are going to address, right? So Anywhere in, you know, almost every agencies I talk to globally. I think this is one of the most least invested activity Globally, right? So, you know, you get a RFP, you get a client coming in barging in and said that okay I have a very big project for you. You know, we're just looking at marketplace. I'm looking at a community portal I'm looking at a marketing portal and you know, you are experts. What is going to cost? Right, you hear a lot like a lot like that. So what do you do? Right, you can't really go on and do user stories You can't really go on build designs mock-ups or frames to give up huge time investment in building the backlog And then doing the estimations, right? So what do you do? What do you do at that point? Internally, we haven't been very successful with our space estimations You know, and doing that very early in the same cycle our base estimations actually hampers big time when you go into the development, when you go into delivery and We have moved away from that. We have moved away And I'm going to talk about what we have been doing now in terms of the estimation, early estimations, which is not ours You know, again features. I think very a lot of companies, a lot of agencies globally give all the estimates on the basis of different features and say that what features is going to, you know get implemented in what hours and that's how they essentially budget and sell all the triple credits That doesn't work as well, right? And we have been trying to move all the conversations and we have been successful as well from features to complex cities, right? And we are going to talk about that as well. And lastly, selling the focus factor, right? Telling the clients that they can be back days for a developer, they can be days when things are not well They can be, you know, it's just not in the right mood, you know, and all that things come up And you have to understand there can be a limited focus factor for a developer to work on a daily basis, right? And how do you convince that? And, you know, I'll actually, rather than going into the theory, I'll talk about the case that we worked on The breach that we started off with was, I want a market place with 250,000 merchants and 1 million has used to start with You are the experts, tell us the time and cost That was the only state And we just have 4 months to launch a beta, right? That was the only state Yeah, so I'm sure it would be pretty common to a lot of businesses, right? And you get across to things like that, a lot What do you do? And it's one of the very big clients in India that we've become from India And we don't want to lose it for sure, right? And we wanted to make sure that we get inroads and, you know, make mark So, we build a base We set up a base and we said that, okay, you don't have a requirement You don't have a defined understanding of what you want to build Let's, let me set up a commerce that's a bit more anti-golden, right? And showcase you what exactly, you know, are the features that are out there that is already built in And, you know, are available, right? Many times we use, we always try to use this base in some other way In all the projects, on all the features that we do Either it's a demo that we're going to do for the distribution Either it's a demo of some other client that we're going to do Either it's a different website, of the current website But we always try and make sure that we have base to start with On the conversation, right? And this is all done by the sales guys There's no delivery or the pre-sales guys coming in And what works with us is that, you know, while you go on and build this base We talk about the nodes and we say that, you know, if we talk about our experience This is the kind of a budget that, you know, this commerce experience should look like So it sets a base from a purchasing point of view, from a budget point of view to start with, right? But the important thing to understand this whole exercise Is to make sure that your people involved in this whole estimation exercise Understand the organization knowledge very well They should know what kind of projects we are doing in terms of What has been the time that we have spent on that, right? What are the different things that you have done, right? Not in a very detailed manner, but on a very holistic level You know, make sure that understanding is with the sales and the pre-sales team very well And make sure that, you know, they understand But what is a learning curve, what is not a learning curve, right? You know, it's easy for architects to come in and say that what is easy What is your learning curve? Are you looking at React? React is a new language, it's going to take time and all that stuff But telling that information, you know, is the training that we spend a lot of time You know, from the sales and the budget should be there And, you know, while we set up this base, this base really helps us, you know And start in the conversation with clients In making sure that they actually get involved in architecting the whole business, right? If you don't have a requirement, if you don't have things in place This base allows to have this conversation starting And they get to, you know, talk about what we can do with their whole thing Or what essentially they are looking at from an output point of view You know, we bring in our different product owners We have a system where we have both product owners, hands-on masters as internally decision And we have a product owners at the client-end as well And these product owners are usually, you know, people who deliver more responsibility And they come in, we make sure that they probe You know, at least usually four, five hours You know, they spend on one particular, you know, prospect Which have been away from the same subject And is a qualified prospect for you, right? You come in and you say, talk about different questions You probe in and you find out what are the different things that the person is looking at from the experience Right? Correctly, on the theoretical client that you have And the base that you created, is it all a pre-sale? Or is it signed in an admin end of the deal at this point? No, it's actually a rule to like It's not a theoretical base It's a practical base that we have created So practically when you created that base Did they sign anything with you? So they signed anything? They signed anything better than to do some work with you So you're getting paid right now? Yeah, what point are you getting paid? Sure, I'll tell you that But yeah, to answer that, yes, they'll sign Maybe we need to get that done for four months now And I think it's going to be a little three, four months Four, three, four months before we go right Yeah, and you know, one of the things that From our experience, I understood that Making sure, making a note that the teams Who are getting into those calls Getting to migration and integrations on a very deep level These have been the two biggest unnotes Which impact for estimation from a new point of view when you get over it Rest of the things, get invested in this work Making sure that migration and integrations are totally covered And you know, one very important part is to Go on and force them to be engaged So when you have put in a base You have talked about what you can do And you're going and probing different questions It's very, very important to tell them Very clearly that you have to be engaged with them You know, I've seen cases where It's very kind of, it's a very exhaustive exercise for clients And if you're coming in and they want They're looking at 10 different vendors And everyone is giving them a call You know, they get very engaged sometimes And say that, you know, why are you doing so many questions? Like why are you going into so deep? You know, everyone is giving you a call And we have walked away many times from that So the client is not engaged And that's what the client wants So we tell them that I need to get engaged Or get into a call And that has worked because many of them Came back to us after a year and two Because of this whole piece Where we have walked away because they were not engaged And it helps Yeah, so here we start with This is a sheet I do not even remember who made that But you know, this is very common I know for sure, right And used by many people The original sheet had powers With the confidence factor coming in But we have changed that And we have got the rest of the stuff there With the assumptions, the specifications But we have removed our part And put the sewing points in there And you know, this is the same as a site The only difference is that, right Apart from going and asking the first people Who are doing the estimation And asking them to do an hour special session And asking them to go into complexity With sewing points And going to talk a little bit about that And how do we do that Yeah, you want to talk about it? So I made that sheet So this is the place Where I come into the picture When my client gives hard time To my sales team And I help them With giving early estimation, basically Because I was working with agile fashion From last many of years And usually we have certain Research exercise Before we took project So we have a one month of The exercise where we actually Talk to client, make all the user stories And put it all the story points And write down the specifics Of certain functionality And maybe using any kind of tool Jira or something else So that's where we have time To actually estimate specific feature What has to be built But in the early estimate We really do not have clarity As Korov also mentioned For specific functionality Which is actually close to That it's going to build In that particular fashion So when the epics level So in agile fashion We use to call the epic When sales guys gives us All the jargon Like carousel and solar search And we have to build our e-commerce site And nobody has any idea What actually needs to be built Or what exactly client wants So we have categorized these Functionality or epics Into two ways So we are going to put our assumption And solution of particular feature And we also give certain reference specification For example in Drupal project While making a Drupal project We have lot of modules So let's say there is a solar search functionality In a project But what is to be there in solar Does solar search should On what level the solar search should go And there should be lot of condition When you actually build those part Facet search and all those things So we actually break them And we break them with our assumption Solar will be running The solar result page will be there And there are certain facets will be there And based on certain queries We are going to drill down all the results Which user want And other part is the specification How we can usually identify What specification it basically comes From the experience when we are making Lot of Drupal sites So you always know that There is a module available in Drupal community So you are going to just use that Configure it and things are ready So that actually help us in Identifying and reducing the time How much time particular feature Going to take for a team To develop or deliver So before the estimation First let's understand what is mean By story points And why we do not Really major things in ours So if you understand correctly Ours is basically a very hard time Which we say So in a development team If someone ask or manager ask Or any scrum master ask How much time it will take If I am a developer I will say 2 hours But in 2 hours I really Don't deliver them Because in 2 hours I probably Checking my Facebook I will probably checking my Twitter Or someone just call me for any help And after 2 hours if my manager Comes and he will say is that done I would say oh no So that's where the problem comes in You really don't deliver anything When you are saying Oh this is the hard time I have For the session I would say For this session we have 60 minutes But can we finish this session In 60 minutes No it can be in 30 minutes It can be in 45 minutes It can be in 15 minutes So we really can't actually Say how much time Particular functionality will take To build and deliver If we are saying in hours So what magic story point does to us So story point basically A number that actually tells That how hard the story is How hard the functionality is Based on the complexity Based on the unknowns And how much effort it's gonna take To build specific functionality So this is the story point Technique that we guys use So it's I don't have Okay let me Okay let me use this one So these are two objects Which one you think a smaller And which one you think is bigger Right so this is what we do In story point technique So we actually define All the stories based on the size So we first say The smallest size story And in compare to smaller We actually align to the larger part So extra small Small, medium, large Extra large and double XL You can actually think about the T-shirt size as well And what are these numbers These numbers are actually a magic number Which we say a fabonacci series Which has been used Throughout the world in manufacturing Industry for the estimation Car industries and IT industry as well Specific to agile So over here When the exercise actually start We have certain team members So not a whole team But usually the team which require To build a website a dev will be there Or maybe a theme And a tech architect So these people are And one product manager who actually help All the business head Who actually have all the Information from the client Or specific feature So as a team we define And we place all the story Based on the sizes And based on the sizes We actually move So let's say a one dev comes in And move one story from medium to large Because he thinks that this story is large It's not to be in medium And the other developer Actually moves the story from large to medium So when certain story gets moved To another size We use a marker And put a dot on the story So that we can actually track Because there is some confusion in that story That we identified At the end of the exercise We actually check out all the Dot stories And we talk to our product owner And product owner actually clarify Okay this is what the assumption is And this is what we have to do If certain story is not clear Then product managers will say Okay these stories will not Estimate as of now We'll go back to client and we'll put the assumption And take if any clarification is needed And Over here the important point is We are actually Calculating the velocity Right so after all These story points we jot down That how many story points Will be needed To complete this specific early Estimation feature So let's say we have 500 Story points in this exercise So it will not take much time It actually take us So let's say we have 200 stories Or 200 features it hardly take 15 to 20 minutes to complete this exercise And after that We sum all the story points So let's say we have 500 story points And we Divide that story point Into a team in sprints And let's say in sprint We have one week of sprint And we divide That sprint and estimation Based on the team members we have So let's say a 50% dev Or 100% dev There is a tech lead There is a scrum master And there is a QA which is available Based on the team and the sprint We divide and come from the velocity Thanks So the quick question which Come to know that Specific feature will take certain time Because in early estimation We do not have lots of Information And lots of complexity That we need to build But as we actually grow And as we actually build things We can actually identify Based on these factor how much A specific feature will take Time to get delivered So first is risk When I mentioned that the moving Of the story we actually track And it comes to the picture that This story has certain risk Or certain things or information is not Clear, or assumption is not clear So we get rectified from the client Second factor is the complexity So for example Which we took is the solar search It can have a lot of complexity But what exactly client needs So based on the assumption That we will take solar Server needs to be configured And there will be a search result page And there will be a fair search And there will be a certain search query Which will pull out the result Maybe a document search and all those things So we take all those assumptions In the early estimate Third factor is the effort How much effort it will require Not in hours that I am going to finish this In two hours it will never work So for efforts we actually took How much effort is going to be So for dev team to build this feature Technology Technology is also a great factor While we are estimating In our case Drupal is one But let's say if there is a payment gateway And we are integrating payment gateway Do we have any module for that Do we have to Write a custom code For payment integration Or any other technology Integration is required I am sorry do you have question Ok alright The last factor which we Think about is the skills So there are a lot of Headless Drupal There is a JavaScript framework Which I actually see Every week I see a new JavaScript framework ReactJS and AngularJS And all those things And the concept actually gets evolved As we are going ahead with the Digital experience, customer experience And over there we actually have Also improve our skill set So do we have a JS person In our company Do we have a Drupal expert in our company So those kind of skills actually we have to think While we are estimating Because you are not going to let us say That oh I don't have a skill set for that It will be a lot of miscommunication With the client A lot of back and forth While the development is going on So at that time only we used to take care Of the skill set as well So after completing this exercise What worked for us We are not estimating Any feature based on ours Everything is on size based So we are actually saying that We are not saying that How much time a particular object Or a particular object Will take time to get delivered We are saying okay this many Effort will get put In building this particular Functionality Second a fear of commitment So usually in the engineering team There is a fear of commitment that Should I say 2 hours Should I say 6 hours to build this functionality What time I exactly should put Because if it will not take that time My manager SM Will definitely get hold of my neck So at that point The fear is gone and it's human actually We really we say Okay I will be 10 minutes late But it will maybe take 30 minutes But if I am not 10 If I will just say okay I will be in couple of hours So I am not saying in specific time I am just saying I will be in couple of hours So at that time The fear factor is removed We are just sizing the stories We are not putting any hours into that Focus client conversion In right direction This is the main important factor Which I think when we are dealing with our clients A sales team or business team It deals with our client So there is one direction where we are thinking Instead of saying We will deliver this functionality In these hours Instead of saying This is what we have to build And this is what effort it's going to be In your product or project Which you want So the focus conversion Actually gets started at that point So relative estimation So it's actually research has been done And it says that humans really Are good with relative estimation As compared to absolute estimation So when we are giving any relative estimation To particular thing In our daily life as well If we are using a relative estimation We usually Go as close as To what we have to do And yeah the story estimation The story point estimation is typically Really very fast This is the research And it says that If you are building Using a traditional Project management methodology Then you will actually Be able to Go a 50% Close to your estimation But if you are building On agile methodology And using in a story point Then you can actually go to the 80% Close to the estimation And this is how it looks On field So you can use your Wide board or you can use your tables And this is how The exercise goes So you know And usually because it's an Expensive exercise Getting your depth In your architecture You want to make sure that It's not going to take a lot of time Typically do about Starting to party Or 15 So we make sure that And we have limited time We make sure that all this You get in 5 to 10 hours Which includes the flight call Which includes all the probing questions And everything to the level Of the estimation What essentially all goes into it So we I've been training upstairs people In Going in the halls And go and ask all the probing questions To find out the high level requirements The ethics Which essentially Helps the devs to come in And understand what is coming At the holistic level The whole requirements look like And then they go on and do the story Point estimation on the deep large Ethics And usually One hours or two hours It usually does over 4 times And we just take notes Over the next few weeks And get the data in the correct order For the guys who are coming on the calls And the work owners are responsible Asking these questions And putting them in the sheet Which can be used by the devs To go on and fill their CVS Which usually takes about 2 to 4 hours In order to spread across In different calls Then you go on to sizing The whole process Which usually takes about 40 to 50 minutes We have trained Internally our devs Our people a lot Which we don't submit really Because they come in, they know what they do They know how the things get removed And they have gone And it usually takes 40 to 50 minutes To get all the sizing in place Then you go back We review this And many good things that have been happening With different things This whole process is getting tied up And all the dots are connected Serious people are much more empowered To go to the client and actually talk about What are the different unknowns That they have And actually present a much bigger sheet Which is our basic course Which is our number And say that this is the unknown that we have This is what we know This is the complex of the course This is the normal course And there is a very good base for the discussion And we are able to rule through a lot of competitors Because of the details that we go on And because of the light It doesn't take more than a day Oh, okay Sorry, I'm not used to that Okay, my mistake So, yeah So you go on Back to the sales team And you give them Essentially empower them With the whole detailed understanding Of why a number came in And then When everything is in place Everything has understood the whole base You go on and make sure that You find the velocity of the team And talk about how do we do that Because the people who are going to estimate Will not be the people who are going to deliver Because of the early estimations So how do you find the velocity in that case And find out how many sprints Are going to take to deliver that stuff And it's usually a 15-20 minute exercise Very quickly So you go back And present this whole sheet Transparenly back to the client Along with the focus factor And tell them this is what we have done This is what we have You know, understood from A detailing point of view And this is how We have estimated the whole effort What do you see? Do you see any gaps Do you see anything that we have missed What are your thoughts and everything Now that engages clients All together And because And this is One of the things that we came up Internally Because we don't have the same teams Delivering and estimating We have segregated our developers And different Works in their appraisals And their salaries as well In different segments You have L2 developer, you have L1 developer You have a senior L1, senior L2 And we have put in Standards and we said that If a senior developer is Delivering x points and this is Based on the data that we have Then a developer would be Probably able to do 70% of that A themer, you know, usually Because theming is much more You get a lot of changes coming in A lot of feedbacks coming in We put in a senior themer to 75% of the capacity From story points From mid-level themer to a 50% capacity To be able to deliver something Does that make sense Because it's a little Complex to understand But this has worked very nicely for us It's a formula that we have used Internally We have been doing it Probably quarterly now And it's I think And everyone is involved into it We have three offices in India We have two development centres And every BU head is really involved Into this And it goes into their appraisals Discussions and everything which happens Again, every quarter All this data actually binds together Every quarter Right now it's actually pretty good It's really working for us And this is again It's very transparent to the client The client knows that these are the people With this seniority Different rates for these different people And this is what they're going to deliver And it again depends on How complex or how easy the project Is going to be Because of this Different capacity and different velocity We actually invite people to give them A range as well So if you want a leader Which essentially does Development in a longer time You have different velocity all together If you are going I've been doing that for quite a while This is the first time I've seen that A factor Times of points Based on a little developer That is really interesting I've never seen that I want to ask about why do you do The total magnitude of that Why do you have that factor Because of this one Because you go in And you always want to make sure That you don't go with an absolute number You want to go with the range You want to say that this to this Is what we think And then go into discovery And do a better estimation in place You're paying 100% for everyone You're paying 100% for everyone You're not paying any So if you look at the sheet It's actually pretty tiny I never realized it would be that tiny If I put in all senior developers Then even It's not going to work Because you have to pace development In a certain way You have to have a mix in place And if there's a senior developer That's a different cost altogether And if you have a junior developer That's a different cost altogether The whole metrics come out very nicely And depending on the complexity of the project For example this one You can see that it's a pretty large team Pretty stiff team Because it was a marketplace Which is supposed to be live in four months So you need to have a stiff team But if you don't have that scenario Then you're probably a teamer In a 50% capacity would do Which is Which is not probably doing X points like a senior person In the place Again It all depends on How easy the client is With all these conversations coming in And when do you bring all these conversations And this is also I don't know if I'm able to capture everything here In this one presentation But I think we have learned that Slowly and slowly over the time When do we bring these conversations in Should we bring it early Later in the stage Largely So we at Srijan stick with Long accounts The strategy is always to go with long accounts Not with projects We have really stopped looking for projects For a long time now Wherever we have found The right people Who have been in the industry Who have seen projects failing They appreciate all this By a huge margin They appreciate the transparency We all telling them The real truth And saying that this is going to be a focus factor You cannot have everyone Living at 100% capacity Always And this is the truth So I think they appreciate it Yeah When you Are responding or do you just choose Not to respond to Estimates that They are asking for A total hours breakdown Or not even a breakdown But a total hours Do you just kind of extrapolate An average rate and say This is our range and that's going to be about 4000 hours We don't do us We don't try and say no That we are not doing ours We try and make them understand What we are trying to do And keep on talking about Story points After the other And if they are not engaging Then we just move on Yeah So the pricing is now With all this When you have done these estimations And everything story points is in place You have found the velocity Of the team What is the total number of story points And what your team can deliver in a sprint With that You find how many sprints Are you going to do So you can see the sprint 1 Sprint 2, sprint 3, sprint 4 6, 7, 8 So you say that you are going to take 8 sprints One developer costs this much This is a burn down For a particular sprint And again, we try and go with the range As I mentioned earlier Which still leaves that Ambiguity in place For the discovery to kick in So we work with dedicated teams The only people that are not dedicated Are sometimes And usually we have even stopped doing that For some time now Is Themos We used to put 50% Themos earlier But now it's We don't see it working But yeah, it's usually all dedicated teams So one projects end And then they move on to the next one All dedicated So then I don't know If luxury is the right word I think When we have looked at the whole ROI That's one of the responsible salespeople To show the whole ROI And say that you are putting 50%, 60% And looking at Again, we are looking at people Who are experienced in delivering Products from the client side With some history of delivering products And they know that a person Not dedicated Doesn't give a good product out Doesn't give the quality out And yeah So it again depends a lot In contracting In ideal scenario We would always want to be a time and material But it doesn't happen So we sometimes go for fixed costs And go for time and material If there is And you know We have been doing all this thing Just to make sure that it doesn't go overshoot And we have been putting all these efforts So for example in this particular case With the marketplace We exceeded by one sprint One sprint was exceeded But it was pretty large So we took that one sprint Hurt for us So we didn't build that to the client And the clients get a little older with us They get comfortable And they have a lot of trust They don't mind being on time and material But usually to start off with We usually start with fixed price projects Again This is a contracting portion Actually Pretty good point I think that's clearly A struggle for us To be honest We have been pretty focused on engineering The engineering capability So we don't do designs We don't do any marketing Things All this done with partners And we actually bring Our engineering capabilities I think That's a place where We are trying to go with solutions As per se And say that if you are looking at these solutions If there is a total unknown area Completely And starting with a pain problem We are trying to do with the product owners In place which are Building them as industry Experts internally But I would not say that we are still there We are still Trying to do Probably Probably That's a good thought Thanks for that Coming back We go and share the range And We have been trying to Try to be accurate in the past The more you go back to the developers The more Estimates seem to be getting Decreased The more you put in more efforts The more Things get creeped in So it's better to be that ambiguous Internally That we have understood And go with The process of this whole estimation And the delivery process to them Rather than trying to focus The whole conversation around Effort And what we have understood from the functionality We bring in the whole expertise Of the delivery How we are going to deliver How we have spent so much time in And we talk about how we have done it in the past With the clients We break The project in smaller releases If you look at the last line it says Contract for small releases is budget for the larger So if we Go on and we do this whole exercise We usually When we are working with large Projects it goes up to Six months, seven months kind of Engagements Signing that big engagement Is usually a little difficult For the lot of clients And we try and focus and don't do that Don't go with a larger contract Go with a smaller contract Go with a four-spin contract And we have been pretty good In terms of delivering stories Sprints after sprints because of the whole Dedicated team effort and the processes we have put in And once we have shown the value It really helps So internally From a sales angle we also Shift the conversation from other sales people And say while other sales guys Are looking for a longer contract We are looking for a shorter contract For our clients We talk about number of sprints And delivering value Every sprint What we also capture is that we put in Goals for each sprint And it's pretty easy We have been doing that now With the whole estimation technique And we say that very holistically We are going to do that in the first Print, content types in the first Print, taxonomy in the first print Second print we will do this migration will go on, you know, I'm all the sprints and you know we're putting all these goals together, right, especially for the people who really want the Gantt chart, you know, to be pitched from us, right, and it really has been also helping, which doesn't capture here. You know just very quickly I wanted to capture on, we've been pretty lean in the sales team, you know, we have US sales rep, we have an India sales rep, we have Asia sales rep, and then we have the solutions team who comes in and helps in and everything is actually overseen by the CEO of the company. Yeah, and again this is, I talked about that, the expected velocity, right, so we talked about the velocity and say that while, and you know, this is a difficult conversation always, right, while we have done all this maths there, still there's a lot of ambiguity that they left, right, and you know you might not get all the velocity in the first print, so and you will gradually going to increase the velocity as you go in the project, right, and we try and bring that conversation in the sales as well, right, with the clients, again transparent, and yeah, you know, we're trying to be more and more transparent with what we have been doing in, from a delivery angle and not, and showing to the clients and some things working, some things are not working, but yeah, we are getting there, and you know we plan the UAT time as well, it's actually built in the contracts, this is again a learning that we had, that we specified time of the client and say that you can see the sprint one and after the sprint one, you can see that you have a UAT time defined for the client, right, so if the client doesn't complete the UAT by that time after that sprint and doesn't sign off and tell them what is being delivered, what is approved, what is not approved, right, then there is a contingency in the contract, right, and make sure that you know that's going to cost them extra, right, so that's one of the things that we force from a contracting angle as well, the UAT time that they have to put in after this, after the sprint, the first sprint, yeah, so is that the question? No, no, no, sorry, so that's one of the more, that's extra sprint that we put in, put in after the whole development, but the client actually sees the project, product after every sprint, so this 2-5 November, you can see, right, just after the first sprint, essentially the first UAT time, and then we bring in one more UAT sprint at the end to iron out everything and go life before a production deployment, right, but the UAT happens after every sprint and the acceptance also happens after every sprint from a story points and internally we have a mandate that every team has to deliver 90% of the stories after every sprint and that affects their appraisals, their salaries, their bonuses, everything, get accepted by the client, yeah, get accepted by the client, if it doesn't then it, you know, impacts the entire team's bonuses and salaries, yeah, also what worked that, you know, we, and you know, and usually this comes in, you know, once we have done this estimations and the estimations are out and I'm actually flying to Boston this Friday for a similar workshop, right, and you know, when we have some understanding of the cost out there, some agreement of the process out there, right, we go and invest, start investing on these brainstorming workshops, right, and help them get more structured, you know, in the unknowns, bring in the unknowns, right, and that is where we help them bring the cost back also, a lot of time and because, you know, all the transparency kicking in, right, we can have the conversation like, okay, you don't have, you know, $200,000, you know, budget, you have $150,000 or you have $100,000, now what I think we should think, we think that you should be getting delivered in $100,000, and we come in and, you know, try and do that, and now because we have done all this groundwork and because that is transferred into the client, we can have all this conversation, okay, you don't have the budgets, but let us work under your budgets and let us tell you what is important in terms of your MVP or what you should not looking at deliver at all, which might not be useful at all for your company or for your business completely, yeah, so we get into all these brainstorming workshops and help them understand that requirements, and yeah, you know, every, you know, this is also, I've just noted down few things that really working for us, you know, so we, you know, there are different stakeholders with enterprises, right, and we are sending the status emails every two weeks to all the stakeholders involved, not the product owner, usually what happened that product owner is usually not the final decision maker from the client send, right, so we've been sending all the status emails to everyone and telling them what is being delivered every two weeks and what is the burn, what are the risks, you know, what are the, you know, complexities coming in, what are the ambiguities still there, so that, and we put in a color marking as well, right, which helps all this business stakeholders jumping in and saying that, oh, there's a red mark, let me get, you know, in and try and solve whatever is the roadblock for the development team, and we forced a discovery, you know, and show the need that, you know, you have to get into a discovery, you know, we have done a lot of things, but unless and until we do a discovery, don't really contract us for the entire thing, just contract us for a discovery, we don't like us, you can take the discovery and go to a different client altogether, right, that also helps, been helping a lot, and, you know, because we have done all this groundwork discovery and we have been able to sell discovery because of all that, because then you have a clear unknowns there and we have been able to say that this is because you need the discovery, because of all these unknowns that are in the picture, it was of these complexities in the picture and then, you know, this is another trick that I've seen, you know, which helps that you insist on getting the designs out before you sign the final contract, right, and this is all when it's done and the client is really desperate to sign the contract, you hold the contract till the designs are not out there, right, just to make sure that there is not ambiguity, right, we have, you know, it's not always, right, it depends on, you know, how they are in, you know, with us, but yeah, insisting on designs coming out, really helping out also, from a delivery point of view. Last slide, essentially, yeah, last slide, because, yeah, last slide. So, be transparent on estimation and all multipliers, I know I've been saying again and again, and help sales team with the purchasing process, you know, I know salespeople are being hated globally, I'm one of the sales guys, and but I think a lot of empathy given in, you know, can help them really succeed in a very well way. And, you know, free audits for the paid audit exercise, POCs, you know, doing that all investment, when you have all this thing done, and when you're going for the brainstorming exercises, also, you know, helps a lot in selling. That would be it. Questions? Yep. No, hardware is in what, security devices? Yeah, so we work extensively with platform, Acquia, we've been working at Acquia for actually a very long time, and the sizing and everything, we bring them in, we don't do it ourselves, right? And Pantheon, platform.ac, we actually work with all of them, yeah. And we have an Indian partner as well, who does the AWS sizing and the AWS implementation. So if they don't want to get, go any of them, and they're looking at cheap infrastructure, we go to this particular partner and let them do the sizing piece. As I mentioned, we are very focused on Drupal, we were just focused on Drupal, all 180 people, all on Drupal, and Angular, right? So very focused on one piece, no designs, no infrastructure, no marketing bit, nothing, we're just going to focus on one thing. Okay, so that essentially is a relative estimation, right? So you put looking at, let's say, you know, you say that a sign-in, you're going into, and you know, just signing into a firm, right? That's probably a one-story point. You're looking at, you know, then a particular different story, which says you create a few blocks, right? That is a, you know, probably three-story point, that's much larger than the simple sign-in, right? So it's again a relative estimate, basis of what the understanding is from a complexity point of view. Yeah, so again, I think we've been working on that, right? We've been working on that. We've been trying to templatize that, yes. You know, for a training point of view, we haven't really done that. You know, it's usually a lot of responsibility that lies with me, the product owners, to really define these epics, right? You know, sales teams are responsible, the sales people are responsible to define the starting bit of, you know, doing the demos, doing the, you know, initial understanding, but then this product owner comes in and does all these, you know, epics defined, right? Yeah. Yeah, story points, right now, it's velocity of sprint for two weeks. For two weeks? For two weeks. For a sprint, correct. So the velocity is for a sprint. Yeah, one sprint. So it depends, right? How do you want to do it? So we are doing in a sprint. You want to do in a day, you can do that. It's not going to really change a lot. No, it's then, you know, we have a burst team capacity defined. So we have an extended team defined and say that if you don't go in, we're going to do an extension of the team by a sprint, right? And that's going to cost you this much. Fantastic. Thank you.