Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.


Last post 09:41 pm March 27, 2013 by Susanta Kar
9 replies
04:29 pm March 22, 2013


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)?


S.J. Westra

04:36 pm March 22, 2013

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.

04:44 pm March 22, 2013

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

07:33 pm March 22, 2013

Hi S.J.,

Allow me to share my thoughts...

The Scrum Guide (Page 14) has the following on "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.

11:56 pm March 22, 2013

If the Product Backlogs are isolated, then the increments would be isolated.

05:08 am March 25, 2013

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 :-)

06:32 am March 25, 2013

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.

10:37 am March 25, 2013

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

10:59 am March 25, 2013

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.

09:41 pm March 27, 2013

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.

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

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.