Utilizing Scrum for non-Software Development
The area that I now work for does not develop software. We work with data and reporting. There are a few things they have done that would have resembled traditional software development. Perhaps I am splitting hairs here. We program, we develop, there is an end goal in sight. It's just most of our stuff is on the smaller scale. It seems people are often getting hung in with names. For example, they currently use User Stories like Tasks. Anything that needs done is a User Story. Epics are basically unheard of. The use of Tasks and Bugs all depends on what the individual develop wants to use. It keeps coming up in my mind to change the name of the levels to something that would make more since to our developers and managers. Not really changing the Scrum process, just a few labels. Now, I do not yet have an answer to what those new labels might be. But I thought I would check out here with the Hive Mind to see what others might have done before. A rose by any other name is still a rose, I know...lol
Concepts like "user story", "epic", "task", and "bug" can't be found in the Scrum Guide. In Scrum, any work needed to improve the product is a Product Backlog Item. Sometimes, teams may find it helpful to differentiate between different types. Using "epics" to describe large pieces of work that need to be decomposed or distinguish between "stories" and "bugs" to differentiate between desired features and fixing problems. However, the Scrum framework doesn't make this distinction. I would defer to the team to help define which terms best help them understand, order, and do the work.
What the team needs to come up with, every Sprint, is a Sprint Goal and a forecast of work. The items on a Product Backlog can be structured however the team likes, as long as they facilitate this conversation and enable the Product Owner to account for value.
As @Thomas stated, there is nothing in the Scrum Guide (https://scrumguides.org/scrum-guide.html) that dictates how items that make up the Product Backlog have to be created or named. In most of the teams I have worked with the desired format is to describe the problem that needs to be solved in any way that best conveys the message. I don't know if I have ever worked with a team that actually used the "As a <>, I want <> so that I can <>" format. Create the item in any way that can completely and clearly convey the need and accurately portray the work that will be done.
As for whether your team is a software development team or not, it doesn't matter. The Scrum framework is intended to be used by groups that have complex problems that need to be solved and can be done so incrementally so that feedback and adaption can occur frequently. I worked at an organization where the Scrum framework was used by the Events team. They created and managed trade shows for large number of vendors, attendees. They found it very useful. I also have an acquaintance that coaches Human Centered Agile to companies. She has used Scrum for many of her implementations in human resources/people administration divisions.
Scrum Guide dose not any terms you have mentioned neither it dictates them. But Scrum events like Sprint, Sprint planning, Sprint Review, Sprint Retrospective etc and artifacts like Sprint Backlog or Product Backlog and Product/Sprint goals. It dose not recommends terms like User Stories, tasks etc. You can research (https://scrumguides.org/scrum-guide.html) for details.
It seems people are often getting hung in with names. For example, they currently use User Stories like Tasks. Anything that needs done is a User Story. Epics are basically unheard of.
Hi Lance, in your situation the best option is to make them understand what Epics, Stories, Tasks mean and probably get them onto the same page so that there is some standardization (may be document it if needed). You may have to go one step ahead and review if they are being used as agreed as people might go back to their old ways of working.
As others have commented Scrum just says product backlog, sprint backlog and the team should decide on what they would like to use.