Demonstrating and Validating the Sprint for Testers

This article covers what is involved in the demonstrating and validating of the sprint deliverables. Also what process is applied and who is involved. Focusing on the Testers role in this process.

Release Planning in Agile from a Testing Perspective

Release planning in Agile is the establishment of a series of scheduled feature deliveries based on the expectations of the Product Owner and Stakeholders. The scrum team is included in release planning discussions to outline features and functionality in the product backlog that have dependencies. Technical debt reduction, environment and integration dependencies can be included in releases along with new any features. Testers within a scrum team are key in establishing guidelines, and testing thresholds.

Releases can be scheduled after each sprint or after the delivery of a series of sprints. Release plans are iterative and will be revisited along with the product backlog. There are several approaches to guide features included in release planning such as Functionality Driven releases and Date Driven releases.

Establishing Guidelines for Release Planning

Each release should be defined based on a set of criteria that is agreed upon and reviewed during the life of an agile project for relevance. Two key criteria in establishing guidelines are:

• Prioritisation of the testing code base and
• Thresholds and approvals for testing

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.

<– Continue Reading –>

Our Book Recommendations

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