Back to top

Blog

A short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity.

A series of four related articles: 1. Why do we need PI Objectives when we have Features? 2. Writing good PI Objectives 3. PI Objectives and the PI Planning Process 4. PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments

Writing good PI Objectives

A short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity.

A series of four related articles: 1. Why do we need PI Objectives when we have Features? 2. Writing good PI Objectives 3. PI Objectives and the PI Planning Process 4. PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments

Why do we need PI Objectives when we have Features?

A short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity.

A series of four related articles: 1. Why do we need PI Objectives when we have Features? 2. Writing good PI Objectives 3. PI Objectives and the PI Planning Process 4. PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments

Part 4: Some practical tips to avoid waterfalling features

Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams.

This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. So what are the worst things you can do to compromise the agility of your program when using Features? In Part 4 of this series, Ian Spence provides some practical tips to avoid waterfalling your features.

Part 3: What Does it Mean for a Feature to be Ready?

Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams.

This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. So what are the worst things you can do to compromise the agility of your program when using Features? In Part 3 of this series, Ian Spence provides guidance on what it means for a Feature to be Ready.

Subscribe to Blog