You may find the following useful if you can’t easily see which user stories relate to which functionality, so you can’t tell what the impact on delivery is of a problem with a user story, or you can’t easily get a view on when functionality is expected to be ready because you’re not sure what all the relevant user stories are.
We got interested in this problem because we needed to use small user stories so that we could fully complete them in a sprint. On one project this was causing the testers to observe that if we could group the stories to make distinctions between groups of stories within a sprint, then the testing could be planned more effectively. Even following the rule of making stories independent it seemed a reasonable point - context switching would be easier. The epics were too broad to help with this, which also made it challenging to be clear about when an epic was expected to complete. On another earlier stage project it was hard for to see which stories were essential to progress to the next stage. In all cases it was resolved with a fairly quick discussion, but we were still left without a good way to capture this information in JIRA. Essentially we needed a lower level of grouping than what we’d been using the JIRA epic links for.
The solution concepts were
Optimise user story size to suit delivery in sprints
Make the stories small enough that they can be tightly defined and fully tested within the sprint
If there is any significant risk on part of a user story then assume it can’t be done, and split the story
This makes the stories easier and safer to develop, test, demo, release to production and assess, but can make them so small that the higher level functionality becomes unclear
Group the user stories by something with a higher level intent than the individual stories, but not much higher.
It should get finished in less than about three sprints otherwise it’s not specific enough
The group should apply to the one team
When you start working on this group, you should know what all the stories are. There’s a chance something will change and you’ll need to add, modify or remove stories, but that should be limited. If you don’t at least have a draft of this, then you don’t know it can be finished in three sprints.
The solution in practice …
We had been following the default JIRA pattern of having user stories grouped by epic. The epics lasted too long and contained too many individual stories to specify the level of intent of the small groups of stories being worked on.
The level of grouping we required was something like the “feature” level of SAFe, though we we wanted the grouping to only apply to stories within our team, to avoid the overhead of discussing individual stories with other teams: http://dev.scaledagileframework.com/safe-requirements-model/
Since JIRA makes the “epic link” prominent in the UI, and we were using that anyway for grouping, the easiest way to get the benefits of this new “feature” grouping was to make the epics at the level described above. This didn’t appear to lose any benefits of clarity of reporting progress at the higher level - in fact it possibly made it easier, because we could be more sure about what we would communicate about the new more granular “feature epics” than before.
Other Considerations and References...
We have appropriated another SAFe - style term though we’re using it with some simplifications, so as well as noting that our JIRA “Feature Epics” aren’t at all the same as SAFe Epics, see the diagram below for how a “Capability” is delivered.
