Releasing the Product for Testers

Releasing the product deliverable to the users is a huge milestone in any project. Scrum projects will find themselves releasing early and releasing often, and it’s important to ensure that they are deploying product increments correctly. Even though quality is everyone’s job in the project, testers have the skill and experience to keep Scrum teams on track in delivering working software during every release.

What is a Product Deliverable?

A product deliverable in software development is a completed software product that has gone through different work stages such as designing, coding, and testing, and has been released to the users.

In traditional software development, releasing a product deliverable to users is held off until towards the end of the project timeline. Prior to release, the product deliverable should have already passed user acceptance tests (UAT) to verify that the specifications have been met, and the team should have already completed the required documents and prepared the build package for distribution. Delivering products this way means having the users get a completed product only at the end of the project timeline, the only time the product value will be realised.

In Scrum, the project timeline is divided into Sprints, where each Sprint aims to finish a potentially shippable product – meaning the quality of the product is being in a release-ready state. Whereas traditional software projects build the product phase-by-phase, Scrum projects build their products in increments. This approach requires Scrum teams to plan and deploy product releases in such a way that although the product has some features missing, the current set of features can already be used by the customers. Despite being incomplete, the product already delivers some of its value to the market.

How are Product Deliverables Ordered?

During Release Planning, releases of product deliverables are already plotted along a timeline, letting stakeholders strategise and forecast in what order the features should be released. These plots are then placed in a release road-map to give a high-level overview of the release plans.

Labelling releases is a best practice for letting teams track the code they pushed to production, and for users to know which version of changes they get to have.

A popular way to version software is Semantic Versioning. Semantic Versioning works like this:

“Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.”

As an example, a website labelled v2.0.15 means it’s on its 15th patch for a 2nd major release, while a mail program labelled v11.2 is on its 2nd minor release for its 11th major version. There could be more levels to Semantic Versioning, but these three levels are the basics, and the Scrum team must see to it that every release is properly labelled with their correct version.

How are Customers Informed of New Product Deliverables?

Part of release management is having a communication plan when deploying products to the users. First, they need to research and identify the various communication platforms that are frequently used by their users. They might want to answer questions like:

1. What are the demographics of the users?
2. For the various groups identified – Do they prefer phone, email, or social media?
3. How up-to-date are the contact information in the database?
4. What should be in the release notes? Have we included licenses?
5. Which devices are still supported, and which are no longer supported?

Having a sound communication plan will give additional assurance that the product release gets safely received by the users.  It also lets users prepare ahead of time, like if they need to adjust anything from their end, if they need to study how to install the software, or if they need to back up some of their data. After all, having the product rendered useless due to incompatibilities or not being informed at all of a new product update could lead to irate users, which will affect the product rating.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: