Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
During an interview I was asked - how do you understand that the team has already completed a half of the Sprint Backlog?
How do we do this? Was I supposed to say that we need to sum up all the user stories that are already closed?
But in my experience user stories tend to get closed only at the last days of the sprint.
An option would be to use a burndown chart.
You can then see where your work from the Sprint backlog falls at the middle of the sprint. Image is taken from this article.
You don't really know what answer they expected. Maybe something simple, or something to tell them you know about the existence of a burndown, and maybe continue with some other questions from that, like how you can identify problems, etc.
But in my experience user stories tend to get closed only at the last days of the sprint.
This might be an indication of some issues, like:
The question is fundamentally wrong. Like nvogel says, the Developers own and manage the Sprint Backlog. Bogdan's answer suggests using a burndown chart, a good tool to visualize the amount of work remaining in the Sprint Backlog.
There are a few things to consider.
There's no good measure of "half the work". Developers may add or remove work at any point in time. Sprint Planning is also not an exact plan. The decomposition of work done at Sprint Planning is not necessarily complete - the Developers may opt only to decompose the work sufficiently to have confidence that they can achieve the Sprint Goal within the Sprint and further decompose the Product Backlog Items as the Sprint goes on.
The Sprint Goal is the purpose of the Sprint and is immutable. If the Sprint Goal becomes obsolete, the result is the cancellation of the Sprint. The work fluctuates as the team develops a deeper understanding of what must be done to achieve the Sprint Goal. On top of this, achieving the Sprint Goal doesn't necessarily require completing all Product Backlog Items.
If the underlying problem is that work gets to Done late in the Sprint, a burndown chart can visualize this. Ideally, work is completed throughout the Sprint. However, a retrospective would be necessary to dig into why the work gets to Done late in the Sprint. Several factors could lead to this.
You don't. The team owns the sprint backlog and may modify it at any time. Trying to monitor or measure the sprint backlog seems to me like micro-management but in any case it may not tell you anything useful because the current sprint is a moving target.
Burn-up charts can show you progress through the product backlog.
You have several options, if you are the Product Owner (PO) there are certain ways you can measure that. One of them is the sprint burndown which @Bodgan already referred to, that will tell you how many story points are done from the total, hence you can calculate a percentage or fraction of progress.
You also have the point of view of the value tied to each user story: this is, as a PO you should have a business value assigned to each item of the product backlog (which has nothing to do with the story points!), so if you see that certain stories are complete, you should have a measure of the value that was delivered upon that completion and that way you could say "hey, half of the sprint backlog is done", and it would be true from the product's perspective.
Notice that because value is not tied to story points or the number of items, you could easily have just 1 user story in "done" status with 95% of the value and 20 stories with the remaining 5%, and you could safely say that 95% of the sprint is done.
I think the question aimed to make you think of all the possible ways of answering it and in that way allow you to go over your knowledge of Scrum.
