4

I would like to ask a question about Scrum. At the end of a Sprint, when we have the Sprint Review, we present an Increment.

The guide says that this Increment has to be potentially releasable.

My question is, does this mean that every increment should involve a running prototype of the software we are building, even involving some mock functionality or data at the beginning?

(I know that it does not have to be fully operational of course.)

EDIT: Perhaps my understanding of the word "prototype" is wrong. What I meant by "prototype" was a operational (if not fully functional) piece of software that can be run and be executed.

Improve this question
8
  • I can't help noticing that answers so far mostly seem to be arguing over what exactly Scrum prescribes, like arguing over Bible text, rather than examining why working increments are (arguably) desirable and what beneficial implications it (arguably) has.
    – Steve
    Commented Jun 9, 2020 at 12:37
  • @Steve well, perhaps because my question is not asking the why but the what. I am not asking what benefits does it have either.
    – KansaiRobot
    Commented Jun 9, 2020 at 13:30
  • I can't help thinking the "why" would naturally answer your (and other people's) "what", improve the general condition of understanding greatly, and clear up ambiguity or redundancy around phrases like "potentially releasable" (I can't understand how "potentially releasable" differs from "releasable", because the suffix "-able" refers to a potential, and the only sensible interpretation of "releasable" as software professionals understand the word is that it forms something that can be given out to users and which will perform a proper function).
    – Steve
    Commented Jun 9, 2020 at 14:13
  • well, sorry, but I already know the why. But that left me still in the dark. I am interested in the what (which is much more practical) and that is why I asked the question
    – KansaiRobot
    Commented Jun 9, 2020 at 14:20
  • 1
    @Steve: I apologize for not being more clear. I meant "what do you mean by 'darkness reigns because it is not clear why the two week sprint is important and what purpose it serves exactly". It sounds like you are making claims against scrum without actually knowing what scrum is. Why participate in a question about a methodology you know very little about? Scrum isn't for everyone, but it's a very powerful and effective process for many, many teams.
    – Bryan Oakley
    Commented Jun 10, 2020 at 22:30

2 Answers 2

Reset to default
11

The wording "potentially releasable increment" may indeed appear ambiguous: some people could understand that it MUST be possible to release the product, whereas others understand that it COULD be (in some cases) possible to release (but not always).

Fortunately, the guide gives a very clear definition:

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of 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". (...) The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

So there is no ambiguity: every sprint shall deliver a working product that is better than the previous product. It should be of the same quality as a finished product, because the product owner could decide to release it.

It's therefore important not to confuse increment and prototype: an increment is meant to be releasable, wehereas a prototype is always meant to be a temporary unfinished product. A prototype is not meant to be releasable at all.

Improve this answer
6
  • As I commented to the other answer, perhaps my understanding of the word "prototype" is wrong. I thought "usable condition" meant prototype as opposed to say.. just documentation. So in simple words what should I have at the end of a sprint? A working software system? (even without the full functionality)
    – KansaiRobot
    Commented Jun 8, 2020 at 0:49
  • 1
    @KansaiRobot a working software system. Because a documentation is of no value if it would be released. And a documentation is not a usable product.
    – Christophe
    Commented Jun 8, 2020 at 0:51
  • 3
    Note that it's not uncommon for "prototype" to be misused and applied to what is an increment. For example, if your current sprint goal is achieved but it functionally doesn't make sense yet (e.g. you display stored data, but users cannot cannot input this data yet, maybe because that input feature is the next sprint's goal), that's still an increment since this feature's development (i.e. the displaying of the stored data, the current sprint goal) is finished. Just because the customer doesn't consider that finished doesn't mean that it's not "done" in the scrum team sense.
    – Flater
    Commented Jun 8, 2020 at 9:29
  • 1
    @Flater I agree that the boundaries are in some conditions, and especially in the very first sprints somewhat fuzzy. But it’s a question of mindset: a prototype is something purposely unfinished and therefore of lower quality grade. Prototype featured do not necessarily comply with definition if done. Using this word for increments therefore might mislead and create a mental bias. If people see the product as a prototype, they might let some things not completely done with the intent of later rework and the risk of forgetting it. This is why I recommend not to use it.
    – Christophe
    Commented Jun 8, 2020 at 9:39
  • @Christophe: I'm agreeing with you :) I agree with your answer but its phrasing left me worried that since an increment is being defined by its distinction from a prototype, it's important to realize that prototypes get mislabeled as commonly as increments do (since "unfinished" for a customer is not always the same as "unfinished" to a developer). I was just adding an asterisk, not trying to contradict your (IMO) correct answer.
    – Flater
    Commented Jun 8, 2020 at 9:41
4

An Increment always involves a "Done", potentially releasable, and working product. A prototype doesn't typically meet these characteristics. Instead, incremental improvement of the product is preferred. However, that doesn't mean that you can't use prototyping. Although every Sprint produces incremental improvements to the product, there's nothing that says that you can't also prototype other work in a way that enables you to receive feedback.

Improve this answer
17
  • 3
    @KansaiRobot I'm not sure how you define "prototype", but it's not typically something that is releasable and usable. A prototype is a model that is used to elicit feedback.
    – Thomas Owens ♦
    Commented Jun 8, 2020 at 1:12
  • 1
    I'm having trouble figuring out how you folks can pull off a releasable product of any significant scope in the first two week sprint.
    – Robert Harvey
    Commented Jun 9, 2020 at 13:37
  • 2
    @RobertHarvey Maybe you don't succeed. It all depends on how you define "releasable" and "significant scope". I think it's more about demonstrating progress on a rapid basis and making sure your previous work isn't broken by any new work.
    – Thomas Owens ♦
    Commented Jun 9, 2020 at 13:50
  • 1
    @Steve That is wrong, and it doesn't make sense to compare software to a wall. Every iteration does result in incremental improvement. However, it may not necessarily be visible incremental improvement. Perhaps it's tech debt paydown to enable new work in the future. Perhaps it's behind a feature flag and not available for use in production but enabled in demo environments. Perhaps it's an A/B test. To me, potentially releasable means that if you release it, stakeholders won't be in a worse place than they are now. It doesn't mean that they will be in a better place than they are now.
    – Thomas Owens ♦
    Commented Jun 9, 2020 at 14:32
  • 1
    @Steve If they don't have working software, you're doing it wrong. They should have working software after every iteration. There may or may not be value in releasing that software if it doesn't meet enough of their needs, but software never regresses from working to non-working. Consider a web application - a "hello world" page with health checks and reuslts from an infrastructure vulnerability scan is working software, but not necessarily valuable enough to release. But maybe that's enough to prove you've established the infrastructure for future work. It can also be demonstrated.
    – Thomas Owens ♦
    Commented Jun 9, 2020 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.