Increment

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.

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

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.

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

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

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.

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

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.

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.