Creating sagas in Productboard for broader features/ideas than epics

  • 1 July 2022
  • 3 replies
  • 151 views
pjsmits
Rank
Userlevel 3
Badge +2
  • pjsmits Product Makers Group Leader
  • Product Makers Group Leader
  • 14 replies

As a maker in Productboard I used to struggle with the differences in how far concretized a ‘feature’ is. We use ‘features’ for specific product functionalities but also for vaguer ideas or topics to collect insights on. Most features translate to Epics that are further refined by the developer into issues/user stories. We use the term ‘Saga’ for bigger topics that usually will be translated into multiple epics later on (after proper discovery), as saga’s usually refer to broader concepts than epics.
To indicate sagas in productboard I started using the §-symbol in the title (at the beginning). It is easy to add on most windows keyboards and on mac using option-6 (depending on your language settings). As you normally need to enter three characters to search for a feature, it can be circumvented by entering ‘ § ‘ (space-§-space). 

 

Always curious how others solve this, or whether this might be useful for others. Let me know in the comments 🙂.

This topic is closed for comments.

3 replies

scott.baldwin
Rank
Userlevel 7
Badge +13

That’s interesting @pjsmits

I’ve seldom seen sagas used by agile teams, but when they are I usually suggest they make them a component then follow the usual Productboard Feature = Epic and Subfeature = Story. Given Sagas typically don’t need to be pushed to JIRA, this still allows for teams to have visibility on the saga in Productboard and do the execution work in JIRA. 
 

Do you have a hierarchy in JIRA that contains sagas? How often do you find yourself using sagas?

 

And for those not familiar with sagas, a bit about these epics of epics from the folks at Scrum Expert:
Sagas are “big picture” requirements that are extremely broad in their scope. An example of a saga might be: “As a: end-user I want to: use an application that has exceptional performance and responds to my requests within a matter of seconds So I can: quickly complete my work and stay focused on my immediate task.” This type of requirement is very broad in its scope and sets an expectation for all functions in the application. As such, every feature and unit of functionality must take it into consideration. This means that multiple epics and stories will be based on this type of saga. Sagas typically have a long life and while they must be adhered to they are not fully completed until all lower level epics and stories rooted in them are finished.

Head of Community & Product Evangelism
pjsmits
Rank
Userlevel 3
Badge +2

Do you have a hierarchy in JIRA that contains sagas? How often do you find yourself using sagas?

 

We don’t use JIRA at the moment (unfortunately), but we use ZenHub in which you can create a hierarchy of epics (top-level epics we use as saga’s and sub-level epics we use as regular epics). You could indeed also use components for sagas, however, I found it useful to be able to assign properties like drivers, competitor values, releases, etc. to sagas as well, and in some cases, the sagas appear not to be that big after all and they can easily be turned into an epic by removing the § sign 😉.

Especially when starting on a new feature set or building something entirely new, I tend to work a lot with sagas which will later crystallize into one or more often multiple epics.
 

plainclothes
Userlevel 5
Badge +2

IME, Pb’s structure perfectly fits the product hierarchy most orgs need:

  1. Product: Maleable depending on the size/complexity of the org.
  2. Component (optional): An area of the product that encapsulates capabilities or workflows.
  3. Feature: An Epic in “agile” terms, which I find usually equates to a “job story” in the jobs-as-progress model.
  4. Sub-feature:  A Story in agile terms, which I think of in terms of a neatly testable unit of the feature.

In your problem statement, I think you’re worrying about where an idea fits in that hierarchy too early.

We use ‘features’ for specific product functionalities but also for vaguer ideas or topics to collect insights on.

 

It’s okay to have features on your board that are somewhat (or very much) undefined. I capture these as placeholder features with a status of “idea” until it warrants further definition effort.

As you understand an idea better you’ll figure out exactly what it is and where it fits. For all you know, it may become a whole new product! I actually just went down that road with a client recently.

If the idea ends up containing sub-features, as @scott.baldwin notes above, it’s really a component at that point. You can map “component” to any internal vernacular you like.

Once you push epics and stories into an engineering space like Jira, the team should break it down further. But that level is rarely important for product planning.

Another important layer here is the strategic initiative or objective. Initiatives come out of strategic planning which might in turn be fed by these loosely defined ideas. IOW, an idea might actually end up being a whole category against which features will be prioritized.

IMHO, the Scrum “Expert” description Scott quoted is just plain wrong. That’s a non-functional requirement just like “all of my data is stored securely”, “credit card data is handled in accordance with PCI regulations”, or “the interface is available in any of our three supported localizations”. There’s no hierarchy there, just a list of requirements that should be adhered to across features.

Community Code of ConductCookie settings