Looking to submit a support request? We are now a Perforce company, please submit any requests on our new support page.
Follow

Sprint Review

At the end of a sprint, the completed work is demonstrated and (if needed) you should close the sprint by handling any unfinished work.
 
Review
 
During the sprint review the process should be as lightweight as possible, and it is not even certain that Hansoft should be used at all.
 
One common way is to give a high level overview of the sprint work in a dashboard
 
 
Both of these use a report as filter so that you can control which sprint you are looking at and to make sure we are only looking at the user stories (something you will have to adapt if you also want to include for example bug fixes):
 
For the view to the left we use an Item View.
 
For the view to the right we use a Chart with the dimension Status Completion and the Measure Number of Items.
 
Closing the Sprint
 
The next step is to close the sprint and make sure it is completed and that you can archive it.
 
Not all sprints are perfect, and some work might not have been completed. There are in essence three ways to handle unfinished work and you typically would decide for one of these:
 
1. Move all the work back to the product backlog
 
Select all the user stories that are not completed and right-click on them to select Return to Product Backlog.
 
This will:
  • Move the user stories together with all sub-tasks to the product backlog (unless it is a pipeline item where the sub-items will be deleted).
 
The big benefit with this approach is that you give the Product Owner (or who else is the stakeholder responsible for priorities) the possibility to re-prioritise the backlog in the case that any of the user stories should not be prioritised for the next sprint.
 
Also, in agile one of the key drivers is to value finished work rather than beginning work. With this way of working you drive the teams to actually complete all tasks rather than beginning too much (over-committing to sprints is a common issue).
 
As a drawback, you must re-estimate the user story (if you use estimations) and the tasks will be available in the product backlog. Some prefer to just delete the tasks and tell the teams that they must break it down again in the case it will be committed to really emphasise to only commit to things that can be completed.
 
2. Move only the remaining task to the product backlog
 
In some situations it is important that the team can account for also started work and then it usually works to just keep the remaining tasks in a new item that is clearly marked as "failed" or "unfinished" so that it is also clear that value was not delivered completely.
 
Then you would copy-paste an item to the next sprint (or back to the Product Backlog) and use the status To Be Deleted to signal which tasks were not completed in that sprint.
 
It could look like this for example after the sprint:
 
 
 
3. Drag and drop everything to the next sprint
 
This is the quickest path and appreciated by many teams to just simply drag and drop the entire item to the next sprint.
 
The issue is of course that there is little opportunity to stop the work if something else should be prioritised and it does not clearly make the tool keep the bookkeeping accurate on exactly when everything was done and velocity.
 
However, the burndown will remain intact for the past days and is often sufficient traceability in most cases to have a good retrospective.
 
Archive the sprint
 
When everything is completed in the sprint, right-click on it and select Archive to ensure the team stays focused on the next sprint. 
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request