I am just trying to get a better understanding of how granular components can be used.
We already use Epics to group the larger feature-sets of the product together, and use releases to manage which version these epics will reside in. We'd like to break down some of the larger items into their individual components, to help us manage the worktype a little easier, but wondered if anyone had a particular process or ruling they use to identify what constitutes a component?
I'd like to be able to set a general rule for components, such as "a component is an area of the product which can have its own permission set" or something similar. Has anyone else come up with this sort of system before?
Hi Jordan - Welcome to the Community!
We use the components in a varied of ways, depending on the team. The most common use is to use Epics for "Project" work - a grouping of issues that satisfy a particular project (work being accomplished over a specific period of time with a clear start and ending).
Then we use Components to represent on-going work for a team - for example, iOS work, browser work, funnel work, etc. This allows the team to filter and/or group that type of work. And still connect it to an Epic for like work being done over a specific time.
Hope that helps a little.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.