November 6, 2023 • 49 mins
#152. Host Neil Benson is joined by the talented Dani Kahil for an insightful discussion on managing backlogs and enhancing user stories in Azure DevOps and Jira. Neil shares his experiences with Jira, highlighting some configuration challenges, while Dani expresses a strong preference for Azure DevOps.
They dive into the hierarchy of backlog items, including epics, features, user stories, and tasks, and explore different approaches to tracking progress on a Kanban board. Throughout their conversation, Neil and Dani discuss the importance of refining user stories, enriching them with acceptance criteria, and prioritising features based on their value to the team or users. They also touch on the significance of releasing value quickly and iterating on functionality. Join us for an engaging conversation packed with practical insights and tips for efficient backlog management. Let's get started!
Dani Kahil on LinkedIn: https://www.linkedin.com/in/danikahil/
Dani's blog: https://danikahil.com
Kahil Consulting: https://kahilconsulting.com/
CONNECT
🌏 Amazing Apps website
MY ONLINE COURSES
🚀 Agile Foundations for Microsoft Business Apps
🏉 Scrum for Microsoft Business Apps
Keep experimenting 🧪
-Neil
Mentioned in this episode:
Subscribe to my new Estimating Business Apps podcast mini-series
Estimating Business Apps is a five-part podcast that will help you quickly, accurately and confidently estimate complex Power Platform and Dynamics 365 apps in minutes. Listen now: https://estimating-business-apps.captivate.fm/listen
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:08):
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
(00:31):
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
(00:54):
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
(01:17):
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.
(01:39):
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
(02:01):
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.
(02:23):
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
(02:46):
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
(03:08):
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
(03:29):
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
(03:51):
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
(04:13):
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,
(04:35):
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.
(04:58):
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
(05:20):
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,
(05:42):
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
(06:05):
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
(06:27):
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
(06:50):
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
(07:12):
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,
(07:34):
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,
(07:56):
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
(08:18):
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
(08:40):
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
(09:01):
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
(09:23):
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.
(09:46):
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
(10:09):
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
(10:31):
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
(10:53):
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
(11:15):
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,
(11:37):
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
(11:59):
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
(12:21):
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,
(12:45):
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.
(13:07):
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
(13:29):
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
(13:52):
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
(14:14):
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,
(14:36):
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
(14:58):
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,
(15:21):
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
(15:44):
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
(16:06):
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
(16:30):
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
(16:52):
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
(17:15):
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
(17:37):
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
(17:58):
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
(18:21):
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
(18:42):
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
(19:04):
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
(19:27):
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,
(19:50):
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
(20:10):
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
(20:33):
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.
(20:56):
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
(21:16):
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,
(21:38):
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
(22:00):
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
(22:23):
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.
(22:47):
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
(23:08):
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
(23:29):
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
(23:51):
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
(24:15):
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
(24:36):
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
(24:58):
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
(25:20):
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.
(25:42):
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
(26:03):
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
(26:25):
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
(26:47):
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
(27:09):
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
(27:31):
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
(27:55):
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
(28:17):
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,
(28:40):
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,
(29:03):
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.
(29:25):
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,
(29:47):
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
(30:11):
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
(30:33):
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
(30:55):
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
(31:17):
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
(31:40):
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
(32:03):
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
(32:27):
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
(32:50):
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
(33:12):
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
(33:34):
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.
(33:57):
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.
(34:18):
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.
(34:38):
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
(35:01):
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
(35:22):
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
(35:44):
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
(36:07):
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.
(36:28):
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
(36:50):
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
(37:12):
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.
(37:35):
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
(37:57):
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
(38:20):
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
(38:42):
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.
(39:05):
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
(39:28):
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
(39:49):
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.
(40:11):
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
(40:33):
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
(40:56):
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
(41:18):
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
(41:41):
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,
(42:02):
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
(42:23):
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.
(42:44):
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?
(43:06):
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
(43:29):
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
(43:51):
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
(44:13):
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
(44:35):
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
(44:58):
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
(45:20):
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
(45:42):
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
(46:04):
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
(46:26):
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
(46:48):
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.
(47:11):
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
(47:34):
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.
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
(00:31):
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
(00:54):
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
(01:17):
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.
(01:39):
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
(02:01):
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.
(02:23):
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
(02:46):
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
(03:08):
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
(03:29):
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
(03:51):
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
(04:13):
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,
(04:35):
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.
(04:58):
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
(05:20):
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,
(05:42):
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
(06:05):
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
(06:27):
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
(06:50):
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
(07:12):
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,
(07:34):
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,
(07:56):
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
(08:18):
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
(08:40):
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
(09:01):
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
(09:23):
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.
(09:46):
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
(10:09):
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
(10:31):
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
(10:53):
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
(11:15):
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,
(11:37):
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
(11:59):
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
(12:21):
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,
(12:45):
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.
(13:07):
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
(13:29):
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
(13:52):
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
(14:14):
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,
(14:36):
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
(14:58):
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,
(15:21):
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
(15:44):
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
(16:06):
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
(16:30):
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
(16:52):
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
(17:15):
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
(17:37):
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
(17:58):
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
(18:21):
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
(18:42):
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
(19:04):
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
(19:27):
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,
(19:50):
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
(20:10):
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
(20:33):
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.
(20:56):
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
(21:16):
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,
(21:38):
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
(22:00):
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
(22:23):
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.
(22:47):
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
(23:08):
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
(23:29):
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
(23:51):
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
(24:15):
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
(24:36):
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
(24:58):
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
(25:20):
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.
(25:42):
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
(26:03):
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
(26:25):
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
(26:47):
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
(27:09):
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
(27:31):
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
(27:55):
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
(28:17):
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,
(28:40):
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,
(29:03):
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.
(29:25):
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,
(29:47):
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
(30:11):
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
(30:33):
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
(30:55):
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
(31:17):
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
(31:40):
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
(32:03):
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
(32:27):
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
(32:50):
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
(33:12):
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
(33:34):
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.
(33:57):
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.
(34:18):
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.
(34:38):
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
(35:01):
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
(35:22):
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
(35:44):
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
(36:07):
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.
(36:28):
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
(36:50):
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
(37:12):
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.
(37:35):
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
(37:57):
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
(38:20):
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
(38:42):
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.
(39:05):
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
(39:28):
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
(39:49):
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.
(40:11):
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
(40:33):
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
(40:56):
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
(41:18):
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
(41:41):
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,
(42:02):
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
(42:23):
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.
(42:44):
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?
(43:06):
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
(43:29):
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
(43:51):
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
(44:13):
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
(44:35):
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
(44:58):
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
(45:20):
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
(45:42):
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
(46:04):
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
(46:26):
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
(46:48):
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.
(47:11):
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
(47:34):
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.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com