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.

Increment
Last Post 27 Mar 2013 04:41 PM by Susanta Kar. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Sjoerd-Jaap Westra
New Member
New Member
Posts:10
Sjoerd-Jaap Westra

--
22 Mar 2013 11:29 AM
    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
    Jack Cantwell
    New Member
    New Member
    Posts:12
    Jack Cantwell

    --
    22 Mar 2013 11:36 AM
    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.
    Sjoerd-Jaap Westra
    New Member
    New Member
    Posts:10
    Sjoerd-Jaap Westra

    --
    22 Mar 2013 11:44 AM
    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:94
    Nitin Khanna

    --
    22 Mar 2013 02: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
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

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

    --
    25 Mar 2013 12: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
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    25 Mar 2013 01: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.
    Sjoerd-Jaap Westra
    New Member
    New Member
    Posts:10
    Sjoerd-Jaap Westra

    --
    25 Mar 2013 05: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:409
    Charles Bradley

    --
    25 Mar 2013 05: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 Kar
    New Member
    New Member
    Posts:20
    Susanta Kar

    --
    27 Mar 2013 04: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