In addition to backlog refinement and ensuring team adherence to set rules and standards, the Product Owner has the responsibility of planning the releases. Release planning includes figuring out the type of release it is going to be and ensuring the team is ready and can deliver on the expected value.
The Chief Product Owner can reach out to customers to determine which type of release is preferred. Customer preference should significantly affect the type of release that the team outputs. Regardless of customer input, the decision should ultimately be left up to the Product Owner. There are three major release types that the Product Owner can choose from:
· Value-driven releases have specific requirements for the value of the output. This could mean that the Product Owner specified features or implementations that must be fully completed before the release. Time is still important but delivering on the expected value takes priority over the release date.
· Deadline driven releases are the opposite of value-driven releases. For this type of release, the Product Owner specifies a nonnegotiable release date. The team still has expectations for the value of the release, but the value can be negotiated or scaled back to meet the deadline.
· Contractual driven releases are a mix between the other two. These releases are dependent on contracts with customers or partners, or decisions made by sales or executives. In this case, the release type is no longer decided by the Product Owner and both the value and deadlines are non-negotiable.
A stance that Product Owners can take that may be beneficial is to select a release type and then build the team’s workflow around the release type. Often, when the release plan is not specified, the default strategy becomes a value-driven release, where no specific date has been chosen but a certain amount of work must be completed before the release. This pattern can be because value-driven releases put the least amount of stress on the team, with deadlines being loose for this type of release. However, many teams will also lock themselves in with deadlines and promised release dates.
Prioritizing a value-driven release type and a deadline-driven release type can lead to a potential issue where the value on the promised release day fails to meet customers’ expectations. When the current value does not match the expected release date, teams are left with an ultimatum where they have to choose whether to release what they’ve been able to accomplish so far, or finish all of the implementations and then release.
When the Product Owner fails to properly plan the releases, they may end up imposing conditions that have not been discussed on the team. This issue relates to the Product Owner’s ability to determine the release type and stick to it. If this is not specified, Product Owners may feel inclined to make up non-negotiable constraints and deadlines for the release without a need for tight constraints. This pressure can lead to neither the value nor the deadline being met because of team burnout.
Contractual driven releases bring the same challenge of having both the value and deadline locked in place. This type of release can make the team overcommitted, overworked, and overwhelmed if the requirements are too much for the team to handle. The key to overcoming this challenge is the Product Owner’s involvement in sticking to a single release type or negotiating the terms in the case of a contractual release.
If the Product Owner actively plans the release type and ensures that either value or deadlines are prioritized, teams can complete backlog items with the intent to adhere to the release type. For contractual driven releases, the Product Owner will need to coordinate with the sales team, executives, and partnerships to ensure the team will be capable of completing the requirements within the specified timeframe. Negotiating the means of the release is a major component of Release Planning. If the release type is not decided by the Product Owner, the workload should at least be negotiated to properly fit the capabilities of the team.
For contractual driven releases, whether the release is determined by an actual contract or executives’ expectations, the Product Owner should be present during the release planning.
In distributed environments, the inclusion of the Product Owner can often be overlooked because the sales, legal, and executive efforts are often considered to be separate from the development efforts. When this separation is enforced, teams may find themselves overcommitted and unable to deliver on expectations.
In a co-located environment, it is easier to include the Product Owner in those discussions but in a remote setting, the inclusion of the Product Owner can be easily forgotten. These release decisions are often dictated by the sales team. If these operations are considered to be separate from development, sales may not consider including the Product Owner in the first place. This means that the Product Owner must be aware of any team separation perceptions that other teams may have and mitigate decision-making that will directly affect the development team without representation.
In a distributed environment, the Product Owner may need to know when these meetings happen, ensure an invite to the meeting is received, and then deliver the necessary points and represent the team during the meetings. These three actions require a proactive Product Owner who understands the importance of negotiating the release constraints and can effectively represent the needs of the team through communication and negotiation with other teams and executives.
Comments