Sprint Review - what is the reason for discussion about tasks from Sprint

Right now our Review meetings looks typically this way:

- team is presenting what was the goal of the Sprint,

- team is demonstraiting what features were done druing Sprint

- team tells what features was in progress but was not completed at the end of the Sprint.

This is in line with what the Scrum Guide describes as what happens at the Sprint Review.

One difference is that Product Backlog Items that do not meet the team's Definition of Done "cannot be ... presented at the Sprint Review". Although the intent is good, since stakeholders who view partially complete work may not have a good grasp of what it will take to get the work to a Done state, I've found that this prohibition on discussing undone work to be overly constraining for some contexts.

Another difference is a discussion about changes in the environment, from the perspective of the Scrum Team as well as the key stakeholders in attendance. Understanding what has changed since the last Sprint Review can help with making informed decisions on what the next step(s) should be.

During team presentation there are questions from the people invited about the solution, the ideas about what could be done next etc. 

In general our PO is taking great value from this part as we are grabbing some feedback from the crowd.

After this part stakeholders outside of the team are leaving the meeting and the Scrum Team discusses the Sprint Backlog.

PO is going through the tasks in Jira project and asks a team about work done here. About what's the status if task is not done yet.

It's seems a bit strange to be talking about a Sprint Backlog. At the time of the Sprint Review, the Sprint is ending. The next Sprint's Sprint Backlog won't exist until the upcoming Sprint Planning session. But what's even more strange is that the Product Owner needs to ask about the status of work. Both the Sprint Backlog and Product Backlog should be information radiators. A stakeholder should be able to look at the backlog and understand the status of the work without needing to ask the team. There are probably some process improvements to be made here.

I am not sure what is the value of going through those tasks in Jira.

Like from the first part I have clear value with opinions from everyone, here we're checking the tasks very similar like on daily and what is not done is going almost in any case going to the next Sprint.

The Scrum Guide states that, at the conclusion of the Sprint, any undone Product Backlog Items go into the Product Backlog, where the Product Owner can order them among the rest of the Product Backlog Items, including the feedback that was obtained at the Sprint Review.

In my experience, nearly all unfinished work ends up at the top of the Product Backlog and would therefore be pulled into the next Sprint. This is also consistent with eliminating waste from inventory - partially completed work is a form of inventory, so making sure that it is done and integrated sooner is better.

If it takes the whole team to walk through the work and understand its current status, then I would recommend looking at how you are visualizing the state of the work and improving that. The Product Owner shouldn't need to take time from the whole team to understand the status of the work to consider that when ordering the Product Backlog.

- is there something missing in our Sprint Review that could give us extra benefit? To grab more info about how to proceed with developing product?

You may consider some of the suggestions from previous editions of the Scrum Guide for things that may be helpful to talk about with the key stakeholders:

• Successes or problems from the previous Sprint
• The current Product Goal and state of the Product Backlog
• Review of how the product is being used and potential uses of the product
• Review of timelines, schedules, budgets, and anticipated releases

What is useful to discuss varies depending on your context. Not everything makes sense for every team.

- what do You think about the part of the meeting about going through backlog? What value should I look in this? I guess there should be some but we're doing something wrong.

It seems indicative of a problem in transparency of the Sprint Backlog and Product Backlog. Minimally within the team - and the Product Owner is a part of the team - there should be high visibility and transparency into the state of work.

- Maybe stakeholders should also take part in this? We are trying to keep the part with stakeholders as a feature related, business point of view. Not going to technical details that would make PM's bored or so. Going through tasks in Jira will definetely go deep in the development and I see no point so far in doing this in front of stakeholders. Should we change it?

The stakeholders likely have an interest in the Product Backlog, since that is the upcoming work for the team. Making sure that they understand the current order and why the Product Owner is ordering work in the way they are is an important part of the Sprint Review. A deeper dive into the technical decomposition of the Product Backlog Items probably doesn't add a lot of value for key stakeholders, though.

- Is this part about Sprint Backlog relevant? What value should we look for in here? 

I'd say no, because there shouldn't be a Sprint Backlog at this point. Any undone work should be back on the Product Backlog and ordered with every other Product Backlog Item. This can shift your focus to the Product Backlog with the key stakeholders.

 this is the reason of my post.

I am not sure what is the value of going through those tasks in Jira.

If those tasks describe work needed to create an increment of immediately usable quality, there would be no benefit at all. The work is either Done or it is not Done, and you either trust the Developers to meet that quality standard -- and to do so honestly -- or you don't.

If those "tasks" describe scope from the Product Backlog which was planned into the Sprint Backlog, but not finished to a Done standard, then there would indeed be value in reviewing them. The whole point of a Sprint Review is to consider the work that has been Done and not Done, and to update the Product Backlog accordingly.

Hey Thomas, Ian. Thank You for the answers, they are very valuable.

I discussed the topic with our PO and I hope we will move forward with this.

We agreed that while stakeholders are still present on the meeting, discussion about where we are with current Product Goal, where are we on a Roadmap and if any changes, priorities needed to implement could give nice output.

Reagarding not Done PBIs and talking about them.

We agreed that talking through all tasks is not giving any value. 

However there are some not Done PBIs. Some of them are in In Progress status and some in Blocked.

And for now PO sees a value in going through them, as some additional actions to blocked could be triggered and to clarify what's more to be done in In progress tasks.

However as You mentioned this could be a sign that transparency on tasks is not working completely.

I can imagine that with detailed DoD we can have right away output how much of the task is done.

And with the comments on blocked tasks there could be info what's actually going on to unblock the task.

Am I right here?

For not Done PBIs, let's assume they are taken to new Sprint and we want to reestimate them, discuss if there is some unforseen problem. Refine them. When is the time to do it? On planning? I guess we should have it already prepared and cleared but there is no time to do this between Review and Planning.

What's Your opinion on this?

I can imagine that with detailed DoD we can have right away output how much of the task is done.

I don't find it useful to talk about how much of a task is done or how close to completion a task is. Even if you had a detailed Definition of Done with, for example, 10 items on it, having 5 of those met doesn't mean that the task is 50% complete. The effort is not equally distributed across all the things that need to be done to achieve a Done state. Between tasks, the effort needed to complete a certain element of the Definition of Done could vary. I prefer to talk about any unit of work as either "done" or "not done". If you need more granularity, then "not started", "in progress", and "done" could give some more insight. Anything else could lead to confusion.

And with the comments on blocked tasks there could be info what's actually going on to unblock the task.

This would be a better discussion at the Daily Scrum. Waiting for the Sprint Review to unblock the work is waiting far too long. Even if you need to talk to a key stakeholder to get the work unblocked, contact them as soon as the work is blocked.

Otherwise, the Sprint Retrospective is a better place to talk about the impediments that came up that slowed or blocked work and how to detect them earlier and prevent them so work doesn't get blocked in the middle of the Sprint.

For not Done PBIs, let's assume they are taken to new Sprint and we want to reestimate them, discuss if there is some unforseen problem. Refine them. When is the time to do it? On planning? I guess we should have it already prepared and cleared but there is no time to do this between Review and Planning.

I don't believe that reestimating work is valuable. However, if the team sees value in it, then they can choose to. It's important to find some time for refinement between the Sprint Review and the Sprint Planning events, even if it's at the start of the Sprint Planning. The Sprint Review may have added work to the Product Backlog or shuffled existing Product Backlog Items around, moving less refined work to be closer to the top. Making sure that the team has some time to refine it and understand if it's possible to take on in the upcoming Sprint is important.

I'm curious as to the timing of you events where you don't have time between the end of Sprint Review and the start of Sprint Planning to do any refinement. Perhaps you can consider moving one of these events to add some slack to the calendar.

I see Your point here.

That's true, half of the items from DoD doesn't mean the whole PBI is half done.

With those comments about blockades I ment that there is action going on and it's easily visible. Right now I assume we have actions taken but it's not totally transparent and someone if interested would need to ask what's going on. Of course waiting for Review to unblock tasks and take action would be total disaster.

About this reestimating of PBIs. I don't have clear opinion on this yet. It could have an impact on velocity and plan of the whole sprint if the PBI had 10 SP and was almost done. First, in the previous Sprint it's not counted to velocity. Second, in coming Sprint it will count as 10 but work done could be equal to 2. 

I am not sure if it should be taken so deep.. What do You think?

Regarding Refinement before planning. I would say that there is no problem with defining the timebox for this part in our team. I was more thinking about that regarding to Scrum Guide but maybe because refining  is not defined as an event then we may look at it as allowed here :)

I didn't think about it this way before.

And what You remind about possible  changes in backlog and new priorities from Review adds another value for doing such refinement at the beginning of planning.

I would say that an answer for topic regarding Story Points was cleared by Ian in another post thread from Yesterday.

"Velocity is the rate at which work is Done, not part Done"

About this reestimating of PBIs. I don't have clear opinion on this yet. It could have an impact on velocity and plan of the whole sprint if the PBI had 10 SP and was almost done. First, in the previous Sprint it's not counted to velocity. Second, in coming Sprint it will count as 10 but work done could be equal to 2. 

Using Story Points to measure velocity is a mistake in my opinion.  As I said in the same post you quoted @Ian from, Story Points are estimates.  Estimates are guesses made at a point in time based upon the information you have at that time.  They are useful for the Developers to determine if they feel like there is a possibility of finishing a body of work during a Sprint.  But as soon as work begins on that item, the estimate are no longer relevant because you are discovering new information.  That information could make the work easier or harder.  So something with 3 Story Points could take as long as something with 13 Story Points or be completed quicker than something with 1 Story Point.  Velocity is better measured with flow metrics like cycle time and throughput.  

Using your example, how do you know that the item with 10 Story Points had 8 points finished in one Sprint and 2 in the next?  Could it be that 6 points were finished in the first and 4 points in the next?  And what does it really mean to complete a single point?  How do you measure that? 

My point is that you don't complete points.  You complete work.  And as you pointed out, the quote from @Ian is "Velocity is the rate at which work is Done, not part Done".  It isn't the rate at which Story Points are done.