Skip to main content

How to visualize Increment as an artifact supporting empiricism?

Last post 05:10 pm April 9, 2020 by Thomas Owens
5 replies
04:01 pm April 7, 2020

Hi Everyone,

As per Scrum Guide with reference to artifacts,

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.

Whereas as per Increment referenced in the Scrum Guide,

An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint.

I am curious to know what is the reason for adaptation not being explicitly mentioned in Scrum Guide if it is mentioned implicitly w.r.t Increment? Please enlighten me! 

Thanks,

Umar


06:16 pm April 7, 2020

Well, blundly stated, the Increment is already Done and Releasable... so adaptation to THIS increment has continously been done in the Sprint which is about to end.

If empiricism is taking place, there is adaptation! Because a revised product backlog is one of the outcomes of the Sprint Review where the Increment is inspected.

In other words, the adaptation is done for the next sprint, for the next increment.

Any insights into what adaptation is needed to the current Increment being inspected, can not be adapted to the increment itself since the Sprint has ended (or is ending technically) and there can be no more work Done (since the next Spint starts directly after the previous Sprint ends)

Also, any of these insights do not make the current Increment less Valueable.

The only true "adaptation" left to the Increment is releasing it or not.

 


09:56 pm April 7, 2020

Empiricism is working based on experience and evidence. Adaptation based on what you have done and learned is inherently part of empiricism. Specifically, with respect to adaptation, the entire Sprint is about the adaptation of the Increment - Done work is integrated into the Increment, the Increment is adapted. The formal point of inspection of these adaptations is the Sprint Review, but it can happen at any point during the Sprint as well.


02:43 pm April 8, 2020

Thanks, Xander and Thomas for your valuable inputs it helps.

However, I would request some more information with an example for the below responses,

  • @Xander - The only true "adaptation" left to the Increment is releasing it or not. Do you mean Adaptation with the empirical observation by releasing it to a cohort of Users and progressing further?
  • @Thomas - Specifically, with respect to adaptation, the entire Sprint is about the adaptation of the Increment. Do you mean Increment is frequently inspected and adapted? Also is there a formal way of adapting the increment?

Thanks,

Umar


11:52 am April 9, 2020

Do you mean Adaptation with the empirical observation by releasing it to a cohort of Users and progressing further?

Deciding to release or not may hold valueable empiric evidence. And by releasing, you foster empiricism because it will create a feedback loop with your users.

Do you mean Increment is frequently inspected and adapted? Also is there a formal way of adapting the increment?

Every day during the sprint! Any feature delivered, any integration is a (formal) way of adapting. next to that, every Daily Scrum is a formal moment to inspect and adapt the Increment at hand


05:10 pm April 9, 2020

Specifically, with respect to adaptation, the entire Sprint is about the adaptation of the Increment. Do you mean Increment is frequently inspected and adapted? Also is there a formal way of adapting the increment?

Doing work is adapting the Increment.

Any time you integrate a piece of work, usually by completing items from the Sprint Backlog or getting a Product Backlog Item selected for the Sprint to Done, you have adapted the Increment. There may be some counter examples where some items on the Sprint Backlog may not result in adapting the Increment, but those are the exception rather than the rule. As you integrate this work, you often inspect the Increment to make sure that it remains in a stable and usable state.

To give an example from software, any time changes to code or configuration are merged into a branch that represents the current state of the system, that in adapting the Increment as the software product under design and development is being changed. The inspection process includes code reviews, testing (both automated and manual), and demonstrations.


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. 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.