What proven practices are there for managing your Power Platform or Dynamics 3 65 product backlog in Azure DevOps? How much detail should your user stories contain, and how do you ensure that what you're doing enhances your user's experience? If you use an agile approach like Scrum to build Power Platform or Dynamics 3 65 applications, you won't wanna miss The insights that Danica Hill shares in this episode of Amazing Apps, the podcast for Dynamics 3 65 and Power Platform
professionals that wanna build amazing Agile business apps. I'm your host, Neil Benson. I'm a Microsoft MVP, and I've coached and trained Thousands of business apps builders to use scrum since I first used it myself in 2008, and I'm on a mission to help you use agile practices to build amazing business apps for your users as well. This is episode 152. If you're listening to the audio podcast, you'll find show notes with links to resources and a transcript at amazingapps.show/one52.
And if you're watching on YouTube, You'll find them in the description, down below. Here's Danny Cahill. Danny, welcome back to Amazing Applications. I was just looking to see how many times you'd been on this show before, and I thought it was 2, 3, maybe 4. It's actually 6th. This is your 6th appearance. Welcome back, my friend. Thank you. Yeah. That's my favorite show. Right? It's everybody's favorite show, Danny.
Absolutely. Yeah. Yeah. Thank you. Yeah. Yeah. Absolutely. And it's always a pleasure to, you know, discuss with you and bounce ideas, and And you have been actually well, that's why I'm 6 times, right, because you have been kind enough to kind of host some of my conversation with other guests. Right. Yeah. Absolutely. So that counts too. I noticed you've been doing a lot of work with Hamish recently. So if you and Hamish wanna do a takeover episode, you're more than welcome. We'd love to to
have you. But today, we're gonna focus on managing the product backlog, which is something a lot of teams struggle with. A lot of teams could do very, very differently From 1 organization to the next, what do you think the biggest challenge is that business apps teams have managing their product backlogs? What have you seen out there in the wild in your experience? Yeah.
So the number 1 challenge, really, what I what I see, Radey, is kind of structuring almost what is the best or what is the the right structure for The the project that you are in. And there is no I found that there there are tapes or there is way you can structure your backlog, but Every project will be different, and every project will have to kind of adapt slightly to how the client works, where they are in the journey on managing for the
backlogs and so forth. Right? So it's always a bit of a tweaking. I found myself, Like, how I use to structure the the backlog and in my head as well, and how I would recommend my clients to do if they don't know it, they just want our recommendations is I always try to follow a bit of a high level process. Right? So even if you have your kind of story map, I do I don't do often, Like, real story mapping, but I cannot follow the same process where I decompose the high level phases
Yeah. Of a of a user, of a client throughout the journey. Right? And those will be my big building blocks. It's easy for me to understand, And then I go to the level of so that would be my epics, and then I have my features, and then I go down to the level. But that's how I structure it, But it's a bit of a challenge I see, and if there is an existing backlog already, like everyone is doing it differently, like sometimes by apps, by technology Yep.
By and, you know, it sometimes it makes sense. Right? And I was not there at the beginning with the person. I cannot really judge. But if I would start from from scratch, I would strive to structure it that way. I'm not really fine. Responded directly to your question and maybe responded way more. But yep. Okay. So let let's let's tackle some of those ideas 1 by 1. Imagine Mhmm. You're in a greenfield scenario, so there's no backlog management tool there Mhmm. Today. First of all, Who
do you think should manage the backlog? Do you, as a expert in managing requirements, do you take that responsibility on? Or do you like your product owner? Who's typically, you know, somebody from the customer side? Do you coach them in how to get to grips with, you know, Jira, Azure DevOps or some other tool. Who do you think should do most of the work? Yeah. Oh, look. Very early. I I would start if I can start
from from an ideal project. Right? Very early on, you wanna you wanna coach your product owner and make him responsible that they are the owner of the product backlog. Like, this there is no there is no question about that. Right? They need to know that they own the product backlog and what is in there. What it means owning? They're making decision on prioritization, They make decision on namings and how we
want to structure this. The challenge we often have is A lot of them don't have a clue on how to do that. They know their business pretty well, right? They know the business, They're pretty, you know, high stake, but I hire in the in the management layer and everything, but they have never done of have never done product ownership, They don't know exactly what is a product backlog. How do we who how do I even name that thing? So we it's a bit of a guidance where most of the time Look. Ideal
scenario, the product owners have done that in the past. They know the product their product backlog. We can just guide them maybe on restructuring a bit, What makes sense to do before another epic because, otherwise, it does it breaks the system or something. That's ideal. But most of the time, they are they are new. And then in this case, we would often come up with a a structure of the product backlog based on the language and that High level
journey that we have discussed. So we have those workshops maybe with, you know, with the client and stakeholders. We map those high level, steps in the journey, which then leads to epics. And we do that together in consultation with the client, and we would most of the time, One of us or myself, I would create the epics because they don't know the tool. So it's almost like a guidance throughout the beginning, But throughout the 1st few weeks, 1st few months, that is slowly transitioning.
Right? Yeah. They start, taking over DevOps, and then we Tag them in in in user stories. We tag them in features. We tag the metrics. And then gradually, Ideal scenario is that you have a very senior BA or even the product owner going in, and then we'll Groom the product backlog. We change split the epics into epics or kind of group some features together or, You know, cancel them completely or rename them. Right? But that is kind of a bit of a journey that I've seen, but Yeah.
That is kind of an ideal scenario I would I would see. Yeah. I I've my my experience mirrors yours exactly, Danny. So I'm working with 1st time product owners, people who understand their business very well. They're in operations. They're in sales. They're marketing. They're some kind of leadership position. They know the business processes. They know existing systems. They know the business challenges they wanna try and solve
and the outcomes they're looking for. They don't know how to use Azure DevOps. They don't know an epic from a feature. And so we drive the tool at the beginning, with their blessing and their oversight. And then gradually, they get more hands on with it. I still quite often have one of the developers who's got a background as a business analyst, still doing most of the day
to day work in Azure DevOps. Yeah. The accountability for what's in scope, what's next, what's high priority, what's not is always with the customer's product owner. So my experience is very similar to yours. Yeah. Yeah. Yeah. Absolutely. Yeah. Glad to hear. Yeah. If, if you have a choice of which backlog management tool to use, Jira is very popular here in Australia. As you as you know, Atlassian is a
big Australian tech company. Microsoft Azure DevOps is very popular, of course, amongst the Microsoft community, And there are there are dozens or hundreds of others. Do you have a preference if given the choice? I have a strong preference for DevOps. Yeah. Good. And Good. It's a it's a preference. I've used it for many years. I just use very, I think
a few years ago, I used Jira on another project, but that's it. Like, I think it's a personal preference in term of just a project that was involved with is plan ahead DevOps already, or they let us make the choice and we went with DevOps? So very strong preference for DevOps. Yeah. Yeah. What about yourself? Yeah. I I mostly, I've been using Jira for the past few years, but when we get a
chance, we'll use Azure DevOps. And I don't know what it is about Jira, but it's quite often just badly configured or it's It's an enterprise tool that's being configured for lots of different teams. And then I can say, hey. Look. I wanna run a scrum team following these principles and these practices. Jira hasn't been configured for that kind of approach. And Yeah. So it's just there's there's just some weird things like You have to finish the sprint, and then you have to manually
start the next sprint. Like, one sprint should follow another naturally. I don't know. There's Yeah. Just some things I don't like about Jira. Yeah. Right. Okay. But it's very popular. Azure DevOps just seems to be a bit more natural. And, of course, it's where most of my developers do, You know, pipelines and source control, everything's been driven from there. I haven't seen I haven't seen many of my teams use
GitHub. And I know that that is you know, there's a lot of overlap these days between GitHub and Azure DevOps from a technical perspective. I'd say DevOps is still stronger from a boards and backlog perspective. I haven't seen I haven't seen anybody drive us towards using GitHub. Yep. Yep. That makes sense. You you talked a little bit about the hierarchy of Items that are in a backlog. Are you always using user stories, and is that the smallest, you know,
type of item in your backlog? How do you How do you structure the hierarchy of items? Yeah. It really, again, depends the size of the of the whole project. Right? If it's very simple, Maybe we have features and user stories. Right? And that's it. If it's a bit bigger, you go to the level of epics. If it's quite large, I would sometimes so I I had a project where I created something above epics because I had I
needed, like, 5 levels almost to structure. It's just from a structuring perspective, right, where, it could have been different projects too. Right? So it's kind of, you know, but basically yeah. Usually, epics feature user stories And then sometimes, and I have been introduced again to the concept of task by a product owner on on one of for one of my client, and
it start It starts to yeah. And it's it helps sometimes where you have a user story and it's more a few guys need to do something specific, then we can create task for us. And it's almost like reminders to kind of you know, I need to Investigate this for that specific feature or I need to do a bit of design for that. This is how I would use task. It's not linked to so we don't really track tasks in, you know, in boards as well
because I think you can track them as well in boards. Yes. I we used to do that in the past a years ago with another product owner, but that's not what I'm I'm talking about. It's more task where you can just manage your own workload within and everybody sees where you are. So it's used pretty loosely, to be fair. But, yeah, those are my 3 levels. Just on on the task thing,
Yeah. When teams are using tasks and they've got a Kanban board style, visualization for tracking their work, The user story or the the product backlog item would remain on the left hand side, and the tasks would move through the columns until they're all done. Whereas if you don't wanna use tasks, generally, the whole story or the whole product backlog item moves through the columns towards done.
Sounds like you're occasionally using tasks where that's helpful, but you're still you're not, you know, tracking the progress of individual tasks across the board. Working at a product backlog item level? Yeah. We we're really using user story as you mentioned, and we move user stories from one phase another. You know, analysis dev. We can talk about that a bit
later. The task you can even see them on the board. Right? In DevOps, you can see, Like a little number and and indication how many task are open underneath just as an indication. It doesn't force anything. It's just there and as an indication, it's used loosely. We haven't really structured it, so that helps on it's that 1 project where I I'm using task. Otherwise,
No. Okay. So for those of you not, not watching the YouTube version of this, discussion, I I kinda threw my head into my hands when Danny talks about tasks because there there are a couple of anti patterns I've seen, and and Danny doesn't sound like he's falling into these anti patterns. But I used to see teams With a product backlog item, and then they they would create tasks underneath or subtasks, sometimes they're called. And those subtasks would look like analysis, design,
development, testing, deployment. And so it's a series of waterfall steps for each product backlog item. And so we just had a 100 tasks all called analysis and a 100. Yeah. Just Very repetitive, not very helpful. But, if you don't use tasks like that and you do use them occasionally as really important stuff that needs to get done, needs to get tracked, And the other people might be interested
in, then I think that's a very fair, fair use of some tasks. So, I applaud you, Danny, in in, you know, figuring out what works for your team because that's what it's all about. Right? Yeah. Yeah. Absolutely. Yeah. I'll be keen to to understand as well how you, yeah, How you manage your analysis task in user story or your analysis activities and user story, but we can Yeah. We can, yeah, Talk about that in a sec. Well, let's let's go to the next because that's that's where
that's where user stories start. Right? We Yeah. I would typically have, similar to you, at the outset of the project, a series of epics, maybe 12, 15, or 20 epics, You know, from small and mid sized project, and that defines the scope of the project. Mhmm. And then we we start to refine those epics, which is the most important epic. Oh, it's Contact management. Contact management's always a good one because it's kind of the foundation for a lot of the
other features that are gonna come later. So we start with contacts. We'll refine that epic down into creating a contact, updating a contact, duplicate detection and emerging contacts, importing contacts, and so on. And so we're splitting. That's the 1st shot. Split the epic down Yep. Into something smaller, maybe a feature, maybe
a user story. And then we start to enrich that Product backlog item with a decent user story title or description, and then some acceptance criteria and and the estimates get, created and and off we go. Is that similar or completely different to your process? So most of the tasks that we could define, I guess, From a feature perspective and in breaking them down when we have our workshop or grooming session, and then we decompose them in those user
stories. But I've So I would follow the same in in most scenarios. Now where I'm finding some challenges, and maybe your your input might help me here, is Sometimes a task might require a decent amount of analysis sorry, the user story might require this amount of analysis. And we kind of it's because we we we thought about as a user story when we discussed that feature, and then we we now it's time to implement that feature, and then we that that user story, and we realize it's
actually a lot of analysis. I I need to talk to integration team. I need to talk to this, And then we need to figure out how we got so it's a lot of kind of analysis. And then, basically, that user story, which is big, then it's becoming this is where sometimes I don't know I don't have a process in my head what best to follow where I would then
say, okay. That is my analysis user story, and I will I will spend some time I will spend some time Or doing the sprint analyzing and kind of making a bit of a design and then decomposing that in maybe other user stories. Sure. This is typically what I would follow because then it's assigned to me. It is always assigned to one of my team member for the the print, and it fits within the sprint, and we can finish it within the sprint. But I'm
not sure if that's the best way. I feel there is better way to to do it. What What would you recommend? I think my my approach is probably fairly similar, and it's not the same approach. Like you said, it's not the same approach every time. Different customers Yeah. Want us to work slightly differently. Generally, there'll be a developer in the, in
the team. Who's got a business analysis background. That developer is working closely with a product owner and the subject matter experts, and they have a, an epic broken down into features or user stories, And they have a status that says either in analysis or not ready. Quite often, we just call it not ready. And that's where a Product backlog item is being enhanced with better descriptions or, maybe a wireframe of how the user interface might look or some sample data Or, you know, whatever it
is that that the an analyst needs to gather. Like you said, integration requirements. And and so once it's We'll see. Analyst feels it's ready. They'll bring it up in the next product backlog refinement meeting. We used to call it grooming, but the the scrum guide updated that language a couple years ago. So now we call it refinement. Sometimes we call it elaboration. And that's where the developers roll there with the analyst and the prop owner and saying, okay. This one's we think
it's ready. Okay. Well, let's take a look at it. So the developers will discuss it, ask some questions, try and Dive a little bit deeper to this. Once they feel it is ready, then they'll estimate it, and that's where we hope the estimate's pretty low. 1, 2, 3, 5 points. Anything bigger than that, and it's still a feature. It probably needs to get split again. So we try and, you know, figure out what what kind of size it is. And once everybody's happy, all
the developers are comfortable. They know enough about it to estimate it. Doesn't have to be 100% perfect. You might not have every answer to every question to that stage, but we know enough to estimate it. Yep. And it's ready to take into a sprint. So we update the status. And When we're doing sprint planning, we can look at all the product backlog items that are in that ready status, and we can consider bringing those into into the sprint
backlog. Something similar, I think. Yeah. Yeah. Something similar. I think is that true yeah. Yeah. Okay. And you don't estimate the analysis time. You don't estimate? No. Because this is what sometimes we do here I mean, I'm doing is okay. For the sprint, because maybe it's a big analysis task. Right? A lot of it's for the screen. We kind of put a u some user stories against
the analysis. Sorry. We put the story points against the analysis time, which helps us a bit estimating the capacity for Okay. That's that's where so this is where I have my user story with a lot of details in there, but I still need to do quite some analysis. Is not ready for dev, then we would kind of consider this as the analysis user story, put some story points so that we can kind of, You know, estimate the capacity, and then
from there, we would probably create additional user stories. I don't know if that's the best way to do it. But Yeah. I I I encourage my teams only to estimate the work that's gonna generate a product that the product owner has asked for. So, Yep. Typically, it's it's some working software. Right? I want I need this this button or this feature or this workflow, whatever it is. Or it could be, I need
this document. I need to use a guide or I need a, yeah, as is system description, you know, whatever the, the artifact is. So we estimate all of that work There then there's work that the dev team needs to do to get things done. Right? I need to stand up a new environment. I need to do some analysis on a user story. I need to, spend some time upskilling Danny. He's gonna I'm gonna train him in all the data migration, jobs that we've got running. Yeah.
That work, we don't estimate because it doesn't drive functionality for the end users. It's not something they care about. And so, yeah, if we have to do a lot of that work, the team will just say, Hey, look, we normally get, you know, 50 story points per sprint done, but we've got all these chores to do. Gonna reduce our capacity to 40 because we have more chores than usual. There's always
Yeah. There's always, work the team needs to do that the product might not necessarily consider valuable, and so we we call those chores, and everything else is a is a story. Yeah. Okay. Cool. Yeah. So it's, sounds pretty similar. Tell me about the type of acceptance criteria that you're writing On a product backlog, I'm gonna use your story. Yeah. So look, I wouldn't draw I mean, I would encourage BA to help me write or write the the acceptance criteria
most of the time. But then because I would prefer them to be written from kind of a business lens more, you know, so and and I strive to follow the best I can, some some exam I mean, a consistent way of writing those acceptance criteria that I've learned from
other good BAs before I've worked. Right? So I'm not Claiming it's mine, but, you know, kind of giving the scenarios, like, even that scenarios, if this happened then and it kind of And it's kind of a nice way if I have a few scenarios even as a as a dev or an architect when I go through this. It's kind of Making me empathize with the scenario I need to think about when I'm designing the system. It helps me even kind of writing
scenarios later. And even if I'm doing my own unit testing, it tells me go through this. Am I meeting the acceptance criteria? So this is what I would strongly recommend doing, And I would have to write them. Sometimes I'm I'm writing them because, well, for whatever reason, I'm the only one on the project or The b there isn't a really a a real BA on the project helping me, but, otherwise, I would strongly recommend the business or the BA to really write them that way.
Yep. Makes sense. Are you reading the same? Yeah. Same. So we call it behavior driven development, BDD, given, when, then, And we we use that that structure, and that's how we write the acceptance, acceptance criteria. Our testers can really easily turn those into test cases. What we find though, is, You know, as you begin to enrich your user story with those acceptance criteria, if you uncover quite a lot of them, that could really
Highlight that this story is way more complicated than we initially thought. Yeah. We might need to revise the estimate. Normally, we've done all the acceptance criteria before estimation. But if you see a a user's degree with 2 or 3 acceptance criteria, well, that's okay. If you see 1 with 7 or 8, 10 acceptance criteria, like, oh, wow. You know, I need to create a contact.
If the contact is this type or that type or the other type or if it's Tuesday or if it if it's every other Thursday or if the weather is wet, you know, all these Strange scenarios that come up whenever you wanna just create a contact. That shows you you might need to split your user story. So really really good way of, iterating to get to the, you know, this this is ready. Yep. Yep. Yep. Yep. Yep. Absolutely. Do you document anything? So that's
maybe another question I'll have for you. So where would you document some of your design ideas? Do you document them In the user story somewhere or in separate documents and you link it or somewhere else completely, where do you have that? We try and keep it Really lightweight. So quite often, it'll just be a comment
in Azure DevOps. So Yeah. When we're when we're estimating, the developers will say, well, we're estimating this on the basis that We think, we can solve this with a custom table, 2 flows and, a form. Right? And so it that's the that's the kind of design idea. Yep. That's good enough for estimating. Then once the sprint starts, we have normally 3 people, working in a team on a user story, at least 3 people. There's the analyst who's maybe done the refinement who knows
it best. That could be the product owner. It could be a subject matter expert or one of the developers who's a business analyst. Plus The developer who's gonna build most of the functionality, and it might be a couple because it might be a professional developer and a maker. Yep. So there might be a couple of developer developers. And then we have another developer, because in scrum, everybody's a developer. But this is a, a tester. Right? Somebody with a professional
qual quality assurance background, and they are gonna test it. So the we call it the 3 amigos, and they have a quick meeting, when they're ready to pick up this product backlog or sprint backlog item, and they say, right, have we confirmed we got everything? We still think it's ready. That design, it still looks appropriate. Yes. Have we learned anything new? No. It's all good. Let's let's get started. And then they come up with a little plan that says, alright. It's Tuesday. The sprint ends,
at 2 weeks from today. So I'm going to try and have it built. I'm gonna do a quick demo with a product owner on Friday, then it's gonna be ready for testing. When do you think that, how long are you gonna be take to test all that? I can get the test done on Monday evening. Okay. What's gonna be done By Tuesday, halfway through the sprint. Great. And so, yeah, the the 3 of them in those 3 amigos session, well, just a good a good sanity check everybody's ready to start work. Yeah. Off
we go. Yeah. Yeah. Yeah. Yeah. Yeah. Cool. Yep. Perfect. Thank you for that. Yeah. Are you are you doing it differently whenever Whenever you're ready to go and start work on it or or capturing your design ideas, how much design are you doing up front? No. It's it's very, actually, very similar, I think, to what to what you do, I think, in your team is just some high level concepts. Right? So, basically, I would if I have Access to making changes to DevOps or ask the client to make
changes to DevOps. I would recommend I myself try to have an additional box with design ideas in there Where instead of having and and then having them probably to the same level as as you at the beginning is, what Kind of automation or workflow do you wanna use? Flow, this, that. What kind of tables do we thinking? Just because when we discussing, we have some ideas. We We just want to capture them so that it's
not forgotten when we start working on this. Right? So we capture them then, and then as we go through The user story, if I would work on the user story, I would often have maybe a small diagram Next to it or a small presentation or as an empty diagram or whatever, then I would document. I will store them as attach not in the box. Don't know that that at the touchpoint in DevOps in a specific SharePoint location that we have linked to Azure DevOps, and then we link Document will link URL,
so we point to those URLs. So, basically, I would say, you know, design ideas would be this, this, that table, and then that portal to me and this and that, and then entity diagram, and then no hyperlink to Perfect. An entity diagram or or a conceptual diagram or something. Right? And this is stored then in a linked SharePoint folder to that users
to that user story effectively in that case. So this is basically how, you and then that folder in SharePoint, I'm actually working with another with another client where they have a bit more structure in those folders as well. So for example, if, documentation is stored there as well. So for you a user story feed, a documentation is required. We would store that documentation there with a specific subfolder of that folder of that DevOps
item. Yeah. Good. Okay. Yeah. Yeah. Do do you have to do much of a design document before the project gets started? Do you find, maybe a enterprise architecture team or solution architecture team requires you to do some kind of upfront design documentation that they have to approve Before you get started, I know Microsoft Fast Track, for example, is pretty keen for Microsoft partners to create the solution
blueprint document Yeah. Which is It's not even a it's not even a solution architecture, but it's, covers all the big topics, like how we're gonna do data migration, how we're gonna do integration, and addresses, Probably the top 12, 15 things you need to consider. Those are really good documents, I think, to create. Long as they're reasonably lightweight, And we're not bound by them, or we can negotiate them later. Do you find yourself doing a lot of that with bigger customers?
Yeah. Actually, I'm doing quite quite a lot of this kind of work, right, which is kind of kind of between discovery and, envisioning and and kind of one of the output that I that I use is is a solution blueprint, which has very similar, you know, subsections as what is in the Fast Track, right, which is effectively it's kind of the the question you need to ask. You you need you need a high level approach for each of those topics before you you start.
Right? The Yeah. It's essential question you wanna ask that you wanna have documented in a high level way kind of And kind of have your I use often like those conceptual diagrams, a bit of an high level architecture diagram, And then integration with maybe an integration diagram high level, what are the concept or the system, What what what are the direction of the integration or so that we at least have a had a discussion doing that, you know,
discovery or project envisioning, whatever you call it. We had a discussion about those topics, and we have an idea To also kind of provide a bit of an estimate when you're going to do the roadmap on the whole thing, but an idea of how we're going to approach So that there is no big surprises halfway through the project that we suddenly cannot integrate with the system, and that
integration is effectively deal breaker or whatever. Right? We don't wanna have we wanna limit the number of surprises. That's that's really the key of that, I think, that that solution blueprint that that project is that you wanna limit the risk and the surprises down the project. You will always have some, but you wanna limit them and at least
address the biggest one. Alright. That sounds very similar to what I'm doing. I I know I've had to take it a step further when I'm working with regulated organizations where there's a very mature enterprise architecture. And I try not to do it all upfront, but I give them the high level picture just to begin with. And as the project proceeds, we'll go deeper into a topic. Like, we're gonna do an integration with this Existing system. Here's our design pattern for for that
integration. We're gonna use Boomi or we're gonna use MuleSoft or use, Azure functions and and logic apps, get that kind of approval. And I think that they like to have some oversight of those patterns because, You know, they want us to reuse existing patterns where we can or, at least stick within the bonds of what they can support later. So Yeah. Yeah. A little bit of upfront design. Never heard anybody. I just try not to get everything, you know, set in concrete before
we start. Absolutely. Yeah. Because things change so fast and quickly that yeah. What are some of the challenges your your you or your customers have faced recently when it comes to managing a backlog? Anything that that's really You know, people are grinding their teeth about that, you can you can help us solve and avoid.
Look. I have seen so I think a structure like I said, a structure and and and Managing a product backlog itself requires a bit of, I think, of experience and and kind of you had you had to done it in in the past to kind of be familiar with it. Right?
And I and clients that haven't done it using a tool like DevOps or Jira Would manage your product backlog, you know, in Excel, I've seen those scenario whose where, you know, you you you jump into or you start a project And then the client opens, you know, a spreadsheet full of requirements and columns with statuses and Yeah. And the filters stop broking, and then, you know, the next day, they open the spreadsheet and it doesn't load because there's so many things. I have
seen those scenarios. Right? And I've I've been in those meetings where it's challenging even to go through the requirements and follow the statuses. Right? So I think the 2 here and and how you manage it also plays a big role. And when I see that, I I strongly recommend my client to take a look at that other tool that is made for that, right, and Kind of help them converting whatever they have somewhere else, whether it's spreadsheets or word document or Yep.
Into a tool like DevOps. So that's one of the challenge I have seen. When you are in DevOps, I guess, Like we discussed at the beginning, right, is that adoption of the tool that will take a bit of time. Yep. I think I think the advice would be is just you you you just need to allow your client time to To onboard and get familiar with it. Right? It just takes time, but it happens. Like, if you actively engage them, if you everyday open DevOps or if you Work in DevOps. You tag them in
DevOps, in comments. They kind of forced after some time to kind of capture their thoughts and the details there. And after a bit of time, everybody's using it. And then 2 months from now, suddenly the plan is using it and and really driving it as well. Yes. And that's kind of a a success. Right? So I think this this is also a challenge. Just give time for the organization to adopt it and And use it because maybe at the beginning, they won't like it or they don't wanna use it and
so step by step. And then after a few weeks, a few months, I've seen that they really start using it. Yeah. Those would be the 2 ones, to be fair. Yeah. Okay. One 1 1 final question for you, Danny. And then Yeah. If you've got a few minutes, I'd love to do a little bit of a retrospective with you. We can get to know you a bit better, what you've been up to recently. Where do you stand on deleting product backlog items? Like, I don't delete. Okay. Sorry. Go ahead.
So Ryan Ripley, he's a professional scrum trainer from Agile for Humans. He is big on deleting, pruning Yeah. Your product backlog item to be as small as Really realistically possible, and that includes hard deleting, you know, tearing up Yeah. Getting rid of items that are never gonna get delivered. He, I don't know, wanted he tells a story about he was at a conference, and he had to stay standing until he called out the you know, how old is your product? Oldest product backlog
item. Yeah. And the 1 guy remains standing the longest. Had a 9 year old product backlog item, you know, had been at the bottom of the product backlog for 9 years. And Ryan said, just delete it. It's never gonna get delivered. If it has hasn't been important to anybody in the last 9 years, it's never gonna get done. So Yeah. I don't
know. You don't like deleting? Well, if I make a mistake, yeah, if I make a mistake, I create, you know, I, of course, I will delete it, but otherwise Well, you have the removed state, so I usually don't if someone had an idea somewhere at some point, maybe it made sense. So I would I would change the status to removed
from the product backup, which is that soft delete. Yep. Inactive in Dynamics with the reason, We try to always try to add a reason in the comment removed because it has been merged with this one or Right. Whatever whatever the reason, it goes out of of the listing. It goes out. You can but you can always find it and find the reasoning why. Yeah. I don't know. I agree. Maybe I yeah. And maybe after, yeah, maybe after 5 years, if you look at your history and But why would you?
I mean, it's there. It's invisible. Yeah. It doesn't it doesn't bother me. I think it could be really nice if, you know, if you come up to me 3 years into the project or after we're going live and tell me, whatever happened to my idea, I had suggested this thing, or my boss suggested this thing, and we can go and trace it back and say, yes. Look. It was in here. It was discussed by the product owner. Yeah. She
she deprioritized it. She she conferred with your boss, and they agreed it wasn't, worth spending a lot of time and money on. And that saves us creating a new item to to go with do the same kind of evaluation all over again, If we can go and find that old old item. So I, I really like it. Yeah. And yeah, I wouldn't, I wouldn't encourage people to delete stuff if there's an convenient way of hiding things And keeping the mode of, out of harm's
way. Yeah. Cool. Yeah. Yeah. Yeah. I have 1 question for you, though, if possible. So I know and then you I think you commented on on someone's LinkedIn post somewhere, mine or maybe someone else, That and you you had a a way of writing user stories in a reverse Yeah. Format, not starting with as a actor. I do. You were writing it differently. Can you can you tell me remind me how you do it and why? Yeah. So the A very common user story template is, as a
actor, I can Yep. Do something so that I get some value. First of all, I don't think having the actor, enumerated in the user story is helpful. Quite often, we have lots of different types of users who can use a feature. Right? I don't wanna say Yeah. As a customer services user or as a sales user or as a marketing user or as an operations manager, I can so that. It's just
Hard to read. Yep. Instead, I just dropped that bit off. I dropped the actor and say, so that So I start with the value statement at the at the beginning so that we can enhance our customer experience. I can merge customer records together. And then what I do is I use the tagging feature in Azure DevOps to tag which roles can use this feature, right? Or you'll be targeting really with it. And so if I ever wanna say, should we all these features we built for sales analysts or finance,
analysts. I can quickly search your filter on the tag and all the user stories that we're building for the those people show up on the list. Yeah. And it's a much easier way of organizing, by by persona or stakeholder or user role, what we're building for. And the value statement at the start just reinforces the fact that we need to focus on creating valuable Functionality. And if you can't describe the value, then is it
really worth doing the work? Sometimes you just have to do the work. Yeah. Focus on the Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. If I may just ask then on this one. So This assume that you deliver that user story in kind of the same time frame more or less. Right? Or What would you do if the sales team needs that user story right now or did that feature right now and then the customer service needed in In 2 months' time, like, would you split the user story, or what would you No. I'd I'd try not to.
So, yeah, it's always a good a good analysis question to ask is, Who's gonna use this feature? And the product owner says, oh, the the sales team. Great. Okay. We're good. Yeah. As a sales user, I can. But a good question to ask is anybody else? Yeah. Are there other teams who could Yeah. Get value from this functionality if we delivered it? And oh, yeah. Well, the customer service team might occasionally need to do it, but not as often. Yep. So The real
priority is for the sales team. Okay. Well, I'll just tag customer service, as a persona on this user story. So I'll try and build it once. You might need to have a 2nd user story Mhmm. Because we forgot. We forgot the customer service needed this functionality as well. Mhmm. And the way that we built it 1st time was we only enable this, you know, through security rules. We only enabled it for the
sales users. And so we have a 2nd user story Just focused on customer service because we need to add the security privileges to their security role. So Yep. I try not to do it twice. Yeah. Yeah. Yeah. Cool. So it's a it's a more of case by case, again, scenario that yeah. Yeah. I would have 2 user stories only if I forgot to ask Upfront the first time. Who who else could benefit from this functionality? Yeah. Yeah.
Well, it's often the case, like, I'm having a situation now where kind of very similar requirements or feature being delivered, but so the product owner is liaising us with business with different business areas. Mhmm. And then 1 business area is very keen on having it. So we we have all the requirements for them, and we're ready, and then we deliver that now. Right. The other business area is a bit more busy or they there are requirements for
them and tell. Basically, they take a bit more time to providing us the details. So That feature for them with the details for them, maybe what kind of let's say connection roles. Add connection roles, that kind of roles they wanna have or something comes a few sprints later. In that case, I would have 2 user stories Because one, I wanna push the first one I wanna push Yes. Through the cycle and deliver, and then the other one which is very similar for another user
Group, I would push it later. Yeah. Oh, absolutely. You're all yes. You're always gonna have, Those enhancement user stories that enhance an earlier released feature. For whatever reason, great idea. You wanna get the Yep. You wanna get the value out there as quickly as you can and as earlier releases you can. And if somebody else wants to increment or iterate on that functionality later, some kind of enhancement, maybe maybe just roll it out to a different group of
users or a different business unit. Yeah. It's fine. Up yeah. Do that all the time. Cool. Have you got a couple of seconds you can stay on and and let me know How to how to reach you, how to find you, and what you're up to recently. So, I like to call this the retrospective, segment in the in the podcast. So for those who don't know Danny, Danny and I, you know, live reasonably close together. You're just down in the Gold Coast, which is, what, 50 k's from Brisbane, and we
catch up occasionally. You've missed, You missed a very fun presentation I did last night at the, Queensland business apps user group. I was in costume doing my how to How to solve the Elon Musk problem in in Dataverse. But, what what kind of events have you got coming up soon, Danny? Yeah. That was an that that was an interesting topic that you presented yesterday. Yeah. Look. I'm hoping to go at the, Nordings Nordic Summit while I'm traveling in Europe end of
September. Great. So Copenhagen this year? Yep. Yeah. Correct. Hoping to get that one. I have a bit of traveling and then for, yeah, for leisure Europe happening, so try to cause us you know, we don't travel to Europe that often for me. It's like a 24 hours plane ride. Right? So but, yes. So that's planned. Nothing really other from a Professional perspectives, where to find me on LinkedIn? You're always pretty active on LinkedIn. I love following your content there. Thank you. Yeah. You you're
pretty active too. Mhmm. Yeah. I I I'll just try and keep up with you and Hamish, really. You're always publishing these really colorful series of conceptual diagrams diving deep into industry accelerators or different applications. Have you got any more of those planned? What kind of content are you brewing for us at the moment. Yeah. So I'm in a series which takes a lot of time, but it's in a series of of kind of concepts where I explore kind of the major components of
the poor platform. So I started with the high level, You know, Microsoft Biz Apps. What is in Biz Apps? It's a bit of diagramming, right, which to be fair, what was was got a lot of attraction, like, comments, and so that was so that kind of encouraged me to continue, and then I went 1 level down to the poor platform, and then, again, decomposing this. Then I I'm doing now data so Dataverse, I had a diagram plus an
explanation to you to a YouTube video. Then I had poor apps, And I had Scott Duro jumping me on a call, depicting the whole thing. I just did Power BI with Greg Nash, is a poor VI MVP. He also went in kind of and it is it it is I like doing those diagram, but it's really helps me understand. Like, I've learned so much from I knew I think I knew poor apps, like, even model driven apps and stuff, but having a conversation with another
Expert, like, telling the stories and how to use specific things. It's just enriching you so much. Right? So it's it's a big it's how I learn, Basically. Right? So I have those planned for the other parts. I'm hoping to get Nick done when I think he already asked if he wanted to do with me the pages one. So he he he was keen to do that. I'll do 1 on automate for Vultr agents. So but it really takes a bit of time, so it's it's It's a few weeks, months sometimes work.
So this I I have. And then, occasionally, whatever I have, What I like doing right now is sometimes some small post on design ideas. You know, I stumbled lately on this new sub grids That you can you click on a sub grade and that opens up in a model view. Yeah. Like so one of my plan, I had a strong requirements around that, and it's really kind of, You know, they were very hap so I kind of posted. So when I have some ideas like that during my work, I try to quickly, you
know, Share it to the community. But other than that, nothing else, really. Apart from all these videos and blogs and YouTube posts and everything else you do, Not much. I love it. Well, you also have, of course, your functional consulting course. We talk a lot today about Managing requirements. Your course is super helpful. If anybody who wants to dive much deeper into the kind of topics Danny and I have discussed today, he has The best course on it. I've I've taken it. I've loved
it. It complements Hamish's work really well too, but you go deep into the stages of, Product backlog items and Azure DevOps and other topics, that we've discussed today, and I find it really useful. So encourage my teams to go through it. I encourage all of you listening watching today to go through that as well. I'll I'll include a link to that in the show notes as well as Danny's YouTube channel and your blog and everything else, Danny. Thanks so much for joining. Amazing.
Thank you, Neil. So, 7th time next time, or was that that's the 6th time now? This is the 6th. Yeah. I think the next time will be the 7th. We'll have to we'll have to find another topic, we'll have you back on as soon as we can. Amazing. Thank you. Thanks, Danny. Bye. See you. My biggest takeaway from my conversation with Danny was the Practical use of documentation in addition to whatever is written in your user story, a solution blueprint, a user interface, wireframe,
or example data in a spreadsheet. I'm generally a fan of minimalist user stories that encourage conversations between developers and users, But Danny shared with us some great reasons to enrich our user stories without going to the extreme of writing an old fashioned upfront requirement specification. What was your biggest takeaway from this episode? Visit the customer company page on LinkedIn or the amazing apps LinkedIn group, and let Donnie know. Until next time, Keep experimenting.