I cannot describe the *relief* I've felt watching your series. I've been killing myself working to implement DevOps processes based on the toolset's prescribed functionality rather than what our team/organisation actually needed. This is so hepful.
Thanks for an incisive explanation to Epic, Theme, User Story and Feature. In fact, Jira has made it confusion or very strictly defined which is not the case. Keep up this good work!!Kudos!!!
Thank you for the simple yet concise explanation. I would really enjoy seeing this information accompanied by infographics or possibly using one of the tools(Jira, Monday, Clickup etc.) that can visualize what was explained.
Thank you. I'll talk to my video editor and see what we can do on graphics. I tried to stay pretty tool agnostic because the ideas I'm discussing apply regardless of tool. But there are tool-specific topics that could be worth going into.
Sometimes people spend too much time debating whether something is an epic or story instead of defining the user need. I think tools such as Jira have contributed to this
You briefly mentioned that these terms shouldn't be used as containers. But I saw that lot of companies see these are hierarchical containers (usually each level has its own rules, owners and responsibilities). The current employer I work for uses them this was as well. "task < pbi < feature < epic < opportunity" and of course we have other backlogs for bugs, technical debts and whatnot. I can't keep tracking. //No they don't want to change this
Yes, many organizations use the terms as a hierarchy (as do tools) and it creates confusion. Then we spend needless time trying to figure out if an item is an epic, a feature, or some other term.
@@MountainGoatSoftware And this is not even the biggest problem because people practicing agility could solve this by common sense. The problem is the owner hierarchy and blocking processes. If you'd like to fix a bug, for example, and you are required to consult with multiple people who "own" the epic, the feature, etc. This is just one example, but there could be multiple blocking factors and processes to burn time and patience in the name of quality control and whatnot.
This is a new concept for me, because the software we use (IBM Rational Team Concert) has them all as a hierarchy. Groups of stories make up and epic. Groups of epics make a Theme.
A hierarchy such as that is very common. I think it can be useful up to 3 levels but some tools and teams go nuts with as many as 8 levels (I think that was the most I've seen).
for me an Epic is an area of functionality e.g. finding parking in a map app. a feature would be filtering by price and a user story would be one or more features that are to become functional requirements
Thanks a lot for your helpful video! I am even more struggling with the process of how scaling is done for multiple teams in my professional environment. In our process, being loosely based on SaFe, we are planning "program increments", i.e. planning horizons of roughly three months, for a bunch of teams. Features are registered by several stakeholders, which jointly get prioritized by the whole group of stakeholders. Teams estimate these features - in most cases by BREAKING THEM DOWN into what exactly has to be done, resulting in a bunch of tasks or user stories. Is this planning of a three month-timespan and breaking things down more of "following a plan" than "responding to change"? I am not quite sure about it. Besides that, ever ongoing discussions such as "this is not a feature! That should be an epic!" are energy-sapping and do not provide any value at all. Once again, thank you, Mike!
I think a really good aspect of SAFe (and what you describe) is the emphasis on goals further away from a sprint. When a team goes from short-term goal to short-term goal it can be sub-optimizing. A team should have a bigger goal out a bit further into the future, and I think 3 months is great. BUT I don't think a team should break anything down beyond the first sprint toward that goal. Doing more than that is unnecessary and very likely wasted work as things change over the 3 months. A good rule of thumb for looking ahead (in any way) is to do only do it if it results in different behavior today. So if we want to break things down (a bit) so we can decide if we need an additional team or the work is the approximately right amount of work, that's great. If not, don't do that extra upfront work.
I think it's better to use them as tags while building the backlog. Then it becomes easy to develop your "definition of done " as well as enable the PO to easily draw them in other of preference into the spring backlog
nice explanation, thanks for that and plenty for me to think about with my team. I noticed you mentioned the term initiative for something that spans a year or so - also what I would refer to as a program (something with a goal that is larger than a few teams and requires coordination across the organization). How do you think about programs and the coordination of work outside the boundary of a team(s) product backlog when work needs coordinating and scheduling to occur around a deadline (e.g. a regulatory due date) What are your thoughts in a product roadmap being outcome based so people make the topmost grouping of work as an outcome rather than in a story format - this way the result is described rather than the solution so that teams have more autonomy over the how. You can take this further with organization goals such as things like OKR and the relationship between stories / themes and OKRs. Would also be keen to get your take on that as well.
The language around agile has gotten very polluted with every tool vendor introducing their own terms for all the levels their tools support. So initiative, program, etc. doesn't really matter. As for roadmaps being outcome based: Yes, I think that's great. If you think about a hierarchy from something like program or initiative to feature to epic to story to task, they'll all end with very tactical "do this" and "do that activities." The deeper into their hierarchy the team can stay outcome focused, the better. So absolutely at the upper levels, including with OKRs. I've worked with quite a few orgs using OKRs and I'm torn on them. They seem like they should be very helpful but nearly all organizations don't get the benefits from them it seems like they should. They seem more promising than they deliver unfortunately.
Hi Mike, thank you for the explanation. What about Use Cases? I was asked this while reviewing the User Story Mapping and struggled to give an answer. If first block of User Story Mapping is the Activity or Epic, is the Use Case the block below (normally referred as called Tasks)? and then under this block, the last part is what we write User Stories? thanks!
I've never seen use cases placed on a story map. Use cases tend to be much larger than user stories, and there is already a Use Case Diagram approach for visualizing use cases. If you're using use cases and stories together, you can think of the use cases as an epic (big story). The individual paths through the use case or the steps within can map to stories.
I can't seem to create my own comment. My question is should o&m epics completed at the end of the release how do you recommend tagging a new fixed version and rolling over to the next release
Requirement can be a bit ambiguous. In some contexts it can be used to describe detail specifications or a user story that needs to be fulfilled. With Azure DevOps using it as an intermediary level, you might run into some confusion if you have team members who are used to a different definition of the term. As long as you're all on the same page about these definitions and consistently use them accordingly I don't see an issue.
Thanks, Brian. I may be missing a nuance to your question but I'd prefer flat over a hierarchy, whether that's the org structure or a backlog item structure. And I'm much more in favor of shared (collective) ownership rather than designated one person to own something. I understand why orgs like that ("a single, wringable neck" is a frequent, unfortunate, phrase). But when ownership is assigned to one person, it decreases any ownership felt by others.
@@MountainGoatSoftware - We use MS ADO. One of the reasons we have been pushing for a hierarchy has been for cross-project report out. As we are trying to report out the 'value delivered' at a Director/VP meeting, we found that most User Stories were too fine grained to be meaningful. but grouping the User Stories into larger grained Features or Epics had more meaning when reporting across Agile projects. Would you recommend using Tagging for this purpose? I still don't think I would be able to get to the larger grained meaningful unit of work. Thoughts?
Mike, can you help me with a question about user story roles? I'm a new Scrum master and I appreciate they should be written from the POV of an end user. How does this work for the infrastructure stories? The team either end up not using the template structure: As a ..I want or writing it from the POV of the Product Owner / Developer. Is there a definitive answer on this? Any thoughts will be gratefully appreciated. Thank you.
Hi Helen, I'll be happy to help. User stories should be written from the perspective of a user or customer. I'm not opposed to an _occasional_ story from a developer for product owner perspective. But those are a bit of a danger sign if used too frequently. For infrastructure stories, I suggest using _job stories._ I'll have a new video here on February 21 about them. But the basic idea is to replace "As a type-of-user" with "When___" The when contains a trigger or situation. A simple example for a refrigerator would be, "When the fridge door is left open more than n seconds, I want the fridge to alert me so that I can close the door." No user in sight on that story! The use is less important so it's replaced by the event initiating the story. You can read more here and I'll have the new video up in a few weeks. www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories
@@MountainGoatSoftwareThat is extremely helpful Mike - thank you so much. I've already shared your advice with the team. Looking forward to the video and keep up the outstanding work. 😊😊
It seems like its a task to just break a project down so it can fit into the Agile terms. This in a way is a project in its self. keeping it simple is best unless the a granular approach is required.
Sure! In general, a feature is a user story that is big enough to release or big enough that users will notice and be happier. An epic is a really big user story. I won't be able to complete an epic in one sprint or iteration, but I might be able to complete a feature.
Do epics really need to close? ie.. for software enhancements tied to an epic w/ a user story already done. Ie an Epic tied with a User Story that has been delivered but with current ongoing software enhancements. Shld I tie the ongoing software enhancements to the Epic or Shld it be separate?
I guess you could keep an epic open forever, but I don't see any usefulness to that. I'm thinking of Microsoft Word. They'll work on the spell checker forever. But there will be flurries of activity and inactivity (I assume). It would make sense to create an epic for a set of big changes to the spell checker. But I wouldn't leave it around just because we'll work on the spell checker again in a year or two. In personal to-do list software there is sometimes the distinction between projects and "areas of responsibility." Projects finish. Areas of responsibility are open forever. For example, I have a project in my to do system to travel to visit my dad next month. I'll do that and it will be done. I'll, of course, visit him again, probably in a couple of months. But I'll add that as a new projects complete with tasks like book flights, rental car, etc. In my to-do system I have an area of responsibility of "Finances" and it has all the tasks like pay my mortgage, my water bill, etc. That area of responsibility will be around as long as I am :) I think of epics more like the projects in this sense--they come and go.
@@MountainGoatSoftware thank you! I’m actually referring to a product rather than a project which has regular software enhancements from time to time (each sprint cycle). From the historical data, there’s not been any pause with the enhancements until to-date since the product went live. How shld you advise in this scenario? I have created 5 epics with a few stories tied to each epic, each sprint cycle the team has some enhancements to do since the product deployed is on MVP and we currently on day 2. When shld I close the epic since there’s always something to update each sprint cycle? Or Shld I close the epic w/ the stories then create another epic for software enhancements that’s open forever?
I'll start with this: I'd say the enhancing the performance of the endpoint is a _product backlog item_ and it would likely have tasks like code it, test it, make test data, and maybe a few more. I've found the syntax of "Feature-Driven Development" good for APIs. It is [action] the [result] [by|for|of|to] a(n) [object]. So examples could be: Estimate the closing price of stock, Generate a unique identifier for a transaction, Change the text displayed on a kiosk, Merge the data for duplicate transactions. I'd put one of those "tech stories" on the product backlog and have tasks (code, test,...) within it.
In my experience of "imposed agile", work items (WI) of different sizes are used as offered by the software in play (Jira / Azure DevOps / ...), resembling the org hierarchy and positions which manage and are accountable for those items. Some org levels might deal with multiple WI levels. In my case, it's a century-old tech company struggling with its politicised and tech- and market-disconnected management; IIRC, we have 5 levels of WIs (PBI/Feature/Epic/Global Epic/Opportunity). It works for creating an agile facade, but is not a great thing for our customers IMHO.
There's probably some relationship between the number of layers of management in a company and the number of layers in the backlog hierarchy. 😞 In my opinion, in both cases, the fewer layers the better.
so, a theme can be a feature? I dont understand the difference between a user story and a BIG user story. who decides that a user story qualifies as big? I'm interpreting it as: you can have multiple, related, user stories (theme?) and combine them into one user story to make it "big" (epic?). Also, you said features are epics that are big enough to be released. Does that mean that in order for a PBI to be released it needs to be big? Does the size matter for it to be released?
Great questions, Oscar. Questions like "who decides that a user story qualifies as big" are why I'm not a huge fan of how tools implement these terms. Many tools create hierarchies and you are forced to choose between things like Story, Epic, Feature (or more) when creating the item. I think the question is analogous to who gets to decide if a movie is a comedy. If the movie has at least one joke a minute, is it comedy? What if it goes 30 minutes without a joke then has a really good joke? The distinction is meaningless. Who cares if it's a comedy? I just want to watch a good movie. The way I think about it is you have stories. Some stories are big enough that we want to split them into smaller stories. Think about adding a spell checker to Microsoft Word (way back when). That's a single story but it's big so I'd call it an epic. As an epic (big story) it's too big to finish in one iteration (or sprint) so we want to split it up to make it more convenient to work with. Maybe we pull out sub-stories like adding words to a custom dictionary, sharing dictionaries, installing them, etc. So imagine we started with the big epic ("As a user, I can spell check a document"). We split it into let's say 8 sub-stories. And now we're told, "Don't work on the spell checker, improving the table designer is more important." We then put a rubber band around the 8 substories and call that a theme. (A group of related items.) It gets confusing because Jira decided to use the terms differently--they call the group of stories an _epic_ instead of a _theme._ I don't use the term _feature_ at all. But others do and usually use it to mean a story of any size that can be released.
@@MountainGoatSoftware thank you for taking the time to explain more. I think you answered some of my questions in your video during the second half, but I was still processing the terminology from the first half during your explanations. It helps to also hear the same explanation worded differently. Thanks again.
Feature is described around 4:00 in the video. I'm not familiar with "capability" other than in the generic sense of the word. If your tool is calling things, capabilities you'll need to use whatever definition the tool uses. This is why I don't like this overly complicated hierarchies.
Sure! The easiest way to think about the relationship between them is that the bigger the story the higher up the backlog it should go. So big epics should be higher up than smaller features. The lower down the backlog you get, and the closer to development that you get, the smaller the stories should be. If you need a good visual there's a great one here: www.mountaingoatsoftware.com/blog/stories-epics-and-themes
My question is should o&m epics completed at the end of the release how do you recommend tagging a new fixed version and rolling over to the next release
@@MountainGoatSoftwareShould O&M epics be closed at the end of the release and a new one created for the next release or should an O&M epic remain open and rollover to a new release.
@@Outdoor_Don Epics, and user stories, should include some value piece. Whether that's value to the end user, a stakeholder, or some kind of technical value. They need to deliver value. If the O&M epics meet that requirement and they don't need altering from one release to the next, I don't see a problem with copying them over to the next release. I can't speak on how to do that within your tool though.
I was about writing a summary for myself and suddenly I heard "Jira, I'm looking at you!" :D made my day at 10 a.m.
😂
I really needed this explanation... trying to understand all these definitions was driving me crazy! Thanks a lot, Mike!!
I'm glad this clicked for you!
THIS IS EXACTLY WHAT I NEEDED TO SEE AT THE RIGHT TIME... AMAZINGLY WELL DONE EXPLANATION
Thanks for the tutorial, I must say the video quality is like the best I've ever seen, it's like you are right here in the room with me! Amazing!!
Thank you. I really appreciate that.
I cannot describe the *relief* I've felt watching your series. I've been killing myself working to implement DevOps processes based on the toolset's prescribed functionality rather than what our team/organisation actually needed. This is so hepful.
I'm glad it was helpful, Johnny. Everyone wants to make things so complicated.
Very helpful. Love this: "They're just labels." Thanks, Mike.
Thanks, Mark!
Clarity and precision as always, thanks Mike!
Thank you, Phillippe!
Excellent video, with nice production values. Helped me a lot - appreciated 😊
Thank you. I really appreciate that and will share your comment with my video editor as well. He'll be delighted. Thanks!
Thanks for an incisive explanation to Epic, Theme, User Story and Feature. In fact, Jira has made it confusion or very strictly defined which is not the case. Keep up this good work!!Kudos!!!
Thank you.
The way you explain stuff is epic. love it
🙂
Thank you very much. That's kind of you to say.
Excellent video, very concise and explanatory. Thanks, Mike!
Thanks!
Thank you for the simple yet concise explanation.
I would really enjoy seeing this information accompanied by infographics or possibly using one of the tools(Jira, Monday, Clickup etc.) that can visualize what was explained.
Thank you. I'll talk to my video editor and see what we can do on graphics. I tried to stay pretty tool agnostic because the ideas I'm discussing apply regardless of tool. But there are tool-specific topics that could be worth going into.
Sometimes people spend too much time debating whether something is an epic or story instead of defining the user need. I think tools such as Jira have contributed to this
I totally agree.
You briefly mentioned that these terms shouldn't be used as containers. But I saw that lot of companies see these are hierarchical containers (usually each level has its own rules, owners and responsibilities).
The current employer I work for uses them this was as well. "task < pbi < feature < epic < opportunity" and of course we have other backlogs for bugs, technical debts and whatnot. I can't keep tracking.
//No they don't want to change this
Yes, many organizations use the terms as a hierarchy (as do tools) and it creates confusion. Then we spend needless time trying to figure out if an item is an epic, a feature, or some other term.
@@MountainGoatSoftware And this is not even the biggest problem because people practicing agility could solve this by common sense. The problem is the owner hierarchy and blocking processes. If you'd like to fix a bug, for example, and you are required to consult with multiple people who "own" the epic, the feature, etc.
This is just one example, but there could be multiple blocking factors and processes to burn time and patience in the name of quality control and whatnot.
Please do an agile tool tier list!
I'll see what I can do.
This is a new concept for me, because the software we use (IBM Rational Team Concert) has them all as a hierarchy. Groups of stories make up and epic. Groups of epics make a Theme.
A hierarchy such as that is very common. I think it can be useful up to 3 levels but some tools and teams go nuts with as many as 8 levels (I think that was the most I've seen).
@@MountainGoatSoftware 8 levels, that IS nuts!
nice information...helpful
Thank you.
Beautiful explanation Mike .
Ahh, thank you!
THanks a lot... I think your explanations are great !
You're welcome
Thanks a lot mate! Really useful information!
You're welcome!
for me an Epic is an area of functionality e.g. finding parking in a map app. a feature would be filtering by price and a user story would be one or more features that are to become functional requirements
Great set of definitions.
Quite simple explanation. Thanks 😊
Thank you!
Thanks a lot for your helpful video!
I am even more struggling with the process of how scaling is done for multiple teams in my professional environment.
In our process, being loosely based on SaFe, we are planning "program increments", i.e. planning horizons of roughly three months, for a bunch of teams.
Features are registered by several stakeholders, which jointly get prioritized by the whole group of stakeholders. Teams estimate these features - in most cases by BREAKING THEM DOWN into what exactly has to be done, resulting in a bunch of tasks or user stories.
Is this planning of a three month-timespan and breaking things down more of "following a plan" than "responding to change"? I am not quite sure about it. Besides that, ever ongoing discussions such as "this is not a feature! That should be an epic!" are energy-sapping and do not provide any value at all.
Once again, thank you, Mike!
I think a really good aspect of SAFe (and what you describe) is the emphasis on goals further away from a sprint. When a team goes from short-term goal to short-term goal it can be sub-optimizing. A team should have a bigger goal out a bit further into the future, and I think 3 months is great.
BUT I don't think a team should break anything down beyond the first sprint toward that goal. Doing more than that is unnecessary and very likely wasted work as things change over the 3 months.
A good rule of thumb for looking ahead (in any way) is to do only do it if it results in different behavior today. So if we want to break things down (a bit) so we can decide if we need an additional team or the work is the approximately right amount of work, that's great. If not, don't do that extra upfront work.
5:40 20 jokes plus a kiss is a successful first date.
Good acceptance criteria!
I think it's better to use them as tags while building the backlog.
Then it becomes easy to develop your "definition of done " as well as enable the PO to easily draw them in other of preference into the spring backlog
That's a great way to keep the backlog organized even early on
nice explanation, thanks for that and plenty for me to think about with my team.
I noticed you mentioned the term initiative for something that spans a year or so - also what I would refer to as a program (something with a goal that is larger than a few teams and requires coordination across the organization). How do you think about programs and the coordination of work outside the boundary of a team(s) product backlog when work needs coordinating and scheduling to occur around a deadline (e.g. a regulatory due date)
What are your thoughts in a product roadmap being outcome based so people make the topmost grouping of work as an outcome rather than in a story format - this way the result is described rather than the solution so that teams have more autonomy over the how. You can take this further with organization goals such as things like OKR and the relationship between stories / themes and OKRs. Would also be keen to get your take on that as well.
The language around agile has gotten very polluted with every tool vendor introducing their own terms for all the levels their tools support. So initiative, program, etc. doesn't really matter.
As for roadmaps being outcome based: Yes, I think that's great. If you think about a hierarchy from something like program or initiative to feature to epic to story to task, they'll all end with very tactical "do this" and "do that activities." The deeper into their hierarchy the team can stay outcome focused, the better. So absolutely at the upper levels, including with OKRs.
I've worked with quite a few orgs using OKRs and I'm torn on them. They seem like they should be very helpful but nearly all organizations don't get the benefits from them it seems like they should. They seem more promising than they deliver unfortunately.
Hi Mike, thank you for the explanation. What about Use Cases? I was asked this while reviewing the User Story Mapping and struggled to give an answer. If first block of User Story Mapping is the Activity or Epic, is the Use Case the block below (normally referred as called Tasks)? and then under this block, the last part is what we write User Stories? thanks!
I've never seen use cases placed on a story map. Use cases tend to be much larger than user stories, and there is already a Use Case Diagram approach for visualizing use cases.
If you're using use cases and stories together, you can think of the use cases as an epic (big story). The individual paths through the use case or the steps within can map to stories.
I can't seem to create my own comment. My question is should o&m epics completed at the end of the release how do you recommend tagging a new fixed version and rolling over to the next release
In Azure DevOps, the hierarchy is Epic-> Requirement -> Feature-> Task. Can you comment on the semantics or use of Requirement?
Requirement can be a bit ambiguous. In some contexts it can be used to describe detail specifications or a user story that needs to be fulfilled. With Azure DevOps using it as an intermediary level, you might run into some confusion if you have team members who are used to a different definition of the term. As long as you're all on the same page about these definitions and consistently use them accordingly I don't see an issue.
@@MountainGoatSoftware thanks!
Great explanations!! We use a SAFe-like framework. What are your thoughts on hierarchy and levels of ownership in scaled scrum environments?
SAFe is not agile so why bother what it calls anything?
Thanks, Brian. I may be missing a nuance to your question but I'd prefer flat over a hierarchy, whether that's the org structure or a backlog item structure. And I'm much more in favor of shared (collective) ownership rather than designated one person to own something. I understand why orgs like that ("a single, wringable neck" is a frequent, unfortunate, phrase). But when ownership is assigned to one person, it decreases any ownership felt by others.
@@MountainGoatSoftware - We use MS ADO. One of the reasons we have been pushing for a hierarchy has been for cross-project report out. As we are trying to report out the 'value delivered' at a Director/VP meeting, we found that most User Stories were too fine grained to be meaningful. but grouping the User Stories into larger grained Features or Epics had more meaning when reporting across Agile projects. Would you recommend using Tagging for this purpose? I still don't think I would be able to get to the larger grained meaningful unit of work. Thoughts?
Mike, can you help me with a question about user story roles? I'm a new Scrum master and I appreciate they should be written from the POV of an end user. How does this work for the infrastructure stories? The team either end up not using the template structure: As a ..I want or writing it from the POV of the Product Owner / Developer. Is there a definitive answer on this? Any thoughts will be gratefully appreciated. Thank you.
Hi Helen, I'll be happy to help. User stories should be written from the perspective of a user or customer. I'm not opposed to an _occasional_ story from a developer for product owner perspective. But those are a bit of a danger sign if used too frequently.
For infrastructure stories, I suggest using _job stories._ I'll have a new video here on February 21 about them. But the basic idea is to replace "As a type-of-user" with "When___" The when contains a trigger or situation. A simple example for a refrigerator would be, "When the fridge door is left open more than n seconds, I want the fridge to alert me so that I can close the door."
No user in sight on that story! The use is less important so it's replaced by the event initiating the story. You can read more here and I'll have the new video up in a few weeks. www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories
@@MountainGoatSoftwareThat is extremely helpful Mike - thank you so much. I've already shared your advice with the team. Looking forward to the video and keep up the outstanding work. 😊😊
@@HelenG-s3d You're welcome
It seems like its a task to just break a project down so it can fit into the Agile terms. This in a way is a project in its self. keeping it simple is best unless the a granular approach is required.
Agreed. I don't like it when I see teams that are trying to work with this cumbersome hierarchies.
This was helpful.
Do you have any videos about writing user stories Gherkin format?
Thanks, Johanna. I don't have any stories specifically about Gherkin.
Can you please help in understanding difference between epic and feature
Sure! In general, a feature is a user story that is big enough to release or big enough that users will notice and be happier. An epic is a really big user story. I won't be able to complete an epic in one sprint or iteration, but I might be able to complete a feature.
Do epics really need to close? ie.. for software enhancements tied to an epic w/ a user story already done. Ie an Epic tied with a User Story that has been delivered but with current ongoing software enhancements. Shld I tie the ongoing software enhancements to the Epic or Shld it be separate?
I guess you could keep an epic open forever, but I don't see any usefulness to that. I'm thinking of Microsoft Word. They'll work on the spell checker forever. But there will be flurries of activity and inactivity (I assume). It would make sense to create an epic for a set of big changes to the spell checker. But I wouldn't leave it around just because we'll work on the spell checker again in a year or two.
In personal to-do list software there is sometimes the distinction between projects and "areas of responsibility." Projects finish. Areas of responsibility are open forever. For example, I have a project in my to do system to travel to visit my dad next month. I'll do that and it will be done. I'll, of course, visit him again, probably in a couple of months. But I'll add that as a new projects complete with tasks like book flights, rental car, etc.
In my to-do system I have an area of responsibility of "Finances" and it has all the tasks like pay my mortgage, my water bill, etc. That area of responsibility will be around as long as I am :)
I think of epics more like the projects in this sense--they come and go.
@@MountainGoatSoftware thank you! I’m actually referring to a product rather than a project which has regular software enhancements from time to time (each sprint cycle). From the historical data, there’s not been any pause with the enhancements until to-date since the product went live. How shld you advise in this scenario? I have created 5 epics with a few stories tied to each epic, each sprint cycle the team has some enhancements to do since the product deployed is on MVP and we currently on day 2. When shld I close the epic since there’s always something to update each sprint cycle? Or Shld I close the epic w/ the stories then create another epic for software enhancements that’s open forever?
@@wennemenzo I don't think anything about my previous answer changes. I see no advantage to having some permanently open item on a product backlog.
Great content!
Thank you!
I created an api endpoint and I want to enhance the performance of it. Is the api endpoint a user story and the enhancement is a task?
I'll start with this: I'd say the enhancing the performance of the endpoint is a _product backlog item_ and it would likely have tasks like code it, test it, make test data, and maybe a few more. I've found the syntax of "Feature-Driven Development" good for APIs. It is [action] the [result] [by|for|of|to] a(n) [object].
So examples could be: Estimate the closing price of stock, Generate a unique identifier for a transaction, Change the text displayed on a kiosk, Merge the data for duplicate transactions.
I'd put one of those "tech stories" on the product backlog and have tasks (code, test,...) within it.
In my experience of "imposed agile", work items (WI) of different sizes are used as offered by the software in play (Jira / Azure DevOps / ...), resembling the org hierarchy and positions which manage and are accountable for those items. Some org levels might deal with multiple WI levels. In my case, it's a century-old tech company struggling with its politicised and tech- and market-disconnected management; IIRC, we have 5 levels of WIs (PBI/Feature/Epic/Global Epic/Opportunity). It works for creating an agile facade, but is not a great thing for our customers IMHO.
There's probably some relationship between the number of layers of management in a company and the number of layers in the backlog hierarchy. 😞 In my opinion, in both cases, the fewer layers the better.
so, a theme can be a feature? I dont understand the difference between a user story and a BIG user story. who decides that a user story qualifies as big? I'm interpreting it as: you can have multiple, related, user stories (theme?) and combine them into one user story to make it "big" (epic?). Also, you said features are epics that are big enough to be released. Does that mean that in order for a PBI to be released it needs to be big? Does the size matter for it to be released?
Great questions, Oscar. Questions like "who decides that a user story qualifies as big" are why I'm not a huge fan of how tools implement these terms. Many tools create hierarchies and you are forced to choose between things like Story, Epic, Feature (or more) when creating the item.
I think the question is analogous to who gets to decide if a movie is a comedy. If the movie has at least one joke a minute, is it comedy? What if it goes 30 minutes without a joke then has a really good joke?
The distinction is meaningless. Who cares if it's a comedy? I just want to watch a good movie.
The way I think about it is you have stories. Some stories are big enough that we want to split them into smaller stories. Think about adding a spell checker to Microsoft Word (way back when). That's a single story but it's big so I'd call it an epic. As an epic (big story) it's too big to finish in one iteration (or sprint) so we want to split it up to make it more convenient to work with. Maybe we pull out sub-stories like adding words to a custom dictionary, sharing dictionaries, installing them, etc.
So imagine we started with the big epic ("As a user, I can spell check a document"). We split it into let's say 8 sub-stories. And now we're told, "Don't work on the spell checker, improving the table designer is more important."
We then put a rubber band around the 8 substories and call that a theme. (A group of related items.)
It gets confusing because Jira decided to use the terms differently--they call the group of stories an _epic_ instead of a _theme._
I don't use the term _feature_ at all. But others do and usually use it to mean a story of any size that can be released.
@@MountainGoatSoftware thank you for taking the time to explain more. I think you answered some of my questions in your video during the second half, but I was still processing the terminology from the first half during your explanations. It helps to also hear the same explanation worded differently. Thanks again.
@@oscaroscuro I'm glad I could help
Sir can you explain feature and capabilities
Feature is described around 4:00 in the video. I'm not familiar with "capability" other than in the generic sense of the word. If your tool is calling things, capabilities you'll need to use whatever definition the tool uses. This is why I don't like this overly complicated hierarchies.
Can you share the original relationship among them. I mean which comes on top
Sure! The easiest way to think about the relationship between them is that the bigger the story the higher up the backlog it should go. So big epics should be higher up than smaller features. The lower down the backlog you get, and the closer to development that you get, the smaller the stories should be. If you need a good visual there's a great one here: www.mountaingoatsoftware.com/blog/stories-epics-and-themes
Can i create a story or task without an epic?
In my view, absolutely. But it may depend on the tool you're using.
I don’t understand the hierarchy of the ticket types. Is it somewhat like themes, initiatives, features, epics, user stories?
I don't recommend having such a complicated hierarchy.
My question is should o&m epics completed at the end of the release how do you recommend tagging a new fixed version and rolling over to the next release
Sorry, but I don't understand the question. It sounds like a tool question.
@@MountainGoatSoftwareShould O&M epics be closed at the end of the release and a new one created for the next release or should an O&M epic remain open and rollover to a new release.
@@Outdoor_Don Epics, and user stories, should include some value piece. Whether that's value to the end user, a stakeholder, or some kind of technical value. They need to deliver value. If the O&M epics meet that requirement and they don't need altering from one release to the next, I don't see a problem with copying them over to the next release. I can't speak on how to do that within your tool though.
Sound like people need to calm down with all the jargon and get to completing projects!
That is a great way of putting it!
superb and precise explanation.
Thank you!