Should We Have a Standard Set of User Stories?

Is it worth having a standard set of user stories for Dynamics 365 projects?

Welcome to the Amazing Apps show for Microsoft business applications creators who want to build amazing business applications that everyone will love.

Hi, everyone, I'm your host, Neil Benson, and my goal on this podcast is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power Platform applications. The question in this episode comes from David Mochrie. David is a Power Platform consultant at Magnetism [00:01:00] in Auckland. Over to you, David.

"Since there are so many standard things in Dynamics 365 they have to do in every project, like security, Outlook integration, SharePoint integration. Of course, you may do some or some of those and not others. Is it worth having a standard set of user stories that you have at the beginning and you can then discount which ones you don't want and then only have to add the customisation stuff that you put in?"

Thanks for that question, David. Is it worth having a standard set of user stories for Dynamics 365 projects? I guess if you'd build an application on Power Apps that was implemented for several customers, for example, like an industry or a line of business application, then the same question could apply.

I'll tell you a story about a similar situation I find myself in many years ago, I was a business analyst writing requirement specifications over and over for lots of similar Dynamics CRM [00:02:00] projects, mostly sales force automation projects. And I set out on a mission to do something very similar to what you're asking, David. I wasn't writing user stories which are, you know, small fragments that capture the essence of what my users need. Oh, no, I went a whole lot further than that.

I built replica screens of hundreds of Dynamics CRM forms and views in a wireframe prototyping tool called Axure RP Pro. In Axure, I could paste a screenshot of a Dynamics 365 screen at the bottom of the on the bottom layer and then build a wireframe replica on top of that. So it looked exactly the same as a screenshot and then delete the screenshot from underneath. It was like it's like recreating a picture from your favourite comic by laying tracing paper over the top and copying it by hand until what you'd drawn on the page looked exactly like the comic book. I [00:03:00] was left with a bunch of graphical components like input boxes and fields and labels and buttons and column headers. Each of those components could be moved, changed, annotated or relabelled. I could add new components to represent custom fields, columns or buttons, and I could even the press of a button In Axure generate a simple web application by rendering wireframes in HTML.

Or I could generate a specification document in Microsoft Word including a screenshot at the top of the page and all my annotations at the bottom. After what's got to be hundreds and hundreds of hours of work, I was nearing my goal of recreating almost every screen from Dynamics CRM as a wireframe in Axure when Microsoft released CRM 4.0 and almost every screen changed. So to keep up, I tried updating every one of my wireframes to look like the new user interface of CRM [00:04:00] 4.0. But after hundreds of hours of more work, I realised I'd never get it all done again before Microsoft probably, you know, they would have released CRM 2011.

So what's all that got to do with a standard set of user stories?

Well, you could write a standard set of user stories for all the standard features in any Microsoft business application, at least any first-party application, you know, Dynamics 365 Marketing or Sales. You could take the user guides that are available in Microsoft Docs and reverse engineer all those feature descriptions as user stories. But how much effort would that take and how many times would you get to use that template of user stories before Microsoft makes some significant changes and you have to start all over again?

I'm a big fan of automating mundane parts of my business and my life. I know that some developers will say that if they have to perform the same task twice, that's once too many and they should have automated it the first time.  [00:05:00]And with that mindset, you might consider investing a whole lot of work upfront, trying to write a catalogue of standard user stories for Dynamics 365 Marketing or Sales or Business Central or Finance or Operations or HR -- whatever you want -- or your own line of business application.

But I'm also a big fan of only doing the important valuable work that I know is needed to achieve a goal that's right in front of me. Importantly, work that somebody else is going to pay for that they find valuable. And so these days, I would never try and build a wireframe replica of every screen in Dynamics 365 and I would never try and write a catalogue of standard user stories.

There's just too high a risk that I'd never use those stories enough before they change and I need to rewrite them again.

So, David, I hope that's a reasonable answer for your question. It may not be the answer you wanted. I certainly don't have a set of standard user stories that I can give to you, if that's [00:06:00] what you were asking for. But if you have, you know, that catalogue, I'm sure if you published it and we'd all find it useful to be a great community resource.

You'll find notes and a transcript of this episode at customery.com/012. And while you're on the Customery website, at Customery.com, you can submit your own question to the amazing applications show by clicking on the 'Send Voicemail' button on the right-hand side. Remember to include your name, where you work and where you live. And your question could feature on a future episode of the show.

Until next time: Keep sprinting.