Mastering Dynamics 365 Requirements in Azure DevOps with Dani Kahil

Neil Benson: [00:00:00] Are you looking for a better way of managing your Dynamics 365 or Power Platform requirements in Azure DevOps. Join me with Dani Kahil in episode 100 of Amazing Applications. 
 Hi, how's it going? I'm Neil Benson and your host for episode 100 of the Amazing Apps show. 
I've just celebrated my 16th wedding anniversary to my amazing wife, Natascha. We had a blissful weekend without the kids in Noosa. And last night as we were falling asleep do you know what she whispered in my ear? "How do I listen to podcasts? Do I find them on YouTube?" 
Although I've been podcasting for over three [00:01:00] years now and produced, well, this is my 100th episode, my wife has never listened to a single one. Maybe that's why we're still so happily married.
But I'm glad you were here and I'm grateful to have you in the audience for this. Special, thanks to John Bordin and Olena Grischenko for generously supporting the show through the show's Buy Me a Coffee page. I really appreciate it.
You can support the show too by visiting AmazingApps.Show and either subscribing to the email list, buying a t-shirt, leaving a review or Buy Me a Coffee. 
Let's get into this episode with Dani. Dani is a freelance Dynamics 365 solution specialist based in the Gold Coast, which is just down the road from me here in Queensland. He is a two-time Microsoft Business Apps MVP and well known for both his colorful shirts and his colorful solution architecture models. Dani's presenting at DynamicsCon in a couple of weeks. [00:02:00] I invited him onto the show to discuss his presentation topic, 'Managing Dynamics 365 Requirements in Azure DevOps'. 
And a quick apology. I had left on the receiver for my wireless mic. So there was a little interference on my wired mic in my interview with Dani. I cleaned it up as best I can. But the important thing is that Dani sounds great. Here he is.
 Dani, welcome back to the Amazing Applications show. It's great to have you back on the show for a second time. 
Dani Kahil: Thank you, Neil. Thank you. Thank you. And great to have you again. And talking to you.
Neil Benson: You were with us on episode 54. It was actually July, 2020. you were sharing with us, a case study of Lives Lived Well, one of your local clients, done an amazing job, and they were happy 365 customer. This time you're coming back to talk to us about your presentation coming up at DynamicsCon in a couple of weeks. title of your presentation is "Best Practices Manage D365 Requirements in Azure [00:03:00] DevOps". So, fascinating subject. Very close to my heart. Looking forward to hearing all about it. 
Dani Kahil: Yeah. Amazing. Thank you, Neil. And look, let's see if I can respond to all your tricky questions. 
Neil Benson: Well, so I do love a good requirement and I'm a big fan of managing those in backlog like Azure DevOps. Most of my projects have been using JIRA recently. JIRA is many more popular here in Australia than elsewhere because Atlassian is a big Australian software company, but I'm curious, and I'd love to build up my expertise on Azure DevOps. So I'm definitely gonna be tuning into your session. 
First of all, I'd like to ask you, ' Why use Azure DevOps'? Let's start there because I see requirements particularly Microsoft customers. They give us their requirements in a spreadsheet. Often as part of a request for proposal. What's wrong with just managing requirements in a spreadsheet, Danny? Why use Azure DevOps at all? 
Dani Kahil: Yeah. Thank you, Neil. I guess look, you, you can use a spreadsheet, but the problem that you often get is[00:04:00] that spreadsheet will grow with columns and hundreds of line of requirements with comments everywhere, with colors everywhere. It's Excel so it might sometimes take a bit of time to load. If it's huge, how do you manage? It's so open with all the columns, you can do whatever you want. The filtering as well of the columns doesn't help. So actually during the session at DynamicsCon I'm sharing shameless story, it's almost covering a story that happened to me where a client started using an Excel spreadsheet and then what happens? So I won't reveal the whole story. So tune in, and then you will see why I then recommended Azure DevOps. There is a full explanation. So you will get the other part of the answer, Neil, at my session. 
Neil Benson: Great. Give me another excuse watch. When do you think is an appropriate time to capture requirements? Do you think, in a procurement scenario, there's a tendency to try and capture all the requirements upfront. Is that still a good practice [00:05:00] or is capturing the requirements during the development process where those requirements are emerging as you build features? Is that a better practice? Have you got a strong opinion either way? 
Dani Kahil: I like to have at least the high level requirements. So in term of structuring and how does requirements work, at least for me, right, where I like to have at least a high level idea of let's call it epics. Kind of the big items that the solution is about, right. If you're going to implement a case management system, it's managing cases, it's knowledge management, it's maybe queue management, it's portal those big items. What is the big epic that we need to implement? And then having a level down. Which is the level in Azure DevOps, you have epics, I use features. 
Features, which is more. So epics would be, I would use use the business translation of the requirements. So customer portal in Dynamics that would be Power Apps Portal, maybe Virtual Agent, and so forth. So I would at least [00:06:00] go to that second level if possible, the level of user stories is probably two months before, at least two sprints before we, we build, I need the user stories to be, to be ready. Agreed. I mean, I'm using, and I'll be writing probably an article about that, the definition of ready, which has kind of a little bit of a key on the project where I'm in now where is effectively a user story. It's going from, its infancy to being ready being built by the team. There is a bit of a process and that step where it goes from in analysis, so to speak, to in dev it's what I call the definition of ready. So I guess having the definition of ready to respond to your question would be at least two sprints before the build start.
That would be how I typically try to do. 
Neil Benson: I'm the same. I like to have little bit of a buffer [00:07:00] of requirements that are ready for development. Quite often though, the way our teams sprint, the analysts are having to work really hard to build up that buffer and then stay ahead of the developers. I always picture the developers like little chicks in the birds nest, or they're just cheap, cheap, cheap.
They want more requirements and the have to go out and find the worms to drop into the nest feed the hungry birds. 
I like that idea of having a two month backlog of ready requirements. The challenge I've got with one of my current clients. One of the parts of being ready is that the user story has to be approved by all of our stakeholders. I'm not a big fan of, of an approval step. We're 
Dani Kahil: yeah, 
Neil Benson: supposed to have a product owner. 
got the ultimate 
Dani Kahil: yeah, 
Neil Benson: and she should 
Dani Kahil: yeah. 
Neil Benson: Be able to approve, on her own, any of the user stories in the product backlog. must have had clients like that as well. What do you think of an approval process in the middle of your requirements analysis? 
Dani Kahil: Yeah, no, I totally agree with you. And in a matter of fact, it's definitely something [00:08:00] that we recommend is, and we have dealt in the past with project with multiple product owners which is, is tricky. Very, very tricky. But it always takes time, right? It takes time to coach kind of the client and explain the reason why.
And it's a learning experience. We say, you see how long it takes? Let's take one product owner. It's fine, if you take a few days to check with everyone in your team, if that makes sense, but you need the one that needs to be able to make the decision fast enough for us to move. 
So, I guess, one product owner. What I usually have is in Azure DevOps is, and I'll cover that in the session as well. How I manage that, but I use that it's not really a state. I use a flag, I will reveal one of the secrets of the session that I will cover. But I use, I use a flag called product owner review on my stories. And whether that is for reviewing the story to accept it to move to dev, [00:09:00] or if it's for a story to be reviewed while it's almost finished and we want to start putting in UAT. I flag it for the product owner. I showed you this have a quick read at the story that makes sense so that they can quickly filter that.
So I guess that approval or formal approval would just be for me, the product owners accepting the story to move to dev.
Neil Benson: Everything in Azure DevOps is an item, is that right? Cause everything in JIRA is called an issue. You have different issue types, I think in Azure DevOps they're called items. So a user story is a type of item... 
Dani Kahil: Yeah. 
Neil Benson: You can have others as well. What do you recommend folks use in Azure DevOps for different item types? 
Dani Kahil: There are a few process that you can choose from. Instead of, so there is the agile, the scrum. I use the agile one and tweak it a bit with my, with a few, a few new items. If I need to, like, I definitely use epics. Features, user story, task. I go to the level of tasks where the task is to assign items to my [00:10:00] team members most of the time or task to myself. So I have a user story and the user story consists of configuring the scheduling board. Well, one user we create, maybe one of my, uh, developers will kind of work on the view to make it work. The other one will work maybe on the filtering options. So I create specific task for them. And we can also track those tasks. 
I've used as well bugs, definitely. So you have your test plan, test suites. It's usually one consultant, one tester, really building those out.
What else do we use? You can create your own items. So I've used, for example, in the past a document. A document item, because I find in Azure DevOps, you attach attachment into the items and it's a little bit tricky. 
The problem is each time you want to make a change. If it's a Word document, each time you may want to make a change to that document, you have to download it and upload it again. Right? So it's not flexible enough, especially if you have mapping [00:11:00] tables, Excel spreadsheet, with mapping between an event needs to create a case needs to create an event and you have mapping fields. You want to maintain that to kind of continue on working on that somehow. It's terrible if you use the standard Azure DevOps. So what I did in the past is I created an item and called Documents. And then in that document, I have a link for example, to a SharePoint, 
Neil Benson: Yeah. 
Dani Kahil: file, if that makes sense.
You can also add your own fields in items. So now for another client, I have a field called Document Location and then I use that document location to point to the correct document. So there is various way of dealing with that, but those would be the items that I use.
Neil Benson: So I would also use spikes and chores. think a chore and a task are very similar, but I don't use tasks in the same way that you do. I don't use sub tasks a story. I have used them in the past. I just didn't find them useful 
enough 
Dani Kahil: Yeah.
Neil Benson: we would always have tasks, like analyze the requirements, [00:12:00] feature, test the feature, deploy the feature
into staging 
Dani Kahil: yeah,
Neil Benson: very repetitive, little tiny waterfall every user
story 
Dani Kahil: yeah, yeah,
Neil Benson: It just wasn't adding enough value to us. And teams even go to the additional effort of estimating sub-tasks often in, in hours to figure out their capacity in a sprint. I just think that's a whole exercise in futility. I keep it at the story level, but I might be on my own there.
Dani Kahil: But that's, that is how that Azure DevOps work for your sprints, right? If you want to estimate your capacity for a sprint, it's the hours that you put at the task level. The whole sprint in Azure DevOps follow that way. There's no other way almost of doing it, 
Neil Benson: You talked about the different processes and Azure DevOps. I think the Scrum process, at least a couple of years ago when I tried it, it was very much configured for the use of sub tasks underneath user stories. And so I didn't use the Scrum process in Azure DevOps. In my Scrum projects. I used the Agile process, which was a little bit more flexible and didn't insist on having, [00:13:00] sub-tasks,
How do you handle defects in Azure DevOps? I just had one of my team members today, the quality analyst, asking me if we want track, defects in a user story before it's done. So it's been developed this sprint, got kind of to the end of the development the tester is testing it and he's found an issue. 
he create a defect? And we track that in our scrum board? Or we just make some comments under the user story, and we put it back a stage in the development process? How do you prefer to handle defects during development? 
Dani Kahil: Yeah, look. During development, so you're not thinking about any end user testing, you really talking about bugs raised during the dev, right? Within the team, yeah. Usually it's a comment to be fair. It's a comment in the story. 
And if it's something bigger, I might ask my team member to say, look, if it's something bigger, I need a bit of time to kind of think about it or another team member to spend some time maybe that it's worth creating then a bug. 
As soon as it moves [00:14:00] to UAT or outside of the dev process, create bugs, even for small It's Berks and it's assigned back to the, to the backlog and then we work on them. But during the dev process, yeah, it's a little bit more flexible.
Neil Benson: Yeah. I'm the same. I like to keep it lightweight during the development process.
Do you estimate the effort it's going to take to resolve the bug, or do you handle estimation around bugs? 
Dani Kahil: No, we don't. No. I mean, if it would be a big one. I was trying to think of a situation. I don't think so. No, we haven't. I've never estimated bugs.
Neil Benson: I'm the same. I think some people like to do it from a capacity planning point of view. 
Dani Kahil: Yeah.
Neil Benson: But what I like to do is leave them unestimated. I don't estimate spikes or chores either. 
Dani Kahil: Yeah.
Neil Benson: If we need to work on a lot of defects, a lot of spikes, a lot of chores, we just reduce our story point forecast for that sprint.
Normally we let's say we can go at 40, well, got a lot more defects than usual. Let's only do 30 points of new user stories we'll see how many of the defects we can get [00:15:00] through. And the danger of estimating particularly defects you kind of double counting the work. I did the five point story and it had a bug. The bug was two points. just delivered seven points worth of work? Not really. I should have done it in five.
Dani Kahil: Yeah.
Neil Benson: So if your velocity calculation includes the effort spent on bugs, then you're double counting. 
Dani Kahil: Exactly.
Neil Benson: All right. What else can we expect to see in your presentation, Dani?
Dani Kahil: I'm covering mostly how I structure requirements. Uh, so I think what I shared with you here within more details about my epics, features. How I like to capture them. When I capture requirements there is a bit of a life cycle of requirements. It goes from, very small and very little details to kind of the steps in the lifetime of, of that user story.
What I'm calling going a little bit more into the details in Azure DevOps, which fields are you specifically on the user story? Right? Which field when. There is a great section about, uh, the [00:16:00] discussion section that we use. Can be overused sometimes. We have to be careful because otherwise you lose track of things, but it's a great way of, of everyone kind of interacting on a, on a user story. So I'm covering that as well. And then yeah, generally the lifecycle of that user story and how I use additional tips. Let's say tips in Azure DevOps. And I won't share more in this one today.
Neil Benson: Keep me hanging. I'm always curious about people who present things like their, their tools, Azure DevOps at conferences. Are you using a real Azure DevOps from one of your projects? Do you have client's permission to be able to do that? do you have to fake some requirements in Azure DevOps in order to show screenshots and screencasts within your presentation?
do you handle it? 
Dani Kahil: Yeah, I have my own, I have my own where, because look, I write things around requirements and Azure DevOps and I experiment with things. So I have my Azure DevOps. You're right. I've spent, it's an effort that I had to [00:17:00] do, but it's a small effort that I have to do over a long period of time. I had already my stories. I played with them. I tweak them the way I wanted. I kind of experimented with them and then it's there. It's ready. I can use it. I can show it. So it was not really build everything from scratch, but no, I'm not showing any live customer data. Yeah. Yeah. I won't be able to.
Neil Benson: You talked there about the level of detail that's in a, a requirement, especially if you're coming from a background of writing big requirements specifications. There is a temptation for a user story to become a mini specification and there's screenshots 
Dani Kahil: Yeah. 
Neil Benson: charts in Excel. Then you go add some behavior driven development scenarios, BDD scenarios, and then there's a whole bunch of acceptance criteria. And suddenly, if you out, it would be dozens of pages. What do you think is the appropriate level of detail to capture for our requirement in [00:18:00] Azure DevOps?
Dani Kahil: Yeah. I use the concept of, of acceptance criteria where, when I talk to my product owner, and my BA, what, when they don't have a lot of experience, I would say, think about the rules that will make that story satisfy you when it goes for you to test and when it goes live. What are the rules, right? Give me a few of those bullet points. But the idea is not really, as you said, to have a specification document, then if my story becomes too big, I split it.
I split it into three stories, become smaller ones, and it's kind of easier. We can handle it easier. Any documents that needs to go with the story, as I told you is I would store it in separate SharePoint or Teams folder and pointed there. Right? For example, there is a bullet point saying mapping between, as I said, case to event to the field is in that Excel spreadsheet.
And then you can open it. I don't store it in the acceptance criteria, if that [00:19:00] 
Neil Benson: Yeah.
And what have you talked about getting split? Can they get too small, a field level change or something? do you handle those? You bundle them up into bigger story later. 
Dani Kahil: Yeah, I know. I never go to just one field and Neil. Uh, yeah, no. 
Neil Benson: I would drive you crazy. 
Dani Kahil: Yeah, no, definitely not. The theory says it has to be a feature of his own right. Look, I like to try to follow a little bit, the INVEST acronym, right? Where independent, negotiable and so forth.
And I think there is one way it's, it's it's valuable. It has to test to provide a little bit of value, adding a simple field, for me, it doesn't, doesn't bring the, the value. So it's, it's more about, creating a case. Let's stick. The example of the case, creating a case or. I'm not even sure I would create one for create an edit to be fair.
I would maybe consider them both create an edit cases. And then if there is something specific in editing a case that requires a story, for example, managing [00:20:00] knowledge articles in that case. Yeah. Let's create another story, manage articles in your case. Right. And then we'll add a few acceptance criteria.
Yeah. Yeah. Strict. It's tricky to explain, but.
Neil Benson: I know it's the arts, right? It's not a science. You have to get some experience at it and find out what works for you and your team 
Dani Kahil: yeah, 
Neil Benson: One final question for you, and then we'll let you go. Who writes the user stories in your projects? Is it the product owner? Who's the business person with the experience of the business domain, who's charge of the application. Or have they delegated the responsibility to a business analyst? Who maybe knows a little bit more about Dynamics, who has some experience writing and capturing requirements. How have you found that responsibility split up your projects? 
Dani Kahil: Yeah, it's again, very dependent of projects, but I haven't seen really product owners writing stories. I haven't come across that yet. They either have a BA that works with them and helps them with that. A BA that knows how [00:21:00] to understand agile, understand how to write user story. So they will help them that. 
It happens in the past where we worked with very new client to, to IT projects and even agile, where we, we guided them through where I wrote some based on the discussions, I wrote the story and presented it to them. Look, is this correct? This is how you write the story. This is the acceptance criteria. Does that make sense? And it took a few months for them to kind of understand and get familiar with that.
So I sometimes do the work, but they are responsible and they approve the story, right? So it happens also happen on bigger project where, you suddenly lose your BA and then they have to find a new BA. And we say, look, I will help the product owner. I will take over, write some stories with them the time that you guys bring in all the BA.
So it's again, very, very flexible and agile in a way. And dependant on the project.
Neil Benson: Yeah.
I'd be the same. Your experience mirrors is mine exactly. And I think that's a hallmark of business [00:22:00] applications projects that we're working with business people who are thrust into the role of product owner and they've probably never been a product owner before. 
Dani Kahil: Yeah. 
Neil Benson: They've never had a background as a business analyst.
Whereas, I think some other scrum teams work with a professional product manager and they write their own requirements. The business people that we work with, don't have that background, skill and are pretty happy to delegate it to a business analyst in the team.
Dani Kahil: Yep absolutely.
Neil Benson: Good stuff. So, Dani, just to recap, once again, you're on at 9:00 AM US Eastern on Monday, the 20th of September. People can register at DynamicsCon.Com for free. And catch up with Dani and he'll be available on chat, I think? 
Dani Kahil: Absolutely. 
Neil Benson: What time of the day have you got to get up in 
Dani Kahil: I think it's 11, but that will be out in the chart. So
Neil Benson: 11:00 PM? That's not so bad. I thought it was going to be like 2:00 AM or 
Dani Kahil: No. Oh, that's not so bad. I think they did it in purpose, so that's good. Uh, thank you, DynamicsCon for thinking about us. So I think they did it in purpose, which is great, where I would be online responding to the question in the chats who [00:23:00] really don't hesitate to ask a question in the chat, I'll be there.
And then I think at the end, I'm live 10 minutes to respond to some of the questions.
Neil Benson: Great stuff. Good. I can't wait to tune in. What else have you got going on? How else can people get hold of you if they want to connect with you. 
Dani Kahil: I'm quite active on LinkedIn. That's probably the social platform where that's probably the only platform where I'm active. You could find my blogs there. 
Neil Benson: Well done. Thank you so much for joining me on Amazing Applications we look forward to hopefully having you back for a third time pretty soon. 
Dani Kahil: Thank you, Neil. Yeah, of course.
Neil Benson: Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 
There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.
You can send me a message or a voicemail if you'd like [00:24:00] your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.
 Visit https://Amazing.Apps.Show. 
Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!