Forums

By posting to our forums you are agreeing to the Forum terms of use.
Artifacts that could be delivered at the end of a Sprint
Last Post 31 Dec 2013 11:59 PM by CT. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Robert Stone
New Member
New Member
Posts:5
Robert Stone

--
22 Dec 2013 04:24 AM
    Hi everybody,

    One question about Scrum framework. It is from the PSM I exam.


    Which of these may a Develpment Team deliver at the end of a Sprint (Choose 2):

    A) An increment of software with minor bugs in it.

    B) A single document, if that is what the Product Owner asked for

    C) Failing unit tests, to identify acceptance tests for the next Sprint.

    D) An increment of working software that is "done".


    I exclude C). I think the correct anwer should be A) and D). But, why a single document could not be delivered if the Product Owner has asked for it?


    Thank you in advance.
    Fredrik Vestin
    New Member
    New Member
    Posts:61
    Fredrik Vestin

    --
    22 Dec 2013 06:11 AM
    A and C is incomplete work, i.e not done.
    B can be part of an increment so it's perfectly OK and D is obviously correct.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    23 Dec 2013 03:59 AM
    'B' and 'D' appear to be the best answers, as Fredrik has indicated.

    However, ruling out 'A' has implications that are worth considering. It establishes the position that it is not acceptable for a Development Team to release an increment of software with minor bugs in it. I'd suggest two ways of interpreting this assertion and its consequences.

    INTERPRETATION 1

    Given that each increment that is delivered includes all previous increments, this could be interpreted as meaning that any 'bugs' found in previously accepted work must be resolved before the current increment can be delivered. It implies that the Development Team should view the increment and all previously implemented requirements in totality, and should therefore resolve any observed defects on top of whatever existing Sprint commitments they have made. It also implies that all defects must be addressed in the current Sprint, even if it relates to work that has already been accepted and delivered, no matter how minor those defects may be, and even if the Product Owner would prefer to triage them for resolution after the current Sprint has finished. Most controversially perhaps, it also implies that resolving the defect is the responsibility of the Development Team , and that the problem does not lie with the Product Owner's method of acceptance.

    INTERPRETATION 2

    An alternative interpretation is to take the view that any problems uncovered after an increment has been accepted are in fact new requirements, and not 'bugs'. Bugs, by definition, would only relate to work undertaken in the current Sprint and which is not yet complete. Errors in work delivered in previous Sprints are not bugs at all, because accepted work cannot be redefined as undone. The Development Team is only forbidden to deliver work committed to in the current Sprint that contains bugs...by definition it would then be undone work. This interpretation puts the onus on the Product Owner not to accept work he or she considers to be undone, because there can be no opportunity to redefine it as undone (i.e. as containing bugs) once it has been accepted.

    Which interpretation do people think is best...or is there a better one?
    Olivier Ledru
    New Member
    New Member
    Posts:31
    Olivier Ledru

    --
    24 Dec 2013 03:07 AM
    Ian, you are right, the question is what is a "bug" in Scrum ?
    I'm not able to answer.

    Nevertheless, I'd rather choose A and D.
    The purpose of the Sprint is to have a shippable increment, not a "perfect" shippable increment, because it still deliver some value and it gives more opportunity to inspect than a single document.
    Do you know a single software without any "minor bug" ?
    Regarding Agile Manifesto, B is less valuable than A, an increment, even with 'minor bugs'
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    24 Dec 2013 05:17 AM
    > Regarding Agile Manifesto, B is less valuable than A, an increment, even with 'minor bugs'

    There's nothing to stop a Scrum Team from working entirely on documentation if that's where their skills lie, and it's what the Product Owner values.

    However, B could be ruled out on the grounds that it says "A single document, if that is what the Product Owner asked for" and not "An increment of a single document, if that is what the Product Owner asked for". The product of a Sprint should always be an increment.

    So, this is a nasty question. The only option I can conclusively rule out is C.
    CT
    New Member
    New Member
    Posts:1
    CT

    --
    31 Dec 2013 11:59 PM
    A doesnt fit the definition of done, and as far as B contrary to value regarding the agile manifesto the product owner decides what is valuable keeping intact the business and sprint goals
    You are not authorized to post a reply.


    Feedback