RELATED IDEAS
User Story Mapping for Features/Requirements
Admins should have the ability to chose which records are in the User Story Mapping. We structure Aha! so that User Stories are at the Requirement Level so it makes sense for us to view as Features/Requirements
We don't use Master Features & don't want Aha! forcing the record type simply because you are leveraging the tool as this will cause user confusion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +3
8
MERGED
Allow Cards in the Map to be User Stories, as well as Epics
I love user story maps, and am a huge proponent of their use, but the mapping functionality in Aha! is currently too coarse grained for the way we use epics and stories. The Aha! story map seems geared to a model where epics map 1-to-1 with a stor...
0
Future consideration
2
MERGED
Allow Users to Configure Granularity of Story Maps
When working with Story Maps, I see that the lowest level of granularity I can use is at the Feature level. I would like the ability to choose to create story maps that go down to Requirement level granularity. Given that users/administrators have...
0
Future consideration
+1Million 😀
Similar to other comments, we integrate with ADO, and map Epic to Epic, Feature to Feature, Requirement to User Story. So to make use of the Story Mapping feature (which we very much want to do as we currently map in another tool and then have to add items in aha after that exercise), we would need to be able to configure the elements and set up our Story Maps to show Epics, Features, Requirements.
Thanks in advance. 🙏
Adding a +1 to this.
Requirements are what get built by engineering in our organization, and the restriction of flow to Master Features and Features significantly limits the value of user story mapping in Aha.
Lack of this forces a core strategic planning activity to take place in a siloed application.
Being able to add/map requirements/user stories would be immensely valuable, as we leverage epics and features at a higher level
Nicky, as a sidenote, you can rename terminology for objects in aha, so you can rename requirements to userstories in the settings!
Totally agree. If we also move everything 'up a level' to accommodate this restriction, then we lose that level of collation.
+1000
The User Story Map functionality would be an awesome addition to the Aha! suite... if we could use it at the record level commonly associated with Stories.
We've done an assessment within our ecosystem and will be using a separate tool until Requirements can be created and portrayed on the Story Map board (which would further allow for us to push to Jira).
Bonus points if all Requirements / Stories created in the Story map workflow were automatically tagged, or with the individual hash recorded... so that one could track burndown of stories when it moves to WIP.
Of course it must be possible to include user stories in the map. Aha has also made a clear semantic definition in one of the last updates by renaming master features to Epics. This means that the object type directly below the epic is also a truly "Feature". And directly below the feature are user stories, which in Aha are still called requirements.I think that's not consistent with the terminology.
I think it would make sense to configure in the map whether epics or features are offered on level 2. We create initial maps which contain goals, steps and user stories. In a second iteration, user stories are then assigned to epics or features. So you would need an additional level for the display of a complete map.
The structure is in Aha as follows:
Goal (completly missing in the map)
-> Step
--> Epic
---> Feature
----> Requirement (better User Story)
Agree.
The unintended consequences here is forcing your customers into a very specific data model that doesn't fit all companies. For us, requirements are the representation of user stories so I completely agree that we should be able to chose which records to use to maximize our utility of this functionality.
Agreed... we want to document the larger customer user map story for an EPIC at feature level and then do another level of that user story map at the requirements/story level... having both abilities will be highly benefits in creating strong product narratives for all team to engage with.
100% agree. We currently have a hierarchy in DevOps of Epic (Master Feature) >> Feature (Feature) >> UserStory (Requirement). In order to adopt Aha! Story Maps we will need to move our 'story' description into the Feature and create more Features to make sorting meaningful. Also, Aha! currently restricts a one-to-one relationship between a Master Feature and a Step which is limiting as it is common for many Features under the same Master Feature to span multiple Steps in the same Story Map.
I cannot agree more. It is very obvious that user story mapping should allow user stories (requirements) to be added.
We use requirements in the same manner as Rich. We support this change.
I couldn't agree more!
User story mapping, should map user stories, and not EPICS. If you could achieve this flexibility, then I'm sure more Aha users would be able to benefit.
Deriving from this article https://support.aha.io/hc/en-us/articles/202001137-Aha-initiative-feature-and-requirement-mapping-for-Jira-Greenhopper-, we are capturing Features as Epics and Requirements as User Stories. This has worked well until we are now trying to leverage your User Story Mapping tool. I believe the 'Steps' in the tool are Features in our world and the Feature details are Requirements to us. Especially as we have integrated to Jira with Feature -> Epic and Requirement -> User Story. We feel we need the ability to story map with requirements so that they can seamlessly flow to Jira as User Stories when dev work is ready to commence. Thanks!