In my Dynamics 365 projects, I describe most requirements as user stories and I organise stories using epics and themes. I thought it might be helpful if I outline how I define these terms.
User stories originated in Extreme Programming, one of the earliest agile software development frameworks. They are very popular with Scrum teams too, and I use them in all my Dynamics 365 projects.
A user story describes what a user wants. Here are a couple of simple examples:
Show progress of the sales team members against their monthly targets.
Convert an email sent to the student support service into a case.
Capture the details of a member's marketing consent.
A very popular format for user stories is the <User> <Want> <Value> format. This helpful format reminds use which user role has requested the feature and what value it has for them. Here are our simple examples expanded into the user-want-value format:
As a territory manager, I can see the progress of my sales team against their monthly targets, so that I can coach the sales team appropriately.
As a student service offer, emails sent to the student support service are converted into a case, so that I can track who is working on it and we can meet our response levels.
As the VP marketing, I can demonstrate that we are capturing members' marketing consent, so that we are honouring their preferences and complying with our legal obligations.
User stories in this format can get a little wordy, so I usually summarise them with a short title: Sales Target Progress, Email to Case, and Marketing Consent.
User stories are not the only type of product backlog item my teams use. We also have spikes, chores and defects. I'll write more about those another time.
Some stories are massive. We call them epics. We write them to remind us about large sets of features that we're going to need later in the project. Just before we start to work on those features we'll split the epic up into small stories that are easy to implement.
There's no industry standard for when a user story becomes an epic. Often, any requirement too big to implement in a single sprint is considered an epic but your mileage may vary.
Here are a couple of examples from some of my projects:
Technician inventory replenishment
Service level agreements
Splitting Epics into Stories
In my misspent youth, I played a lot of Asteroids, an arcade game where the goal was to use your rocket shop to shoot all the asteroids into smaller asteroids until they blew up entirely.
Just like an Asteroids player, a Dynamics 365 team will get crushed if they blow up all the epic asteroids into tiny asteroids straight away. The best Asteroids players work on one or two epics at a time.
We can use themes to tie together collections of stories and epics that have something in common. My Dynamics 365 teams use all sorts of themes to categorise stories. We use tags in Visual Studio Team Service or JIRA to apply themes to our stories.
Examples of themes might be :
'Portals' for all the stories that might need Dynamics 365 portal pages.
'Security' for all the stories where we'll modify business units, security roles, access teams or field level security.
'Mobile' for all the stories where users need a mobile-first experience.
Stories often have multiple themes which is why tags are helpful.
I hope you've found my short explanation helpful. I'd love to hear about your user stories, epics and themes in the comments below. Please subscribe to my blog if you'd like to be notified about new articles on Scrum for Dynamics 365.