A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Trying to decide how to do a release for a Scrum project – and whether you are ready for it – Part 2

In the previous post (Scrum Release Readiness – Part 1), we talked very briefly about what the Release Readiness is for a Scrum project. In this post, we will discuss the Release readiness in more detail, and work through what what are some of the points that need to be kept in mind when talking about release readiness.
What is release readiness ? Well, in a typical project, Release readiness means a series of steps, schedules, and plans to prepare for the final release of a project / product. A release is when the project is deemed to be in a state whereby it can be shipped to the customers / uploaded on the website and it has met the various quality checks. At the end of the final Sprint, the team would decide that the project has met the various value parameters and is now ready for shipment. Keep in mind, that when we talk about Release Readiness, we are differentiating this from the Release Planning, which runs through the entire schedule of the project. Release readiness would be defined as being able to look at various parameters, and decide that the time has now come for the release of the project, and that it is ready.
What are some of the metrics / criteria that would help in determining whether the product is now ready for release:
– The number one criteria that would be used is a pre-determined date. It is a given in the software industry that a lot of projects are determined by a pre-decided release date. As the team approaches the release date, the factors that determined the release date (such as specific Christmas schedules / heading off competitor releases, etc) need to be evaluated again to see whether there is any change in those factors.
– The user stories that are needed to have been complete for the product (basically, the prioritized list of the essential user stories is required). In the various Sprints, it is very much possible that all the desired User Stories have not been implemented. It is for the Product Manager to determine whether the User Stories that have been implemented are enough for a feasible product.
– The quality levels. The quality level of the product is of the utmost importance, since a good quality product can determine the success or failure of the product; while a poor quality product can make the entire effort seem waster, with low sales and poor customer perception. These are metrics that would have been determined much earlier and are tracked very tightly when the team moves towards the final stages of a release.
– Near the final release, the team would need to ensure that all the feedback that has been received from the stakeholders during the many Sprint end releases (from the customers / Product owner) have been incorporated (or atleast resolved in some manner that the discussion has been closed).
– The compromises that the team has made in the various parts of the Scrum cycle need to be categorised for the future, and re-evaluated to determine whether there is a significant impact of any of these compromises on the overall product quality and release. These could be bugs that were deferred because of the impact, or features that were implemented in a workaround way because of time or design limitations, and so on. Categorization of these near the end of the release, ensures that the information is captured when it is still fresh, and also because more compromises are made near the end of the release.
– There is typically a final Sprint called the ‘Release Sprint’, in which the team would integrate everything in the product, and complete the integration testing.

We will talk more about this topic in the next post in this series.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>