Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Sprint Review...
Last Post 04 Aug 2014 03:15 AM by Ian Mitchell. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Mandeep Singh
New Member
New Member
Posts:2
Mandeep Singh

--
25 Jul 2014 02:13 AM
    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?
    Snehal Lohar
    New Member
    New Member
    Posts:10
    Snehal Lohar

    --
    25 Jul 2014 06:06 PM
    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.
    nikos batsios
    New Member
    New Member
    Posts:11
    nikos batsios

    --
    26 Jul 2014 12:10 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1687
    Ian Mitchell

    --
    27 Jul 2014 10:16 AM
    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.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    30 Jul 2014 09:26 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1687
    Ian Mitchell

    --
    31 Jul 2014 10:33 PM
    > 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.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    04 Aug 2014 12:37 AM

    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1687
    Ian Mitchell

    --
    04 Aug 2014 03:15 AM
    >> 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.
    You are not authorized to post a reply.


    Feedback