Standard approach for tracking half-done features in Azure DevOps

Question

We practice Scrum (SAFe) and use Azure DevOps to track features and PBIs. The team is unsure of how to handle features which have been started but not finished at the end of a program increment.

Half the team wants to move the feature back to the program backlog, but we then lose the ability to report on effort already spent on the feature, and the fact that our forecasts were wrong.

The other half of the team wants to clone the feature...which polluted our backlogs.

Is there any standard way to do this? I’d like an approach that doesn’t confuse new team members if possible.

Answer 1

Within Scrum (and to my knowledge within SAFe as well) there is no such thing as a partially completed feature. All features are either on the backlog, being worked on or completely done. And the team only earns credit for features that are completely done.

This means that if a feature isn't completed by the end of an iteration, then it should move back to the backlog in its entirety to be re-planned. If the feature then gets planned to be picked up (early) in the next iteration, then it is probably fresh enough in the memory of the team that you can re-estimate the amount of work remaining for the feature and take the difference with the original estimate as an apparent over-commitment.
If the feature is not that important anymore to plan it early, then it is likely that the details will have been forgotten by the time work resumes on the feature and the previous work on it should be regarded as wasted.

The only reason for splitting a feature is if each part can stand on its own as a feature itself. Such a split should be done before a feature is planned, not when it overruns the iteration timebox.

As for showing that forecasts were wrong, most tools have a way of showing on iteration level which PBIs were planned for an iteration and which were actually completed. That is more useful than recording that information in the separate PBIs.