Software Release Planning – An Overlay to Scrum

Story maps are invaluable tools to help product planners (Product Owners / Product Managers / Requirements Analysts) visualize all features (User Stories) in a release through the context of the User’s experience with the product.

The goals of Story Mapping are:

1. Visualize the complete product experience versus a collection of individual features (User Stories).
2. Ensure that no User Stories are missing.
3. Prioritize by release… some User Stories may be deferred to a subsequent release.

In Story Mapping, User Stories are logically grouped into Epics or User Journeys. For example, a product might have an Epic for “Registration & Login” that would include the following User Stories:

• Create an account with email (enter email address, submit form).
• Receive verification email (system sends an email to the user with a link to confirm ownership and accuracy of the email address).
• Verify email address and complete account creation (click email link, add avatar, name, password, and any other desired information).
• Login.
• User initiates password reset (from login screen, user clicks option to reset password, enters email address and submits form).
• Receive password reset email (system sends email to the user with link to complete password reset).
• Complete password reset (click email link, enter new password, and submit form).

User Stories need not be completed to create a Story Map. Summary information per above is sufficient for the time being given the objectives above.

We covered the definition of the Product Backlog in Sprint Basics. In the context of release planning, the Product Backlog is the repository into which User Stories prioritized for the release being planned to be prioritized.

So where then do User Stories deferred to a future release go? Where do new ideas customers request go?

The Icebox is a concept NOT covered by the Scrum method, but is invaluable to Product Owners as a repository for futures. By creating an Icebox for each software product, the Product Owner can keep the Product Backlog “clean” and avoid the chance that an enterprising team elects to complete a User Story that the Product Owner deferred to a future release (yep, it happens).

The Icebox, like the Product Backlog, can be groomed although it’s not required. But as the Icebox grows in size, it’s helpful to create priorities and even start Story Mapping the next release while the current release is being built.

Software features and releases have functional requirements and non-functional requirements. Functional requirements are features with which users interact and gain value. Non-functional requirements are software qualities that determine architecture, technology stack and testing parameters of the product.

Examples of non-functional requirements might include:

• For a web application, whether or not the application must be responsive, and to what screen resolutions and break points (at what browser width the layout “breaks” to each screen size).
• For a mobile application, which platforms (iOS, Android, etc.) and screen resolutions the application must support; whether tablets and phones have the same layout; and (possibly) whether the application must support landscape versus portrait mode.
• Scalability and performance requirements typically defined based on “peak load” the highest level of usage the application should see in terms of simultaneous user sessions.
• The level of quality that must be achieved for the software to be released. For example, defects with a priority of urgent and high priority must be fixed, but the software can be released with medium or low priority defects.

In many cases, non-functional requirements are the same for all features in a release. Thus, having to draft these requirements for every User Story is unnecessarily time consuming.

Instead, CodeStringers advocates adding a definition of done for each software release that captures all non-functional requirements that are common to all User Stories in the release.

On another page of this resource center, we told you not to estimate effort in time (the lumberjack analogy). But there is one exception. When estimating the first version of a new software product to be built by a newly established development team.

Newly established teams working on new products do not have a Velocity measurement. Thus, they are able to estimate individual User Stories in Story Points based on past experience, how do they translate those estimates into a release date?

A business cannot execute without release dates. Marketing can’t plan launches and demand generation programs. Sales can’t forecast deals and revenue. Operations doesn’t know when they need additional resources or training to support the product.

So, how do we create predictability?

The process is pretty simple, but will result in both predictability and transparency within your company about when the release will be complete and where the development organization is in the process.

After Story Mapping is complete and the release User Stories are in the Product Backlog, the team estimates everything in the Product Backlog using time-based estimates. This process may take one to three days, which may seem a waste of time, but the answer it provides is worth the investment.

When the CodeStringers team completes these estimates, the mandate given to them is to create “no greater than” estimates. We live by the “under promise and over deliver” saying.

That effort estimation allows us to provide the company with a planned release date.

Once we have a time-based estimate, we complete several sprints. Prior to each Sprint, the team estimates the Stories in the Sprint Backlog in Story Points. The number of sprints depends upon the length of the release. We strive at CodeStringers to have the number of sprints we complete at this point equal about 10 percent of the expected sprints based on the time-based estimate.

This allows us to establish a Velocity. Although that Velocity has likely not reached its peak yet as the team is still ramping up, we can guesstimate based on experience and the current Velocity how much the Velocity will increase with more team experience.

Then, the team re-estimates all remaining Stories in the Product Backlog in Story Points. At this point, we have the benefit of experience on the current software product to support comparative Story estimates relative to Stories already completed on this Product.

We divide the total of all Story Points remaining in the Product Backlog by the Velocity, which gives us a second view of the number of remaining sprints.

This methodology has a few benefits:

We now have to methods of predicting a release date and we can compare them to each other. This predictability gives the organization the opportunity to take action if the first (time-based) estimate was low, meaning we will miss the release date absent a change in scope and/or resources. This in turn allows the organization to have time to either change the release date (early enough that other departments have sufficient time to adjust their plans), reduce release scope (defer features to a later release), or increase resources to increase the Velocity.

We learn how accurate our time-based estimates were and if/when we’re wrong, the reasons. This learning helps improve future estimates. When estimates are wrong, it’s typically (in CodeStringers’ experience) for one of a couple reasons:

1. We missed entire User Stories in our Story Mapping. It happens. There’s a science and art to envisioning a software release and ensuring that all functionality is documented in the release plan. And even the most experienced product planners miss things.
2. Downstream logic where one User Story impacts others or creates others aren’t considered. For instance, if you have an application where user permissions determine functionality available to users, every feature has to be implemented with permissions in mind. Sometimes things of this nature aren’t considered by the team when doing initial time-based estimates.

In these situations, it’s helpful to review the “mistakes” and learn from them so that time estimates on future releases increase in accuracy.

Go through this process on a few hundred software products and the team gets pretty accurate.