all right good morning welcome everyone the webinar is going to start about three minutes we'll stop at 3 after the hour um while we are waiting for others to join please tell us in the chat your biggest challenges to getting requirements and documenting them properly feel free just go ahead and type that in in the chat awesome we're getting some feedback here adequate feedback yeah definitely challenge um users understanding what they're asking for yep speaking the customer language absolutely that can be challenging um we know our business and it sometimes we don't always connect clients not understanding their own process or how about clients who don't even have a process and they're hoping you have the magic answers all right new to service now getting to grips with the platform yep and the challeng is that it brings absolutely our developers often want more requirements than our business analysts provides almost as if they want all the requirements before coding begins what a crazy concept yep I totally understand that one understanding the acceptance criteria yes that also kind of goes back to you know the language barrier between the business they just know that they want this fancy button on a portal as an example um we on the on the on the technical side we want to know well what kind of button what should it say what should it do when should it present itself yes absolutely understanding system limitations that's a big one um I don't have an easy button Ryan if you have an easy button please feel free to share that with me many many button yeah all right all right three after we're going to go ahead and get started with requirements Gathering and story writing Workshop rayan I'm gonna pass it over to you yeah thanks Jen uh this got to start off with our um Safe Harbor first so you can cue me up on that Jan so everybody can read all the legal jumbo uh this presentation may contain forward-looking statements that reflect the current beliefs of service now and are based on current information available these forward-looking statements should not be reliable upon in making purchasing decisions so now that we got that out of the way we'll start talking about the good stuff uh Jen you want to move on to the next slide we're gonna start off with introducing ourselves so welcome everyone thanks so much for joining us um my name is Ray Anne priki I currently live in the Netherlands and I have been in the service now ecosystem for a little over six years now and what I mean by the ecosystem is I started off as a customer like many of you on this call and I was using service now and once I saw it I fell in love with it and I decided to make it my career so then I moved on to working for a partner in just implementing service now so I've been doing that for around five years uh worked for the partner for a couple years and then I um moved on to service now three and a half years ago and I've been implementing with customers uh could be potentially some of you out there as well um in just implementing I um my current role is as an engagement manager and you're going to hear Jen and I today we've got two different roles I play the role as a engagement manager some of you it's very very very similar to a project manager and so my responsibility is managing the schedule and the scope and the the money um and keeping everyone on track and so story requirements are such a pivotal part of a project um for us that I I'm really passionate about this topic because it really sets you up for a successful project um it's just one of the most important phases so um I'll move it on over to Jennifer hi thank you Ryan hi everyone my name is Jennifer Dew I'm a principal business process consultant here at service now um my journey very very similar to rayan's I've been in the ecosystem about 10 years and I started on the customer side so I remember my first um implementation I was on the customer side I was a system admin I never heard of service now before and it was like Hey surprise let's do this and I fell in love um from there I stayed on the business side for a little bit helped out with some product management you know got into that's where I got and fell in love with the Strategic portfolio management product I then went to the partner so I started implementing and Consulting on um re related to service now and then about two and a half years ago I came to the Mothership I came to service now and I have loved this journey ever since um when I was at the partner and at service now I played the same role as the business process consultant so I feel many of you the comments that you put um in our chat because I live that every single day I Implement our strategic portfolio management product so I'm meeting with customers all over the world who have fallen in love with service now and who want to implement SPM and during our plan phase we're doing our workshops we're Gathering our requirements and as we touched on early I have to be that translator almost between what are you trying to say and What needs to be said so that we can ensure that we are meeting those business objectives excited to be here all right let's keep going so we've got an hour today and um we're Jen and I will we'll share some information with you about Gathering requirements for product implementation so it's all a lot around implementing those products in service now um we'll cover the basics so what our requirements and why do we do them and then we're going to share some tips with you which we'll and we'll get to answering some of your questions as well or maybe even your challenges that we're seeing in the chat so we we'll we'll get to commenting on those as well um we'll also share some CH common challenges ourself that we're seeing um and we'll give you some um uh really some solutions to those and try to help you along the way and that's really the goal so this time is for you at the end we're going to have some Q&A but if you have any questions please place them in the Q&A I can see that there's already one in there from Kathy so thank you Kathy and we'll you know we'll we'll we'll answer those throughout the session as well so um we that's where we'll be spending the next uh few minutes Jen you want to move on so today's session is part of what we call live on service now and maybe you've attended some before maybe this is your first but these are really curated events that they bring experts within service now in front of you to really try to help you understand how do you implement your products and achieve your value faster that's always our goal so we hope you join us again we'd like you to just take a little bit of time and scan this QR code and this QR code is going to give you a link that'll allow you to see the other webinars that are coming up I know I when I was a customer coming to these events was really helpful it really helped me to learn a lot and and connect with the community as well so um before we get started uh you know click that QR code I can see also that we've got one in the chat so you can use it um in there as well if that's a little easier for you and then at the end of the event just to just to let you know um you will be getting a survey that you'll receive we really hope you can give us feedback on that survey we're always trying to improve what are you looking for what what other kind of sessions would be valuable for us so please try to take less than a minute and fill that out so what's the goal of the webinar today uh today's goal is really to provide a clear understanding of why we gather requirements for product implementation and why that story writing is so important it's we're going to give you some guidance and tools to help you become proficient in that area so Jennifer and I play two very different roles in a project but we balance each other out really well so I as an engagement manager I spend a lot of time in ensuring that those customers requirements that we're hearing are are outlined so we can I can put together the estimates understand how big is this project what would our timeline be and what can we get done and set those expectations for the customer whereas Jennifer's role she's a business process consultant and she's the one that's Gathering those requirements so the two of us together are really it's these requirements are really important for both of our roles um and we'll we'll talk a little bit about that today okay we're going to do a couple polls throughout this session um the first poll is coming up on your screen now and we'd like to know before we begin and get too deep into this like help us understand what is your current project management environment I can see some some results coming in here these aren't all of the potential answers that you probably could have so picked up one that best applies to you but um we just kind of want to understand where what we've got out there so we got some that are working in agile but there's no standards some are waterfall very few in waterfall um and then some have pmo and standards it looks like yeah give everybody maybe another minute till they start to come through okay we also have a question in the Q&A box you want to hit before we move forward yeah yeah go ahead Jenifer okay so the question has um it's as a process owner or business analyst often we need to send workflow diagrams to the business but so far I don't see any option to extract a multi-page workflow that doesn't fit in a page to print screen from the workflow editor screen to an image or a PDF how do you manage this with um how do I manage this challenge that is a great question I'm on the SPM side so we typically don't have a lot of complex workflows within the workflow editor what I typically do as a business process consultant not as a technical consultant so I'll put that I'm not techy um I use tools as miror or as Lucid chart to really identify those flows because from a service now workflow perspective trying to share that with the business it's G to go right over their head they don't really understand our if then or we're going to have this so I find that I really need to simplify those workflows in just little think of oh what was that just had a blank um like the art web tool that we like people used to use so many you know years ago go get a box and then a triangle or something for your de decision tree but I find that I really need to simplify the workflow so that the business understands what that process and workflow is and then we can now articulate that to the technical team and then they use the tools as workflow editor and so on and so forth yeah good and I and I see that for most of my bpcs as well so I as an engagement manager when I'm on a project I get a different bpc often so I I get a little bit more of a diverse group that I'm working with and I'd say that's what most bpcs are doing as well trying to really break it down in a simplistic way and for the business so that they can see it a little easier than what's in that um I know that would be easy and nice but yeah we I usually see that as well trying to really break it down in a simplistic way for the um for the businesses so I'm going to share the results um of the poll and and it looks like we've got um you know some are kind of ad hoc we don't have a p pmo not many uh looks like that most of you are working in agile but there are no standards that's pretty common as well and then about half of you as well in the larger group have a pmo and standard so um we got a little bit of range of folks out there um and what your experiences are okay Jennifer let's move on to to the next slide I don't think we have any more open questions in there so what are requirements and why do we gather them it it it you know we've got a wide range here of everybody that has different experiences so we're going to kind of step back and make sure that we understand a little bit about what we've you know what we've what what our requirements and why are we even doing them so maybe we can start with that Jennifer can you help us understand like what is a requirement and why do we even gather them start simple absolutely absolutely so starting simple I'm going to continue going down that simple path requirements identify the needs and expectations of our stakeholders we take those requirements we write them in the form of a user story and that's where we document that feature or the functionality from a user perspective and why do we do this we do this so we can ensure that our project is meeting our requirements and the desired outcomes of our stakeholders so with that we've got another Poll for you how confident are you in your ability to gather requirements and write user stories that can be used for development and testing nice we got got a lot of mediums coming in which is nice got some highs out there you you you all should be putting in your you know feel free to put in the chat as well any if you if you have any suggestions for anyone we we'd love to hear them as well and while that poll is um going one of our Q&A do we have a template that we use to gather requirements of course we do especially on the SPM side very type type A over here um we are actually going to get to some of those templates in a few slides so you'll be able to see um how we capture them here Jennifer we should mention now create as well for everyone um if you haven't if you haven't been out there definitely recommend going out to now create go look at what we've got we as implementers use now create as well so that's how we run our projects there's a lot of resources out there um for you beyond storywriting it's just how to run a project and a service now project in and getting down to the granular level of what that product is so if you haven't looked into now create I would highly recommend you spend some time in there okay we've got looks like we got some medium about 64% of us are medium confidence we got some highs and a couple with low confidence as well so hopefully hopefully we'll give everybody something today that they'll learn from I'm going to stop sharing that share the results okay so uh Gathering user stories really needs to be a structured and collaborative approach because that is what is going to give you that product project success that's what we find and as a project manager that's really important to me that we really are structured in gathering these requirements Etc so Jennifer what approach do you use in gathering your stories and working with your customers awesome um first workshops I mentioned a little bit earlier that plan phase of our engagements we're going to have our workshops and what we're talking about from a workshop perspective we are meeting with our stakeholders our stakeholders I always want to ensure I have my three PS in those workshops I have my platform owner I have my product owner and I have my process owner as a process consultant my process and owner we're going to be besties now it's okay if your customer or your organization does not have three individual people for that that's okay you want those hats though you want to understand that from or want to ensure from a platform perspective you've got that governance there there's going to be some amazing requirements that are going to come out of that workshop and the platform owner is going to cringe a bit because they might go against some of your technical governance so they need a voice you want that product owner so I'm going to keep using SPM as our product example as that SPM product owner you are very close to your product road map and what is it going to look as you continue to scale your product and the platform you need a voice you might have some areas of the business coming in and saying I want to do this and this thing is going to be this Global thing and you're like I don't think so and then you're process owner we know that the platform does not solve everything you need your platform and your process to coexist and come together so that's why I want to make sure that they're all together so we invite our stakeholders to our Workshop so that they have the opportunity to on those future State capabilities we showcase here's how service now works out of the box now let's talk about your process and what gaps or opportunities do we have the stakeholders um oh I mentioned the stakeholders we want to make sure that are present and then they're the ones that we're going to go ahead and capture those requirements from while we document those requirements we will also ensure that post workshops we are going to meet with our stakeholders we are not leaving our workshops with 100 % refined requirements I call them more of a soft requirement you we believe we want to add a certain field to the form well is it going to be a calculated field is it a drop down is it a free Tex is that field going to move from one form to the other so we C we capture that that softw requirement post Workshop we're going to have refinement sessions so you might have some action items for your customers or from your for your business hey you want this field it's going to be a field that is going to populate data I need that data let's talk about it where is it going to live and then as you're going through that refinement you're also going to have a final formal approval session you will read back all of your requirements we are all human we're going to get something wrong it's okay you're going to read back that requirement and make sure did I capture your intent do we have the user identified appropriately do we have the why do we have the need is our acceptance criteria does it make sense and then you're getting get all of that approval and then you move forward into execute all right let's pause real quick we got two questions do you mind if I grab one of these Jennifer you probably know which one I'm G to grab so I'm going to grab deil lenina um which is May this maybe a little off topic but I still want to ask I'm a I'm a service now developer but want to change my role to business analyst so can you tell me if business analyst role and process consultant role are similar um and I would love to answer this because I'm super passate about just careers within service now and making changes um I will say deini they are very similar I think there gets to be some confusion it's a little bit about a title um the business the process consultant I think is we use that here at service now business process consultant it's a little bit more entails a little bit more than just understanding the business process it's understanding that tool as well within service now but it does mirr a ba role a lot lot and the reason why I wanted to pick this question as well is I would like to just put out a a call there um for service now's Rise Up program we have a lot of great materials out there if there's any of you that are um maybe working in stories but maybe you don't work you joined today you want to learn even just a little bit about service now but we have a riseup program out there that helps you to look at what career could you have at service now and deina we have a ba path that you could go and look at and that's really a path that that Jennifer is is that that kind of leads to her role as well so um kind of kind of similar uh very similar but I think it's just a little bit more um the consultant term after is more to kind of marry up between just analyzing the business and then also mirring up with the with the product itself so um do we want to look at that other question Jennifer um yeah When We Gather requirements do we need both use case and user story to capture all the requirements or user story enough for the same purpose and how do we decide what all documents will be there based on the project requirements that's a great series of of questions um I would say that for the first part user story and the use case your user story should contain that use case so in a few slides I think yep in a few slides where will'll get to that when it comes to the documentation on the story it's going to vary um what type of story are you documenting one example you're going to create a new security group for a particular Persona you're going to want documentation there who are all of the users you want that template um attached to that story if we're creating a project template as an example we're going to create a project or maybe a series of project templates that we want our project managers to have access to when they're managing projects in the service now platform we're going to have some attachments there documents there um I do like to work I work very very closely with my developers we are we are besties um and I gauge them what's too much information I don't want to lose anything what's not enough and I've learned a lot through my career finding that that balance so it will vary based on the requirement all right let's go move forward hey we we've talked a little bit about clear and concise user stories and and how they're important and it really allows us to understand from everyone what will be completed because that's really important um in terms of making sure you set that expectation what the C what your customer we call it a customer it could be in this your in your same company but whoever you're writing these stories for make sure that you're all on the same page and it also allows the team to estimate how much work is going to be done so that's important to me as a project manager to be able to see you know Jennifer writes all these stories for me and then I can see how big is this you know what what what what does it all entail and and can we get this done when we need to get this done so um definitely something that's important to us um I'm we're going to finish this John I see that you've raised a hand um Jennifer so help us understand a little bit how how do you create clear and concise user stories awesome well we mentioned earlier that when we start to write a user story we write it in the voice of the customer I like to look at that voice as a Persona so sticking with our SPN product I have various personas I have an end user if they're the one submitting demands on a portal I have a demand manager I have a stakeholder I have a project manager so we want our stories um to be small and manageable so we document that concise narrative and it's easy to understand we also want to ensure we are capturing the value why are we doing this and in addition to that why we're going to capture that acceptance criteria this is how are we going to validate and test it so I have my Persona I have why we're doing what we're doing now I want to go ahead and test it to make sure everything that we've asked for was achieved all right I see a question in the chat how do you guys estimate the story points um do you guys have a defined procedure that varies typical consultant response it varies on the engagement so some custo so what we typically do at service now we do one point equates to one hour and we point our stories to factor in not only the development of the story but then the testing of the story when we're talking testing we're testing unit testing within the Sprint we're not talking uat that's after everything has been developed so we want to make sure that we've got some cushion in there um some of our stories can be very complex and we know we're going to have to meet with various stakeholders maybe go through some solution design our design may change based on a few things so that's how we tend to um Point our stories but I've worked with other customers that have um different variations of how they want to point there's multiple methods out there so it really comes down to what works best for the customer we we're very agile here and we'll accommodate yeah and and just to add to that Jennifer I as an as an engagement manager at the project manager yeah it's it's it's more than just that developer time of configuring it it's writing the documentation after the story it's it's to make sure that you captured what you've done it's including that testing on both sides the developer doing it the testing as well as we we here have a bpc then that tests it based on what the requirement was so make sure that you include enough in there because that's setting that expectation as well and how long something's going to take so if if I can give any advice there would be that as well well is just make sure that you put in enough time to encapsulate everything that you're doing with that story um I see that we've got um I think it's a tool I'm probably hacking your name I apologize but it says deina I'm a bpc inba and happy to share my experience to changing your role I that's great um you know that's here I'll put in another plug for service now if you're not on service now community and active in there get on it that is how I got here at service now um I I called it my Daily Yoga I got on on service now um Community just community.com and um I was I was working for a partner at the time and I would go out there and read comments from folks and meet people and connect with people on community it's just a really great um a really great platform to meet others that are doing the exact same thing as you potentially in your same line of business whatever that may be so um yeah get DEF definitely get connected I'd love to see I don't know how you two can connect but um maybe we can we can work on that um so thanks for that atol what else do we got in here from Tom hello when the slide deck and recording is shared where will I be able to find it that's a great question I know correct me if I'm wrong Jennifer I I believe that when the attendees and maybe our um admin can put it in the chat as well confirm this for us but you should receive then afterwards do we receive a yeah link or is it there go there go post it so the recording of the resources will be available right there and then we're also going to make sure that after the presentation our PowerPoint is posted there as well so bookmark that's link thanks for that um there was a question I answered in Q&A but I just want to vocalize it so that everyone else can hear about it Jason asked the question will now assist for SPM have any future to help help improve our user stories and test scripts and acceptance criteria Jason I can't wait for it um it is on our product road map so with our zanadoo release we actually did just come out with um with our um now assist for SPM we have the feedback summarization awesome feature if you haven't checked it out go check it out there's some there's a lot of content about that um we know that we want to expand that to many areas not only of the service now platform but within SPM so it is is on the road map we don't have any um indication of when it will be Rel released but I am impatiently waiting for it so it'll come all right any all right let's go I'm gonna move a few of those and I feel like there was another question yeah I'm just looking at this so um now this is you uh now create has been business process analyst role but not bpc can we get that changed into the bpc yeah that's a great question I think there's so many different titles out there and um I think we yeah I'm not sure why we do that to be honest but it really is the same concept it's it's helping you know the customer really understand their business process and um so it's probably a little bit more of a generic term all right let's um I want to keep rayan if it's okay those um two questions let's keep those in the parking lot just for a few minutes um just a time check so we can get through a few more slides we're going to have um some time at the end to go through some questions and answers as well all right going to keep us moving forward so here's that example I mentioned earlier so here's an example of a user story our user story will have a description that details a user a goal and a reason and we'll document this as as a which is our user Persona I need our goal so that the reason here's an example as a customer I need a customer survey generated in our customer portal when a case is closed so that I can give feedback from the closed cases our acceptance criteria is written in gken sty that is how we at service now write our acceptance CR um criteria we actually changed this this year I love it um it has really really helped with our business to understand what is being asked and we found that it is also really helping when they get into uat we talked earlier language between business and it is like this we are two planes just passing each other um so I found with this style it really helps bridge that Gap a little bit so that is going to be our example given I am a customer on the customer portal When I close the case then a survey will be displayed and the following questions are displayed this is where we would actually enter in those questions or if there are a lot of questions we would have that document attached to the story now when we attach documents and I learned this tidbit from my bestie rayan when we attach documents to our stories we're going to identify that document name in our acceptance criteria because there's a probability you're going to have more than one document and I mentioned our develop team rtcs they are our besties we want to make their job easier not harder so I want them to know you're going to look at this exact document to get what you need um we're then moving forward um and I can submit the survey but I cannot submit that survey if I do not answer all of the questions so we're letting them know that all of those questions in this example they're all required okay all right next up now one point of confusion we hear a lot from customers is the confusion between product theme epic and then stories this hierarchy is the hierarchy we use in our platform within the service now platform if you're used to other platforms um for story re repository Ado or jira you might be used to um epics and features so we have a different hierarchy here at service down a product represents a feature or a functionality important to customers a product can contain themes epics and stories that describe these enhancements from the perspective of a user um using that example I'm going to give you our service now example strategic portfolio management would be a product now my little disclaimer here when it comes to product and this is going to be for any of the customers here who are more product Centric and you have very mature processes the way you define a product might have little variation on that use that if your organizations Define a product a certain way and you guys are all aligned then that is how you're going to Define that product within the platform one thing I am overly passionate about if you can't tell I'm already overly passionate about SPM but it's around the data governance within SPM when we talk about portfolios programs products we want to Define them globally a product equals x a portfolio equals y you're going to find that if you do not do that as you scale and bring more areas of the business into service now you're going to have conflicts you're going to have issues so this is where remember my my 3ps that product owner and that platform owner you guys have a voice you want to standardize what those definitions mean a theme theme is a strategic initiative it's that high level concept um and it connects to the development work that's and the objective service now example our product with strategic portfolio management our theme can be Innovation management that's one of the applications within our product our epic is that highlevel requirement of features one Epic could be implementing the idea portal and then as a story it's that discret piece of functionality so here's our story as an employee I need the ability to access our idea portal from the employee Center so that I can submit ideas related to product enhancements all right ran should we pause for some questions or keep going yeah yeah let's pause for some questions I've got I'm answering one here on do we have to use the terms given you know when in our stories and we do because it really helps you just write out a sentence after it's done so it it's you know I remember when I started writing stories this all just it was kind of hard for me um because but really all you're doing is just writing out a story of who needs it what do they need and why do they need it so you really do want to include that to just really form a a proper sentence so that it's easy for the business to understand and it just makes it simplified sometimes that given when um doesn't apply you have to change that a little bit but the goal really is to try to make it a sentence that includes those three sections um what else we got in here I know Jen you wanted to hold a couple did you want to go to those next was I think it's the first two on the list go to some um I see how does story reviews oh how are story reviews done at um service now so we have our we do Sprint planning and then we also do our within Sprint planning it it differs with with product I have noticed and I think it's just because of the amount of stories so sometimes that changes but what we do is we get all our stakeholders in that room and we clearly communicate we're very transparent this this is your opportunity to talk about the requirement when we are executing your chance to give us a requirement for this engagement has sailed away we will capture those new requirements as enhancements and if we have either the bandwidth the opportunity we'll potentially bump those up but we want to ensure everyone that's a serious meeting be in attendance and focus be there so that we can go over the story do we have everything accurately identified in that description and and in that um acceptance CR criteria because what we want to make sure is that it's all accurate so then it can be estimated by our development team and then we can get into that formal Sprint planning so now we can see our team's capacity and then what stories we can complete now I think and I just want to add something to that Jen so you know I think at service now here we we we do follow the typical agile um uh ceremonies so you know we do our Sprint planning and and then we have our Sprints and at the end we do those reviews a lot of those are just aligned to uh creating a demo around what we've completed at the time so it's and we always try to put our Sprints together we try to work on that Sprint planning not just you know what what do we want to pick but we really try to finish that Sprint with something that could bring value to that customer so they get excited about it so maybe it's finishing a section of something you know an epic that that entails a bunch of stories so we really do try to do that with our reviews but that our technical uh Consultants generally do those demos sometimes the the business process Consultants do as well and that's really what we see as the review um Jen do you mind if I say one thing about this hierarchy that's still on the screen um I I will say that when I go to customers so we you know Jen and I are working with different customers all the time and they have some already um descriptions to what is a product what is a theme what is an epic and what is a user story The Bottom I think it's a little that the user story is a lot easier for everybody to agree upon but sometimes epic means completely something different and I just want to say that's okay um sometimes we can spend so much time worrying about what all these terms are this is what we do at service now I think it really helps us because as a team we we all aligned but what's most important is that you just have all of these pieces kind of placed ins something I see often theme and epic getting flip-flopped around but that's okay don't you know if if the organization agrees upon it I think that's the most important part um so don't get too caught up in the right and wrong of it um a little bit what agile is supposed to be about so yeah all right I go ahead because I know I think we only have a few slides and then we get into a poll and QA so let's go ahead and Maran I'll pass it over to you yeah so what are what are some common challenges and solutions you started off the beginning of the conversation just the beginning of this hour saying a lot of them and and we heard them and we we hear them it's you know the big ones are requirements that are not well defined it's really being clear and concise like Jen talked about and making sure that everybody understands those requirements really well um another one is the requirements change throughout the life cycle of a Sprint so you're in the you know you're you're in the middle of a Sprint and somebody says oh yeah actually I don't think we want that anymore and that gets to be a challenge you know it it definitely does and then the the the two that really are really important and Jen talked about this is the lack of involvement from those stakeholders we sometimes get them at the beginning but we don't get them throughout and so it's really important to keep them Linked In so at the beginning when you're hearing the requirements but also as you're going through your Sprint so that you make sure that they're aligned with what is happening because sometimes like Jennifer said we're all humans and we're you know we're trying to do our best with communicating in those stories but sometimes there gets to be some mixup there so you want to keep them involved and then the miscommunication between stakeholders so sometimes you have multiple stakeholders that are trying to align to a process and that doesn't always work so you want to um you know you want to keep them connection so what are what are some of those Solutions really hosting regular stakeholder meetings really keeping good relationship with them and make sure that they um are invested in the project throughout the whole entire um clear and concise stories again good documentation good good story writing and then um being flexible as well sometimes you know we we talk about this documentation and documenting everything really well and Etc and agile is supposed to be agile right that term itself means being flexible um but you have to have a balance there as well you really have to find a balance of um making sure everything gets documented well but being flexible when you can so that you can stay on the schedule budget whatever your timeline is so okay let's um I'm just going to do a quick summary and then we're going to move it into Q&A um so we all know you know as we talked about Gathering requirements super important critical step to the success of any implementation of service now and focus on your users really spend time on who are they what do they need and what are those Persona requirements so get down to that Persona level make sure that all stakeholders are involved from the beginning as well as throughout the entire implementation and then be concise and clear and um following you know what Jenna jennif you know had shared with you earlier about really trying to get down to what exactly they want so let's do one more poll um before we open it up for questions which we'll probably just answer some of these but as you're answering the poll as well start thinking about some questions you have um so since attending this webinar how confident are you that you'll be able to gather requirements and write stories that can be used for development and testing looks like we've got results R yeah yeah yeah yeah we got some high confidence that's good that's good I got some medium we're about half and half yeah I will say that you know when it comes to this question is um as I start when I began writing stories I used to be a business process consultant myself Jennifer and I were peers uh so we so we definitely um that's how we know one another and when I was writing stories I remember it was so hard at the beginning um and I think the most important especially those in the low and those in the medium um it's it's just get in there and practice and it's get in there and you know you just just like anything that we do at work but you really got to get in the groove and soon it becomes I mean I I can watch Jennifer she can just listen and just pump out a story in no time you really do get there because you you start to change your mind to how do I take this what I'm hearing from my customer into the story format so it does become much more comfortable as you just get in there and you got to practice yeah yeah awesome and then um one thing I want to just touch real quick Angela posted I know this is so much to remember this was like information overload um as a reminder recording and the presentation will be posted on the link that we provided in the chat so make sure you grab that link because we do have that template on the story how to write the story how to write to your acceptance criteria as well as our guidance there's also I want to um touch on I forgot to mention it earlier on now learning there's actually a bpc course and it does touch on it doesn't go into as much detail as Ryan and I did here but it does touch on requirements Gathering so if you have not taken that course I highly highly recommend it especially if you're early in career or early in that bpc ba role I think you're going to get a lot of great um touch points from there yeah it's another good one so now Community now learning now create really great great resources Jennifer I'm going to go to the there's a couple questions that are in the chat so maybe I'll I'll start with one there are yeah I'm gonna move over us to that was not a grammatically correct um statement I'm gonna move us just to the questions uh we'll get into our Q&A here we go go ahead okay do you want to go through the questions in yes sorry sorry yep yep yep okay so um first in the chat I'm reading um how do you come to Common Grounds and requirements when different clients want to achieve same goal but with different processes great question great question right Jennifer it's like you're you're dealing with same company but different organizations departments whatever it may be I don't know Jennifer what what are some things that you do yeah so within I see this all the time now it varies um I mentioned that typical consultant response um it's going to vary but here's why because sometimes your processes from business unit to business unit or team to team are vastly different your end result yes we're all going to manage a project record or a demand whatever it is it's okay to support those various processes I've worked with some very large scale Global organizations that we introduce both of those processes in but you want your process owner and product owner to agree to that they're almost going to say I support that you're going to have using SPN as our example we have a standard process for large scale projects and then we have a standard process for enhancements so you're going to get into that room sometimes it's a virtual room and not that you're going to Duke it out but you really have to talk through that process end to end identify where you have connectors you might find that you can consolidate and go into one process but you might find that no you actually do need two processes because all of the activity that happens maybe in the middle they're very very different so it it will vary yeah and I I'll add to that Jennifer just to say sometimes and this and it's hard to know what's leading into this question but sometimes you have almost like a conflict of it one wants one one wants another I will say a lot of times I see our bpcs they're making some recommendations because when you get an outsider perspective on it um so one wants this one wants this it's like if we can if we as The Outsider can make a recommendation kind of bring together the best of the best sometimes that helps as well so it just depends on if they're different different processes that you're trying to bring up or not okay do we have another what other question we have some Q&A that um I kind of just put on hold from earlier so I'm going to start getting that list um is there a perfect balance between including enough technical details in in the description of a story to get the desired outcome without adding too much my rule of thumb is just mine um I'm not a developer not going to tell the developer how to develop that is on them they have the expertise to know is it a business rule is it a client script is it a yada yada I'm going to write the requirement so as a customer I need the ability to submit feedback when I'm on this page on the customer portal as an example how they develop it is up to them so that's what I that's the process that I follow um a lot of the bpcs here we follow the same thing we want give that creative freedom to the technical consultant now at times we will work hand inhand with that TC because the solution might impact the process so depending on the requirement you might have to have some conversations with them to talk them through and say I recommend we do something like this but I do not get technical in my story writing or in my acceptance criteria all right yeah so so here's another um I think I just lost that one there was a question of um Can agile really be used in service now project since um I think it was since it's there's a lot more configuration than there is development and I'll say we run 100% of our project work um is on agile stories so obviously we have a project plan as well that's very waterfall but when we talk about what we're doing in the tool every single thing has a story so so if you're just if it's just a configuration of adding a field that's a story so yeah agile definitely can be used for service now projects and it's just I as a user need a new field on this form so that I can do XYZ so even if it's simple it seems simple but yeah absolutely we write a story for everything um how do you priori your stories maybe I'll grab that one uh Jennifer is um because that's good A lot of times what what we do is we come in to uh we're not in an organization that stays forever we're coming in to implement something and even if you're you know a certain deliverable that we have uh Implement strategic portfolio management and do these five things that we want to accomplish by the end I think that's important even if you're in an organization that lasts forever you know create your epics or whatever around getting a deliverable so you can kind of have a start and an end but it's um you know well how we prioritize then is once we determine what the business's priorities are then we have to pick those stories to match it so then we do our Sprint planning we say okay we've got an X deliverable that we need to achieve and then we have X amount of stories and we put them together to align to that you know deliverable based on again our Sprints are going to always have something at the end that they can test and look at so that's how we prioritize the order now there's also a priority of you got this huge backlog you know you got a huge backlog that they want to do and that we really rely on the business to put together a governance around what's important to them and that's always you always want to make them identify at the beginning what are we trying to achieve at the end or how are we going to measure this at the end and that helps us understand what our priorities are because you're always you're always going after that goal all right we've got do a quick time check okay uh another question we have in Q&A what do you consider to be a good practice on transitioning the requirement Gathering to accept to the acceptance criteria to user story we talked a little bit about this um early on so in that Workshop that's where we're going to capture those requirements so they're telling us I want the tool to do this I want the tool to to do that as a business process consultant we're then going to take that high level requirement and we're going to break it out um and that's where Ray ranne touched on this earlier a part of our role is we're intimate not only with the process but the platform capability if someone says I want an assessment in demand as an SPM bpc we need to know and understand there's an out-of-the-box risk and value assessment that already exists is this customer mature enough to use that out of the box assessment or do we need to build a new one maybe it's not a fullon assessment maybe it's a few fields on the record so you do want to make sure that you have that knowledge so then then you can start to write that out same with the acceptance criteria you should be able to pull information for your acceptance criteria from that requirement because you've already identified who that Persona that user is the what and the why we also work with our customers this is not a oneperson show you're not just writing the requirement crossing your fingers and hoping for the best no you're going to work with that customer here's what I heard did I hear this correctly do we need to alter a little bit of this so that's what um I recommend there's a lot of collaboration when you're in that that plan phase I'm gonna try to tackle a couple questions here at the same time we've got one that says can you tell me more and expand about the importance of the relationship between the dev and the ba um and then there was one about does the dev need or the technical person need to be at the story uh G the requirements Gathering and so one Jen says the technical we call them technical consultants here some call them developers that's exactly that same role and they're besties and because they need to work closely together to say you know Jennifer as a business person says this is what I'm hearing and that technical person is is starting to work on that solution and so they really do need it's really important for them to work closely together um and so yes we do at service now projects we do include that technical person when Jennifer is doing her uh facilitating her workshops and Gathering requirements we have that technical person there so they can hear everything that is being said because they're processing that solution out so very important uh I was actually just about to respond to one Anonymous member but I'll I'll vocalize this one here and you know how how best do you gather requirements outside of of the workshops um it's very typical we're in the middle of build and we get new requirements that come in um you have to have a plan in place beforehand on how you're going to handle that um some customers you they find that you know we have some critical gaps that have to be addressed we will write either the enhancement record if it's tied to an existing story or a new story that we place in the backlog um what I do is even though it's a backlog story I like to get that refined as much as possible get it estimated so in the event that we have a room to put it back into a Sprint we do there are times where our customers have have so many great ideas that we just can't deliver everything within an engagement so we leave them with that backlog um they'll have that backlog of stories and then they know it's all an iterative cycle we've mentioned multiple times we follow an agile methodology so we do the implementation and then we leave them with some backlog stories that they can now prioritize and get into that release future State all right um there's another one I wanted to address earlier someone mentioned about a statement I made on um changing how we change how we capture um we did not change how we capture the description of a story so that given all um we captured we changed how we do our acceptance criteria we used to write I know this is complete when and then we'd have all these bullet points of you know that acceptance criteria Now using the girkin um uh standard we we break that out um and I mentioned earlier we found that it really helps it really helps not only the business understand it helps the TCS and then it helps with testing so I answer a couple online I I will ask Jen do you know we have a question about road map do we have a road map on agile module to capture Sprint Project Retros for retrospectives this is a great question do you know that Jen um I have not seen it yet but um for those of you who are using safe you might be aware that safe is transitioning into enter Enterprise agile planning EAP which is on top it's layered on top of strategic planning workspace I know that they do have that particular requirement in their product backlog as well as for the Agile development application so I don't have any insight into the when but I do know that a lot of our customers especially customers who are more formal and I'm presuming that in your case if you're you're doing that um they want this in our product um they're being more vocal about that I will tell you product feedback our product managers here at service now they look at the idea portal go out there put your ideas out there and vote on products or enhancements that you want it helps us because we know some of the product enhancements that we want we hear from customers but when they go back and look well how often is actually being asked sometimes there's a a big gap variance so it helps us help you um so please go to that idea portal um you can find it I believe on um the Community page there's a link to it there and post your ideas if someone has a similar idea vote that up um please please please it it really helps yeah so there's a question on here about ji and um Jennifer she knows Jenna AI is huge for us like AI is we focus all the time on every single product owner that will develop any product on our platform is responsible to make sure that they're growing in AI because we know that that's the way so I'm I'm not sure I don't know Jennifer if you have any knowledge about in project in project but there's there's definitely pieces that are getting added all the time in all of our project products y so now now assist is our gen AI tool um we've seen a lot and actually in our xanad do re release that's where we're seeing more geni capabilities our first um Peak into gen from an SPM perspective we're seeing it with product feedback which is located in strategic planning workspace we know that it there is a nice healthy pipeline to get it into project um to get into the docs the new docs component within project project workspace if you'll see it there um as well as on the story side so looking at that summarization feedback so keep up with those I know we there's a lot of release notes um but just keep um keep them tabed or on the community there's the Forum out there you'll see that when we have some new capabilities they will have events so you'll see a lot of because it is such a Hot Topic our product success team they will host various events um showcasing that capability now I know we're at the top of the hour yes that's probably you too is Jennifer so thanks gosh these were great questions everyone great interaction is always helps us out with helping you out so yeah awesome thank you all so much for attending and we hope to talk to some of you guys shortly