Release

• Myth: In Scrum, releases are done only at the end of the Sprint
  • The completeness of the increment is defined by the amount of time that is still needed to get the increment to users (e.g. to production)
  • the Sprint is the minimal boundary for when to deliver a “Done” increment. There is nothing that prevents releasing as long as the Product Owner is involved in the decision to release.
  • Scrum actually encourages release, this optimizes the value of the empirical process, as feedback becomes increasingly more applicable and realistic (even its possible to get already feedback for the Sprint Review)
  • Origins of the Myth
    • The increment can be a package of new features to be deployed in one go at the end of a Sprint. But it doesn’t have to be. An increment can also be the sum of functionality that has been released during the Sprint
    • Potentially releasable product increment Although not intended this way, the qualifiers can support a belief that increments are only (potentially) “shipped” or “released” at the end of a Sprint
    • DevOps is superior to Scrum because it allows teams to release working software faster. Because DevOps does not know the concept of a Sprint, it is argued that working software can be released whenever the team deems it “ready”
  • What about the Sprint Review?
    • a demo of working software is only a small part of the Sprint Review. The primary purpose is to inspect what was done during the Sprint and to decide what next things can be done to optimize value
    • So if the team has already released working software during the Sprint, this makes the Sprint Review an excellent opportunity to inspect feedback from real users and adapt based on the insights that emerge from that
    • The value of the Sprint Review actually increases as the “Definition of Done” of a team moves towards “Released to production”
    • you can deliver software to production multiple times (continuously) during a Sprint and in fact the best Sprint Reviews happen with software in production being used by real users
    • There is nothing stated that the increment cannot be in production before the Sprint Review. The Scrum Guide avoids defining the state the increment is in, the state is defined by the DoD
    • Release can occur many times within a Sprint or once, Scrum doesn’t care, what is important however is that we learn from what we have done, adapt in the future from that learning and deliver value to our users
• Release Maps
  • Models
    • Goal Oriented (GO)
      • (Date), Version, Goal (of the Release), Key Features, Metrics / Quarter Number
    • Story map
      • User Activities, User Tasks, Features per UA-UT-Release (can include dependencies)
• 10 Tips for PO on release planning
  • PO responsible for release strategy and release plan
    • decide what to deliver (release) to customers/users, in what order to deliver to customers/users and when to deliver
  • Tips:
  • Focus on goals, benefits and results
    • When planning for releases, there is a lot to take into account, start by identifying goals, benefits and results you want to achieve
    • Many Product Owners out there are creating a release planning which is focused around features
    • we've experienced to be even more valuable is to design a roadmap around the goals or targets you want to achieve and to show what features are contributing to a certain goal
    • GO Product Roadmap
  • Take dependencies and uncertainty into account
    • Besides planning for goals, it's really important to take dependencies and uncertainty into account
    • makes it easier to collaborate with the DT and SH and to reorder the PB in a meaningful way
    • Model to make dependencies visible, especially relevant when you're working with multiple DTs
      • Program Board or Dependency Board
        • Milestones/Events, Team 1, …, Team N / Iteration Number
          • Inside the cells
            • Milestones/Events
            • Features
            • Features with Significant dependency
            • String Dependency between F or FwSD to FwSD or M/E
      • Story Map
  • Release early and often!
    • we talk about Value, remember: “You have to release a Product to customers and users, in order to find out if you have delivered value for them!”
    • a lot of POs, think that ‘working on the Product for just a couple more Sprints’ will create a Product that customers/users will certainly love. Often, this results in a lot of disappointment…
    • So, start validating value, by releasing to your customers and users early and often!
    • Many POs though 'rather' release a couple of times a year, doing big bang releases
      • done in organizations 'because doing a release is difficult'
      • if a release becomes bigger and you release less often, it stays a difficult thing that people want to avoid
      • So, in order to make it easier, you have to do it more often!
      • When you start releasing more often, people will start to think about making it easier (by automation i.e.) they will also gain experience, which helps them in doing it better and faster
      • stop doing big bang, low frequency release and start doing smaller releases more often!
  • Only release work that is 'Done'
    • releasing 'undone work' creates technical debt
    • which costs you a lot of time and a lot of money to fix. It will cost you valuable time which you can't spend on delivering value for customers and users!
    • *So respect the DoD!*
  • Get ownership over the release process
    • Or better said: Support the DT in getting ownership over the release process
    • In many organizations, doing releases by a department such as Release Management
    • When the DT doesn't have ownership over the release process, it is often more difficult to do a release and it often costs you as a PO valuable time
    • something nor you, nor the Development Team can often decide by yourselves
    • what you can do as a PO, is to create transparency about this topic in the Sprint Review for example
  • Improve the release process continuously
    • there is more to Product development than delivering more features and functionalities
    • that improving the release process will support you in delivering more value for your Product
    • So collaborate with your Development Team to automate the release process, automate tests, automate deployments, etc
    • don't try to do it overnight though! Spend a little time on improving the release process every Sprint, so you can deliver both customer value and improve the team
  • Create at least one releasable Increment per Sprint
    • In many organizations, teams are working very hard on a lot of different things in a Sprint, this often results in the team having 100% of the work, 80% done
    • this means that a lot of work has been done, but no value for customers and users has been delivered
    • So help the Development Team by offering focus, with a Sprint Goal for example
    • Support the DT to deliver a Done Product Increment, as early as possible in the Sprint, since you will at least end up with one Increment that could be released if you'd want to
  • Don't release for the sake of releasing + Make releasing a business decision
    • In some organizations there is a centralized release calendar in which everyone has to participate, or, more and more teams are gaining ownership over the release process, making it more decentralized
    • In both situations, many teams are 'releasing because we have to release every Sprint'. This is not true! Yes, from a Scrum theory perspective you want to have a releasable/potentially shippable Product Increment every Sprint
    • Whether or not you release this Increment to production, should be a business-driven decision, not driven from a technical perspective
  • Take the context and your audience into account
    • When, how often, to whom you release an Increment depends on the context you are working in and on your target audience