Forums

By posting to our forums you are agreeing to the Forum terms of use.
Increment
Last Post 27 Mar 2013 08:41 PM by Susanta. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
S.J. Westra
New Member
New Member
Posts:9
S.J. Westra

--
22 Mar 2013 03:29 PM
    Hi,

    Preparing for the exam so this may be a stupid question :-)

    Is the increment always the former shippable product plus new functionality? Or can the increment be isolated stand-alone functionality (isolated from the former shippable product)?

    Thanks

    S.J. Westra
    JackOLantern
    New Member
    New Member
    Posts:12
    JackOLantern

    --
    22 Mar 2013 03:36 PM
    Not a stupid question, but an interesting one. A Scrum team should work on one product at a time. What did you have in mind for this "stand-alone" functionality? Some separate utility that's part of the overall product, or a different product? If it's the former, then fine. If it's the latter, then no, that's not part of Scrum, as a general rule.
    S.J. Westra
    New Member
    New Member
    Posts:9
    S.J. Westra

    --
    22 Mar 2013 03:44 PM
    Hello Jack,

    Thanks for your prompt reply.

    I meant the former, for example new add-on funtionality of the "main product" that could be separately tested (by customers) and integrated into the "main product" in a future sprint.

    Thanks again.

    Sjoerd-Jaap Westra
    Nitin Khanna
    New Member
    New Member
    Posts:47
    Nitin Khanna

    --
    22 Mar 2013 06:33 PM
    Hi S.J.,

    Allow me to share my thoughts...

    The Scrum Guide (Page 14) has the following on "increment" --
    Increment
    The Increment is the sum of all the Product Backlog items completed during a Sprint and all
    previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it
    must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in
    useable condition regardless of whether the Product Owner decides to actually release it.
    .
    .
    .


    My interpretation of what you're describing in the "future" would not constitute as the increment.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    22 Mar 2013 10:56 PM
    If the Product Backlogs are isolated, then the increments would be isolated.
    S.J. Westra
    New Member
    New Member
    Posts:9
    S.J. Westra

    --
    25 Mar 2013 04:08 AM
    Ok, thanks.

    Suppose we delivered working software in the past, but we did not deliver complete documentation (because it was not part of the Definition of Done at that time).

    Now my customers ask for documentation (this is value for them) so as a PO I would like the team to deliver a manual.

    Could a manual (PDF document) be a valid sprint deliverable in this real-life situation or should a deliverable ALWAYS be an increment of the real software (as the theory states)?

    If the latter is the case, what is a goad approach to deliver the manual anyway? Customers still want it, even if scrum wouldn't allow it :-)

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    25 Mar 2013 05:32 AM
    It's quite reasonable for a PO to put the creation of a manual on the Product Backlog so he can negotiate it into a sprint at some point. However, I suggest this be broken up into several user stories as some sections/chapters are likely to be more valuable than others, and would benefit from early delivery. Also, authoring a manual can be soul destroying for many devs, and it may be easier for them if the work is interleaved with other stuff.

    Once the manual has been delivered, you can modify the team's Definition of Done to keep any impacted documentation updated. However, this is the sort of thing that is likely to slide, even if you mandated peer review for it. A more pragmatic option could be for the PO to request specific documentation updates in the Acceptance Criteria of relevant User Stories.
    S.J. Westra
    New Member
    New Member
    Posts:9
    S.J. Westra

    --
    25 Mar 2013 09:37 AM
    Aha! Thanks!

    Now I think I know how to look at it in a scrum-way.

    - Before the sprint - in which the manual is made - I had a potentially shippable increment without a manual.
    - During the sprint planning I pick up the backlog item "as a user of the software I want a manual so that I understand how to use the software"
    - After the sprint I have a potentially shippable increment including a manual.

    In other words, it's not the manual that will be delivered. It's the potentially shippable increment - including a manual - that will be delivered!

    Thanks for your answers!

    Sjoerd-Jaap Westra

    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    25 Mar 2013 09:59 AM
    Two comments:

    1. You're supposed to create functionality that has business value each sprint. Having the whole team work on the doc for an entire sprint doesn't do that. Maybe you could deliver the manual over two sprints and also deliver a bit of valuable functionality?

    2. Recommend adding "update user manual" to your DoD for sprints going forward.

    Sorry for the terseness.
    Susanta
    New Member
    New Member
    Posts:20
    Susanta

    --
    27 Mar 2013 08:41 PM
    I think the answer depends - it could accumulated increment on same avenue of the product or it could be different based on PO's priority on assigning the user stories. For big SCRUM project I would envision to be the later one being the case while for small SCRUM project advice would be to go for the first one - my perspective.
    You are not authorized to post a reply.


    Feedback