What do I think about them?
Way too often Stretch Objectives are understood and used by teams in a way that make them a classic case of oxymoron. And no wonder. After all “Stretch” implies uncertainty and hope. “Objectives” on the other hand imply exactly the opposite - certainty and commitment.
Teams may find it more self-fulfilling to present longer lists of objectives at the end of Program Increment (PI) planning by including along with PI Objectives also Stretch Objectives.
The reality however is that the product organization can only count on committed PI Objectives, not on hopeful Stretch Objectives. Stretch Objectives are merely work items that the organization wanted teams to take on but in the end admitted/realized they cannot be committed to in a given timeframe, due to some constraints.
Furthermore, the understanding of relative importance (priority/ranking) to deliver on Stretch Objectives is a snapshot in time, valid only at the time of PI Planning. As teams move through the Program Increment and receive new inputs, the product needs and priorities may change, potentially invalidating or changing priority of the original Stretch Objectives. For this very reason as a good practice teams should re-confirm with Product Management later during PI before work on any Stretch Objective starts.
Here is how SAFE defines Stretch Objectives:
What's your experience with Stretch Objectives?
ox·y·mo·ronDictionary result for oxymoron
/ˌäksəˈmôrˌän/nouna figure of speech in which apparently contradictory terms appear in conjunction (e.g. faith unfaithful kept him falsely true ).
Way too often Stretch Objectives are understood and used by teams in a way that make them a classic case of oxymoron. And no wonder. After all “Stretch” implies uncertainty and hope. “Objectives” on the other hand imply exactly the opposite - certainty and commitment.
The reality however is that the product organization can only count on committed PI Objectives, not on hopeful Stretch Objectives. Stretch Objectives are merely work items that the organization wanted teams to take on but in the end admitted/realized they cannot be committed to in a given timeframe, due to some constraints.
Furthermore, the understanding of relative importance (priority/ranking) to deliver on Stretch Objectives is a snapshot in time, valid only at the time of PI Planning. As teams move through the Program Increment and receive new inputs, the product needs and priorities may change, potentially invalidating or changing priority of the original Stretch Objectives. For this very reason as a good practice teams should re-confirm with Product Management later during PI before work on any Stretch Objective starts.
Here is how SAFE defines Stretch Objectives:
Stretch objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictable measure.Unfortunately, way to often teams forget the difference and keep Stretch Objectives on the list just like PI Objectives. Over time I found it best to simply move out all PI Planning candidates back to the parking lot for consideration in future Program Increments.
What's your experience with Stretch Objectives?
No comments:
Post a Comment