Incomplete tasks & Release management.
Hi guys,
Given: Sprints are 2 weeks long, release management is separated and fully automated, usually happens by Wednesdays, Thursdays each 2 weeks and usually delivers the last product increment.
During the spring the new version of product is created and each feature moves over Acceptance by QA in QA/UIT environment and Regression before the release. Sometimes before the start of the new sprint (but before the release) we still may have a few open tasks inside of the sprint Dev/QA pipeline (sometimes requires fixes from devs, sometimes just acceptance/regression before the release).
Current Approach:
We move the such tasks to a new sprint, allowing the QA team accept the tasks and devs to fix (if required) the issues and if they eventually passed the acceptance we do release them to the production. (This usually happens the very first 1, 2 days of the new sprint and may involve couple of people).
The Issue: One of the key stakeholders in the company dislikes the fact that some tasks had been planed for the previous sprint are moved and then closed during the new sprint and insists that something broken in the process.
What is the best practice to handle such unfinished tasks, please advice.
Thanks.
First I'm going to say that I do not believe in best practices. I believe that there are a lot of great ideas and one of them might apply for a given situation but not for others.
Having said that, my best practice is to address each situation individually and make the best decision for that situation. Don't create a rule for what will be done every time. For example, some of those "leftover tasks" might be better to be placed into the Product Backlog to be addressed at a later date. Others might be worth addressing immediately. Some of them might not be needed anymore and new tasks should take their place.
As a Scrum Master I would ask the "key stakeholder" if If their entire objection is that tasks are being carried over? Then I'd ask if they are happy with the value that is being delivered? Because Scrum shouldn't be judged on whether tasks are completed or not. It should be judged on whether there is a consistent delivery of incremental value to the stakeholder.
Teams should not be concerned about whether they finish all of the tasks. They should be concerned about whether they are meeting the Sprint Goals and are those goals providing value to the stakeholders. This is something that I would discuss with the "key stakeholder" to help them better understand how their interactions can be harmful or helpful to the team.
We move the such tasks to a new sprint
There's your problem. You've missed an inspect-and-adapt opportunity by moving undone work to a new Sprint. The matter is effectively covered up by normalizing a roll-over. Eventually it takes a stakeholder to point out to you that something must surely be wrong.
The right thing to do would be to re-estimate any undone, missing, or newly discovered work on the Product Backlog, where it may or may not be planned into a future Sprint. The Sprint Review ought to be a workshop for getting the Product Backlog in good shape, while the Retrospective should consider the risk being presented by unfinished work to the team's ability to frame and meet a Sprint Goal.