3 User Story Traps to Avoid with Power Platform and Dynamics 365

Welcome to the Amazing Applications podcast -- for Microsoft Business Applications makers who want to build amazing applications that everyone will love.

Hi, I'm your host Neil Benson. My goal on this show 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.

If you’re a regular listener, welcome back to the show. It’s great to have you subscribe to the podcast. I appreciate your feedback and the engagement we get on the Amazing Applications page on LinkedIn.

If this is your first time listening to the Amazing Applications show, then a very special welcome. As the intro suggests, the show exists to help you build amazing, agile Microsoft Business Applications. Sometimes we have guests from the Dynamics 365 and Power Platform community on the show to reveal the critical success factors that help them build amazing applications. 

Recently we’ve had Haniel Croitoru from Protiviti, Bert Wijns from Power Accelerate and CJ Brooks from MISSION CRM sharing their stories with us.

Today it’s a solo episode, where’ll I’ll do my best to answer one of our listener’s questions.

Thanks to Richard for his insightful questions about working with user stories in a Dynamics 365 or Power Platform agile project.

Richard is a business analyst and he’s admitted to me that his career in business analysis has mostly been working in waterfall projects, and like me, Richard’s got some classic business analysis certifications in requirements engineering and business process modelling.

Let’s spend this episode talking about user stories on Dynamics 365 and Power Platform projects. I’ll share three traps to avoid when working with user stories.

You’ll find the show notes including a transcript and resources for this episode at customery.com/028.

What are user stories? A user story captures the essence of a requirement from the point of view of the user.

A system-shall statement might say, “The system shall display key metrics of regional sales in a dashboard.”

The same requirement captured as a user story might say, “As a sales manager, I can review all the key metrics for my region so that I can coach my team to pursue the best opportunities”.

Notice the key differences:

The system-shall statement does not tell you who the story is for. The user story does. It’s for a sales manager.

The system-shall statement gives you a design constraint. The metrics will be displayed in a dashboard. The user story captures the requirement, not the solution.

The system-shall statement doesn’t tell you why the requirement is valuable. The user story captures the value the sales manager will get from knowing the regional sales metrics. She’ll be able to coach her team more effectively.

If you’ve never worked with user stories before, there’s a lot more to learn and I’ll include some resources in the show notes. If you’ve been listening to Amazing Applications and using an agile approach for a while, I’m going to assume you’re familiar with user stories and have a good grasp of the basics.

Richard asked a couple of questions about user stories in some situations on his recent projects. There are some traps that it’s easy to fall into when we’re working with user stories, and Richard’s trying to avoid them. Here they are:

The first trap is the level of detail. 

The second trap is splitting and combining stories.

The third trap is managing changes to the backlog of users stories.

Let’s go through those, starting with the level of detail.

I love keeping user stories as brief as possible. There’s a temptation for a business analyst to support the product owner by interviewing or observing users or running workshops and capturing lots of notes and jamming them into the user story as acceptance criteria or test scenarios.

This is a trap.

It’s a trap for a couple of reasons.

Sometimes we capture a lot of detail about user stories without understanding the relative priority of this user story in the product backlog. We spend hours or days of effort writing a detailed user story only to discover that the product owner doesn’t think this story will be a candidate for the next release. It could be months before we start developing it. The story is going to go stale. The requirement could change. It could become obsolete months from now, and that effort would be wasted.

But I know Richard’s on board with just-in-time requirements analysis. His scrum team has already discussed the priority of this user story and the product owner wants to start work on it in a sprint or two.

Even then, writing a detailed user story with lots of criteria and scenarios could still be a trap.

We try to write a user story so descriptive that it’s got all the details our developers need and that they never have to bother our users or confer with the product owner. It’s all right there in the story.

That’s a waterfall mindset. Believing that our stakeholders’ complex wants and needs can be specified in writing or with a few diagrams in such a way that it’s faithful, unambiguous, and complete knowledge transfer. 

I often see this with remote teams, especially those separated by time zones. There’s barely any overlap in the working day of the developers and the users, so we try and write everything down for the developers because face-to-face dialogue is too hard to schedule. The cost of documentation. The cost of miscommunication. The cost of getting lost in translation. This is the invisible cost of offshore development.

Instead, our user stories should be a reminder to have a conversation. User stories are not a requirement specification. They are a reminder that the developers need to discuss what the users want and need with the users. 

During that discussion, there’ll be questions. Coming back to our sales manager’s requirement for team metrics, there’ll be questions such as:

What do you mean by key metrics? Can you give us some examples? How are those metrics calculated? Is all the data to calculate the metrics in the application or do you combine it with data in other systems?

There’ll be design options the developers might want to evaluate:

Would it be good enough if we recreated the key metrics you’ve got today? Could we do it in Excel? Would a dashboard be preferable? Do you already use Power BI? Do you want to change the filters and adjust the slicers yourself?

There’ll be some design constraints too:

How often do you need to refresh the metrics? How often do you change the coaching plan for your team? Does anyone else need access to the metrics? 

Through this dialogue, we arrive at a mutual understanding. Most of our developers now understand what’s driving the requirement, the user’s context, and they probably have a candidate solution design in mind. The users have been able to express the nuances of their requirements, and the product owner understands the design options the developers are considering.

At this point, it’s a great idea to make some notes so that the key details are captured. This could be a wireframe of a dashboard or the current Excel charts attached to the story. It doesn’t have to be a detailed set of acceptance criteria or test scenarios. Although, these can be really useful so that the scrum team and stakeholders all agree when this story will be done.

If developers don’t have the opportunity to have the dialogue with the users, then they’ll have to rely on the documentation. 

Natural languages, like written English, are terrible at capturing all the detail, nuance and meaning of our requirements. 

Here’s a recent example from a requirements specification provided to Microsoft partners as part of a request for proposal for Power Platform development services:

“Business users, including third-party suppliers, are guided by tailored case workflows to assess an application and make a recommendation, assisted by variations for common scenarios (e.g. agency referrals, site inspections), intelligence informing risk management, and flexibility for handling exceptions.”

Respondents to the RFP are expected to understand this requirement so that they can specify whether it can be met with a standard feature, or it will require configuration or custom development, which Microsoft or third-party module or components would be used, the respondent’s approach to meeting the requirement, and any assumptions.

What’s a tailored case workflow? When you say ‘workflow’ are you referring to classic Dynamics 365 workflows, cloud flows or business process flows in Power Automate or some kind of generic workflow? When you say ‘for example agency referrals and site inspections’ what other scenarios are there? Can you describe all of them? What does ‘intelligence informing risk management’ mean? And when you need ‘flexibility for handling exceptions’ how would you test whether a feature was flexible enough?

Do you see what I mean? Written requirements generate a lot of questions. And that was just one requirement. This RFP had hundreds just like that one. But don’t get me started on the uselessness of public sector procurement and the pointlessness of requests for proposals like this one.

My point is that it’s amazing when the developers can ask the users directly. And it’s a game of whispers when they can’t.

In response to the futility of requirements written in natural language, the requirements engineering community has tried to teach business analysts to use structured techniques to capture and communicate requirements. 

These methods include system-shall statements, use cases and use case diagrams, business process models using BPMN, state transition diagrams, data flow diagrams, role-activity diagrams and lots of other modelling notations.

The trouble with all of these modelling notations is that our users aren’t trained business analysts, neither are the vast majority of developers. Linda in sales wants a dashboard showing her team’s metrics. But she’s not about to learn how to read a data flow diagram so that she can evaluate whether you’ve modelled her requirements accurately. 

Heck, I’ve worked with lots of brilliant developers who couldn’t make heads or tails of a data flow diagram either. I’m pretty sure UML isn’t as exciting or widely taught to developers today as it was 20 years ago.

These models make sense for the people who know to write and read the notations. They’re great for analysts and architects who need to document how your Dynamics 365 or Power Platform application works, but I don’t think wordy specifications or obscure models are suitable for conveying the detail, nuance and meaning of requirements.

In my experience, an open dialogue between the users and the developers is still the best way of reaching a mutual understanding and results in the highest possible chance that the developers will build something the users will love.

Richard, here’s my advice for the appropriate level of detail to include in your user stories:

A short title and a description. If it helps, you can use the classic user story template for the description: As a <user role>, I can <use a feature>, so that <I get some value>. But don’t feel constrained to use a template like that for user stories. In fact, don’t feel constrained to use user stories for all requirements in your backlog.

Add some acceptance criteria if it’ll help your scrum team (your product owner and your developers) verify when the user story is done.

Include a visual where it’ll help communicate a possible user interface design. That could be a whiteboard sketch or a wireframe.

And that’s it. 

Give the developers a chance to clarify the details with the product owner and users prior to development so they can estimate the story and again during development so they can build the best possible feature for the users.

***

Richard’s next question (and a possible trap) was about splitting and combining user stories.

Specifically, Richard’s question was how to handle the situation where different stakeholders or user persona have very similar requirements.

Should we combine them into a single user story and call out any minor differences in the details? For example, should we have a couple of acceptance criteria unique to each persona?

Or should we split them into separate user stories, one for each persona, so that they can each have their own acceptance criteria and the progress of each user story can be tracked separately for each persona?

I think this decision needs to be made by the team’s product owner, and then handled by a scrum team developer, like Richard, who specialises in business analysis.

As the business analyst gets to know the product owner and her goal for the product, he can make recommendations but the final decision rests with the product owner.

Here’s why.

It’s the product owner’s job to prioritise the different needs of her stakeholders. 

If there are multiple variations of a requirement needed for multiple personas by different stakeholders, she knows it makes sense to develop them all at once. While the requirement is forefront in our minds, while the solution is open, while the Visual Studio project is on screen, let’s meet all the requirements in one go. 

That’s the most efficient way to do it. That’s the way I’d recommend doing it.

But not always the best way to do it or the most appropriate way of doing it.

Perhaps one of the stakeholders is dragging their feet in providing the necessary details of how the requirement needs to work for the persona in her department. Our product owner might want to fulfil the requirement for all the other persona but split out the requirement for the persona in the foot-dragging stakeholder’s department.

Or the requirement is mission-critical for one stakeholder to meet his regulatory obligations and important, but not critical, for the other stakeholders. Our product owner might want to split out the requirement for the stakeholder with the mission-critical regulatory obligations and get it done in the next sprint while leaving a similar requirement for the other stakeholders further down the product backlog to be prioritised later.

Balancing these kinds of trade-offs and prioritisation decisions are what product owners are made of. It’s not always easy to make the right call. You can’t please all of the people all of the time. But great a product owner enjoys this responsibility and does a great job of listening to her stakeholders, making a decision, and explaining that decision to her stakeholders and the rest of the scrum team.

As developers in the scrum team, our job is to help the product owner by suggesting user stories that can easily be combined or highlighting technical risks of splitting stories; risks that the product owner might not see coming.

I hope that helps you with your dilemma about when to split and combine user stories, Richard. In short, combine them where possible because this is the most efficient way of doing it from a time and cost point of view, but there will be times when splitting stories is the best approach.

Here’s a bonus tip about handling user stories for multiple personas. When you’re managing user stories in a backlog management tool like Azure DevOps or JIRA, use tags to indicate the person who will benefit from this feature. In our sales dashboard example, tag the user story “Linda” or “Sales Manager”. If the feature was requested by multiple personas, add a tag for each one. Now you can easily filter for all the user stories by a given persona, and tagging makes splitting or combining the user stories easier too.

***

Richard’s last question is about handling changes to the product backlog from the perspective of cost.

The third trap of working with user stories is to treat changes in the product backlog, such as adding or removing user stories, like we would treat a change request in a traditional project.

Like many of us, Richard works for a Microsoft partner and so there’s a statement of work between Richard’s team and the Microsoft customer that specifies the work to be done and how it’s going to be paid for.

Traditional statements of work point at a requirements specification, and usually say ‘you’ll pay us this agreed fee when all those requirements are verified’. Sometimes they are fixed-price because they are fixed-scope, sometimes they are time-and-materials. 

In either case, there’s usually a change control procedure to adjust the fees if the agreed scope is changed. Managing this change control procedure is a key responsibility of a project manager. In fact, negotiating a change control request is probably the most fun a project manager ever has.

The statement of work looks quite different when we’re using an agile approach like Scrum.

An agile statement of work doesn’t point at a requirements specification. Because there isn’t one. We might have an initial, high-level product backlog of epic user stories or a user story map that we refer to in the statement of work, but it’s indicative and not binding. 

The reason that the scope is not binding in an agile statement of work is that the product owner controls the scope. Every week or two, at the sprint planning event, the product owner presents her highest priority items and the developers forecast which items they’ll get done in this sprint. This backlog can change from sprint to sprint as the scrum team learns more about their stakeholders’ needs and the stakeholders provide feedback on completed increments. Even during the sprint, the sprint backlog can change as the team learns more about the features it's building.

There is no formal change control process to follow. It’s usually a simple negotiation and agreement between the product owner and the developers, often facilitated by the scrum master.

Commercially, the agile statement of work doesn’t say ‘you’ll pay us this agreed fee when all those requirements are verified’ because we don’t know all the requirements upfront. Instead, it’ll say something like, ‘you’ll pay us approximately this amount for each sprint and we’ll do our best work on your prioritised requirements until you tell us we’re done’.

Agile statements of work are usually time and materials. You could charge a fixed fee for each sprint, but developers go on holiday or they change projects, and so it makes sense to base the fees on their effort on the project. Customers who need some certainty, can cap the fees or cap the duration, but the scope remains in their control.

Some customers think that a traditional statement of work with a fixed-price, fixed-scope arrangement pushes a reasonable amount of risk back onto the developers; onto the Microsoft partner. In my experience, fixed-price/fixed-scope engagements push an unreasonable amount of risk onto the requirements specification being perfect and not changing. And Microsoft partners have to inflate their fees to cover the risk, and so fixed-price engagements usually cost more and don’t deliver what the customer needs, and no one finds out until the testing phase when it’s too late.

Of course, those assumptions about requirements specifications are never true. They are never perfect, and they always change. Fixed-price/fixed-scope means your project manager is destined for the change control dance. If the Microsoft partner didn’t risk-adjust the fees in their original fixed-price statement of work, the customer can expect to pay handsomely for every change request afterwards.

My advice, Richard, would be to work with your team, specifically the engagement team who agrees to the statements of work with your customers. Examine whether you’re trying to adopt an agile approach within a traditional statement of work, and if so, how you can realign your statements of work to support and nurture an agile approach that’ll benefit you and your customers.

You’ll need to support your customers by educating them on the important role that the product owner plays in controlling the scope of the project.

***

How to avoid the three traps of working with user stories when building Power Platform and Dynamics 365 apps using Scrum:

Trap 1: Level of detail. Keep the written user story as brief as possible and ensure that your developers, users and product owner have opportunities to discuss the requirement and reach a mutual understanding.

Trap 2: Combining and splitting user stories. Combine similar user stories together as far as possible to minimise the development effort, but your product owner can decide there’s a good reason to split a user story if she wants.

Trap 3: User stories can be added and removed from the product backlog at any time. It’s the product owner’s job to prioritise user stories, and if this backlog management work impacts the statement of work between a Microsoft customer and partner then examine whether you’re trying to fit an agile project into a waterfall statement of work.

I hope that helps, Richard. Thanks for your question.

Unless you’re as shy as Richard, you’re welcome to leave your question about building amazing agile business applications on my voicemail service. Visit customery.com and click on the ‘Send Voicemail’ feature and I’ll try and answer your question in an upcoming episode.

Don’t forget you’ll find show notes for this episode at customery.com/028 including a transcript and some user story resources.

If you’d like to find out more about managing a product backlog in an agile Dynamics 365 or Power Platform project, I have 10 videos covering product backlog management proven practices such as user stories, epics, user story mapping, estimating, non-functional requirement and more. They’re in my Scrum for Microsoft Business Apps online course at customery.com/scrum. The course will teach you everything you need to know about the Scrum framework so you can achieve your Professional Scrum Master certification, which I think is the perfect initial certification for everyone in a scrum team, and you’ll learn all my proven practices for applying scrum to Dynamics 365 and Power Platform projects.

Until next time,

Keep sprinting.