Establishing Guidelines for Release Planning
The code base is defined as the source code and configurations that deliver a set of features for a software release. For Agile projects that aren’t software based, it would be equivalent to tasks and processes that will be executed to deliver the final product. Code base with the highest complexities (generally meaning that it also has the highest level of risk) is generally prioritised for early validation during the testing process. Within the Scrum team, testers will work with developers to ensure that this code goes through an extensive set of quality assurance tests. Code base testing can also be prioritised based on expected usage by customers. Code base including features that will be utilised the most should be validated with a higher priority to ensure a positive user experience.
Testing thresholds and approvals will be defined by the testers and approved by the Product Owner. An example would be categorising defects as show-stoppers, important and non-production impacting. Testers will not allow features to move into production that are show-stoppers. This may mean delaying the release of features. Important feature defects will be reviewed on a one-by-one basis with the product owner to determine if a workaround is acceptable. Non-production impacting defects can be moved to the product backlog for later consideration in sprint planning.
Release Types
Functionality Driven and Date Driven releases are two primary modelling techniques used to define the scope of a release.
Functionality Driven release cycles use the modelling technique that employs the input of the product owner and project stakeholders in determining which features need to be delivered to the end user in order to gain the greatest value. The scope of features and the time that it will take to deliver determines the release date. The testers will actively work on the backlog and release planning with the product owner to assign viability to feature sets based upon known complexities and dependencies in testing. Both measurements must be accounted for to effectively plan which features will be included in the release. A tester who recognises that features and technical debt that are interdependent will lobby to have those included.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: