Skip to main content
Back
X
Back

Scrum Forum

Sprint Review...

Last post 08:15 am August 4, 2014
by Ian Mitchell
7 replies
Author
Messages
07:13 am July 25, 2014

1.Suppose a work(from sprint backlog) is unfinished or is not completely tested, can it be included in the sprint review or be discarded from the sprint review?
2. Suppose just before the sprint it is found that it has bugs as a result of some work, what should be done - should the particular work be included in the sprint review or be discarded from the sprint review?

11:06 pm July 25, 2014

PO shall be best person to decide the priority and impact of these last minute bugs. He shall put together same and make a decision on business needs.
If the bugs are minor, that story can be accepted provided it is been communicated to stakeholders by PO in review.

05:10 pm July 26, 2014

any work that is compliant with the definition of "done" is demonstrated during the sprint review. As long as Pdo (work accepting) and dev team (work creating) sharing the same understanding on definition of "done" then none of them will either accept or demonstrate the work in sprint review.

03:16 pm July 27, 2014

All work, whether done or undone, should be inspected in a Sprint Review. Work that was planned into the Sprint but which remains undone should be re-estimated and returned to the Product Backlog. it can then be planned into a future sprint.

All work that remains on the Product Backlog should also be reviewed, regardless of whether or not it was inducted into the current Sprint. This is an opportunity to prepare the Product Backlog for the next Sprint Planning session.

02:26 am July 31, 2014

An interesting topic. When you re-estimate the work, you will probably "lose" some estimated size which will not appear in the velocity, so your planning might be less accurate. How would you deal with that? Would you advise the team to decompose the work further in the refinement and planning sessions to get a more accurate velocity? The usual answer is that it is not possible to decompose it further. Is it allowed to add the "missed" size to the velocity of the previous sprint?
I know Scrum is about delivering value and not velocity, but still I am interested in an accurate measurement for planning purposes.

03:33 am August 1, 2014

> Is it allowed to add the "missed" size to the velocity of the previous sprint?
> I know Scrum is about delivering value and not velocity, but still I am interested
> in an accurate measurement for planning purposes.

Bear in mind that when an item is re-estimated the total size of the Product Backlog is reduced. That is effectively how the work done is recorded. For planning purposes you will see less work remaining in the backlog. The recorded velocity is immaterial.

05:37 am August 4, 2014

The recorded velocity is immaterial.

Then why do people record it? In my opinion there are two reasons:
1. In Sprint Planning, the team can better estimate how many PBIs they can pull into a sprint
2. After a retrospective where they decide about a strategy to improve productivity, they can take a measurement to see if it worked.
Now you will say, productivity is not USP/time (velocity) but it is value/time. OK, but how do you measure value? And how you distinguish the change in productivity caused by the Retrospective from the change caused by the PO's decisions in sorting the PBIs?

08:15 am August 4, 2014

>> The recorded velocity is immaterial. 
> Then why do people record it?

In Kanban and similar approaches, velocity is a useful primary measure, as are throughput and cycle time. There is no Product Backlog that can be inspected for burndown.

In Scrum, teams often do use velocity as you say. However it is less than ideal as a forecasting tool because - when recorded properly - velocity excludes any partial credit for undone work.

A better planning measure in Scrum is to consider the work inducted into the Sprint minus any work re-estimated and returned to the Product Backlog. An even better one is to look at a planned Sprint Backlog in its entirety, and to view individual PBI estimates as nothing more than a very rough guide to the whole. Scrum after all is about the delivery of value as expressed through Sprint Goals, and not about being story point accountants.