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.