PI Planning and user stories without features

Question

In our project we have features containing stories and some standalone stories which have no binding to features at all. For example it can be story for adding one new column in report.

For feature we have understandable process including wsjf and PI Planning. But what we need to do when we want to plan such standalone stories? Should we use Weighted Shortest Job First (WSJF) on them too? And plan them into PI as a part of increment? Or we can just plan some resource as a container and place such stories within it? Or we are going completely wrong and every story should be bound to a respective feature?

Answer 1

In SAFe, the Feature is the core artefact for value delivery. Because of that, adding a column into a report should in theory be linked to a value expected to be perceived by users.

The PI planning also works as a ceremony to communicate to stakeholders the changes on their systems, so by not explicitly having the feature you may be wasting an opportunity to show an evolution in your system to others.

As a standalone feature, the WSJF calculation should be pretty straightforward and with a fairly high value, not causing any prioritisation problem.

Besides, if the change in the column is needed and prioritised, it may be part of a broader pack of improvements that may constitute a feature in itself.

If there's too much bureaucracy around the PI planning and the effort is too low, you may also consider using the IP week for such small improvements (with the trade-off that the change might not get the needed visibility and the need to review the PI planning process).

Answer 2

Differentiating Between the Team-Level Critical Path vs. "Hidden Work"

There really isn't any such thing as a "standalone story" in either SAFe or Scrum. In general, all work should be related to PI Objectives at the Agile Release Train level in SAFe, or the Product Goal, Sprint Goal, or Definition of Done in Scrum. Since teams in SAFe are using ScrumBut (see the Scrum Guide's End Note), SAFe teams aren't exempted from the need to tie work to a coherent Increment each Sprint.

However, lots of things can end up on the Sprint Backlog that are needed but not clearly tied to a particular high-level objective: architectural runway, chores, or other items too small to defined at the Program Increment level. In my experience, they can still usually be tied to Features, Objectives, or Goals, but in a few cases they are simply small but necessary items that only go on the Sprint Backlog because they aren't work items anyone outside the team would understand or care about. They're just necessary things for the team to do in order to complete or perform other work. However, such items still consume team resources, and should absolutely be made visible and transparent to the Product Owner, the Release Train Engineer, and anyone else who needs visibility into the team's available capacity through the Sprint Backlog whether or not they belong on the PI Planning board as separate elements of the critical path.

That said, please avoid adding anything that might be considered "hidden work" to your Sprint Backlog. If it's work, it belongs on a backlog. If it's essential work that impacts anyone outside the team or the team's current critical path to the Sprint Goal, then it needs to be explicitly included in the Product Backlog, the Definition of Done, or some other higher-level tracking artifact. No invisible work, ever!℠ is one of the many laws of CodeGnomism, and I thank you for providing such a great use case for explaining why.