Locked lesson.
About this lesson
Release planning allows the Product Owner to manage the rollout of capability in order to obtain feedback and assess progress.
Exercise files
Download this lesson’s related exercise files.
Release Planning.docx61.1 KB Release Planning - Solution.docx
61.1 KB
Quick reference
Release Planning
Release planning allows the Product Owner to manage the rollout of capability in order to obtain feedback and assess progress.
When to Use Revenues and Profits
If the project is large enough to require five or more two to three week Sprints, you should plan for at least one Release. On some development projects, each Sprint is a release that adds more functionality for internal testing and evaluation. Ultimately it is a judgement call by the Product Owner as to the number and timing of releases.
Instructions
- Each release is “Potentially Shippable Product” which means that it can be used for evaluation, sale, or operations.
- The final Release of the project is normally what is sold or put into operation.
- Interim Releases are often distributed for evaluation either within the organization or to selected users/customers in order to obtain feedback about the functionality and performance that was the focus of the Release.
- When planning what will be in a Release, the Product Owner should consider a particular user or market niche and focus on the functionality required for that target.
- Based upon the target of the Release, the Product Owner should select the Stories that support the goals of that target. Use the MuSCoWa categorization to assist.
- Must have
- Should have
- Could have
- Want to have
- A project may have a combination of both development-focused Releases and market-focused Releases.
- Development-focuses Releases are targeted towards proving the effectiveness of a particular technology or technical approach.
- These Releases are used to reduce technical risk by proving a technical concept before extensive additional development work is performed.
- A project using this approach will often have an early Release (or Releases) that demonstrate the technical performance with basic system or product functionality.
- Later Releases will add additional features and performance, leading to a more complex product or system. However, the underlying technical risk of the new technology has mitigated with the first Release.
- It is very common that after the first Release, there is a significant re-write of Story Cards based upon the actual performance of the new technology.
- Market-focused Releases are targeted towards market niches or product/system upgrades.
- The Releases are used to package a set of customer/user features and functions into a Release that has commercial or operational value.
- This approach is often used with products or systems that have pre-planned upgrades, such as “quarterly updates” or seasonal products that are revised each season to accommodate market and consumer trends.
Hints and Tips
- Take the time to think through a Release strategy, then recategorize and reprioritize the Stories to support that strategy. Treat this like a “rolling wave” development where each wave gets bigger and better than the last.
- Don’t arbitrarily set a Release to happen after every “x” number of Sprints. Determine the Release strategy, then determine how many Sprints it will take to get to each Release.
- Releases are often major milestones in a project and great time to integrate back with all of your stakeholders about the progress that is being made.
- 00:04 Hi, this is Ray Sheen.
- 00:06 One more item associated with managing the backlog is Release planning.
- 00:10 The Product Owner will often segregate the product backlog into releases
- 00:15 to aid in the management of the project.
- 00:18 So let's talk about releases and some considerations when planning them.
- 00:22 If you have a large Agile/Scrum project,
- 00:24 it is often helpful to divide the product backlog into releases.
- 00:28 This will allow you an opportunity to do periodic evaluations
- 00:32 of project progress with an actual product or system.
- 00:36 The deliverable that is needed for
- 00:37 each release is a potentially shippable product.
- 00:41 This means that the product or system is at a state
- 00:44 where the Product Owner is willing to allow others to evaluate the system.
- 00:47 It has fully functioning set of features and
- 00:49 capabilities that were defined to be part of the release.
- 00:53 Not necessarily everything on the product backlog, but
- 00:56 a subset of functions that will work together.
- 00:59 It does not mean that you must ship the product, but
- 01:01 rather that is a complete enough state that you can evaluate product performance.
- 01:06 Think of it as an alpha or beta prototype unit that are used for evaluation and
- 01:10 characterization.
- 01:12 Depending upon the goals and the target of the release, and
- 01:15 its potentially shippable product, a subset of the story cards often including
- 01:20 some of the must have, should have, could have's and want have's will be included.
- 01:26 There are two different approaches that can be used when doing Release planning,
- 01:29 either Development-focused or Market-focused.
- 01:32 Either way, the release will often have several Sprints.
- 01:35 You can do a release after every Sprint and on a small project,
- 01:39 that may make sense.
- 01:40 But often on large projects, there is not enough new capability created in a two or
- 01:45 three week Sprint to make it worthwhile for
- 01:47 the organization to do the work of another release.
- 01:51 Let's consider Development Release Planning first.
- 01:54 This is normally used for projects they're developing a brand new product, system, or
- 01:58 process.
- 01:59 Because it is new there are many aspects of the features and
- 02:03 functions that must be tested and tried.
- 02:05 The early releases are used to reduce the technical risk on the project
- 02:09 by having the new technology or system do some of the basic or
- 02:12 simple functions that it will need to do.
- 02:14 With the early release of basic functions, the stakeholders can be evaluating
- 02:19 that while the scrum team is working on a next Sprint.
- 02:23 You can expect a bunch of new and
- 02:25 changing stories from the early releases of a technology development project.
- 02:30 The early release will answer some questions, raise some others, and
- 02:34 provide a much better context for the stakeholders to set their expectations.
- 02:39 When used well,
- 02:40 the early release resolves the highest technical risk items on the project.
- 02:45 The other type of Release planning is Market-focused Release planning.
- 02:48 This is often used with a product or
- 02:50 system that goes through regular updates or releases.
- 02:54 An example could be a system that has a quarterly update to add new features and
- 02:58 improve performance.
- 03:00 The basic function doesn't change, but every release incorporates those features
- 03:04 that are most important at that time to the market or business.
- 03:07 Another example is a product that prepares a new release for each new selling season.
- 03:13 In that case, the Product Owner often has a very long wishlist of stories.
- 03:17 Here she will decide which stores will be in the next release
- 03:20 based upon the Sprint capacity and velocity.
- 03:24 Let me give you an example of Release planning.
- 03:27 In this case, we have a website who are upgrading for
- 03:30 consumer products company that was formed from a recent merger.
- 03:33 The company quickly put a basic website in place, but
- 03:36 they now want to set up a schedule where they provide major upgrades every quarter.
- 03:41 For the first quarterly update,
- 03:43 the Product Owner decides that the focus would be to get online sales started.
- 03:47 They needed to get their online store operational.
- 03:50 In the first Sprint, the emphasis was just getting the structure in place for
- 03:54 large online shopping website.
- 03:56 And insuring that the highest technical risk of secure login was working.
- 04:00 The next Sprint focused on getting the store database and functionality working.
- 04:05 The third Sprint, added some basic social media and
- 04:07 interaction elements to the website.
- 04:10 With that the first release was ready.
- 04:12 It was focused on a basic functionality of the new store and how it works.
- 04:17 This is a potentially shippable product and can be released to the customer base
- 04:21 to allow them to buy products from the new company and
- 04:24 allow the new company to engage with their customers.
- 04:27 The next release is scheduled for three months later,
- 04:30 and then we'll add a lot more interactivity and customer customization.
- 04:33 The first Sprint in this quarter, converts the site into the responsive web approach
- 04:38 and adds the customization capability and structure.
- 04:41 The next Sprint adds the web page analytics and
- 04:44 embeds features that allows a customer to customize the look and feel of the page.
- 04:49 The third sprint begins to preload some of the customizable content and
- 04:53 includes poles and games for
- 04:54 customers that will provide incentives to improve their shopping experience.
- 04:59 This release is focused on user customization.
- 05:02 Of course, this release will also probably include a few stories
- 05:06 that have been added to correct bugs or
- 05:08 improve the functionality from their preceding release.
- 05:11 Knowing the release plan, the product owner is better able to determine which
- 05:15 stories best fit each of the releases and if there are other stories that don't fit
- 05:20 either release, the product owner can decide how to prioritize them and
- 05:24 whether to include them or wait for another release in another quarter.
- 05:30 Release planning is a great benefit to the Product Owner
- 05:33 when prioritizing the product backlog.
- 05:35 Releases can be structured to minimize the technical risk or focus on market offers.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.