Do you tag user stories with iteration path, their tasks or both when using Azure DevOps?
We're using Azure devops, "agile settings".
We write the user stories in different ways (combination "As a user..", "Do this", "Adjust SinglanR...", etc. We have a functional team (FA) that write the user stories - all members pitch stories do the backlog.
During the current sprint (8), FA sit down with the developer(s) and discuss the user stories that have been assigned the next sprint as its iteration path. We do this prior to the start of the sprint in order to avoid a lot of questions in the planning meeting. During the discussions, dev. break down the work into tasks. The tasks are assigned an iteration path as well. Now we have an iteration path on both the user story as well as the tasks.
In DevOps, user stories are shown with their (child)tasks in "sprint backlog view". But - let's say that you start on a user story in sprint 9, complete 50% of the work in sprint 9 but have to move the remaining set of tasks to sprint 10 - do you adjust iteration path for the remaining tasks, the user story or both? Or do you remove the iteration path from the user story when you create the task and assign iteration to them?
The reason I'm asking is that I want to group the tasks under the correct story - at the same time it is incorrect to show that a user story with iteration path 9 is "still being worked on" in sprint 10. I would therefore prefer to remove the iteration path on the user story and keep it on the task-level only.
How are others doing this?
Iteration paths are given to both, the user story and the task as well.
During the current sprint (8), FA sit down with the developer(s) and discuss the user stories that have been assigned the next sprint as its iteration path.
Since you have mentioned that you are working in sprints, I assume you are working with the Scrum framework. In which case, no external entity other than the development team can decide whether or not the user story can be delivered during a sprint i.e. the development team completely owns the sprint backlog. Here it looks like the user story is already committed for the next sprint, which would not be the correct approach.
Assuming that due to some unforeseen reasons, only 50% of the user story was complete, we would change the iteration path of the user story and all it's pending tasks as well. Ideally, all incomplete items would be sent back to the product backlog and planned again during the sprint planning meeting for the next iteration. No story points are considered in the previous iteration for that user story as there is no real value added to the increment.