Publications

Welcome to the amalgamation of a short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity. We have seen a lot of confusion surrounding the use of PI objectives; confusion that often results in: Resistance to their use and; The production of poorly formed team objectives that appear to be completely redundant as they just list the Features being addressed. The first step to creating well-formed, useful objectives is for everyone to understand why they are so important. Covered in this document: Why do we need PI Objectives when we have Features? Writing good PI Objectives PI Objectives and the PI Planning Process PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments  

Scrum and its hybrids are the dominant approaches used by Agile teams today. However, despite Scrum being a seemingly simple framework, many teams struggle to apply Scrum well and fail to achieve the faster delivery of higher value products that are promised. Playing the Practice Spotlight game is a simple way to improve any team's understanding and application of Scrum.

In this series of posts we wil explore the Events that either perform, schedule or track the activities that affect the Lifecycle of an Epic. This second post looks at how the events that run the Portfolio could be structured.

In this series of posts we wil explore the Events that either perform, schedule or track the activities that affect the Lifecycle of an Epic. This first post looks at the activites that the Portfolio needs to perform in order for it to make progress.

Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation. This post looks at some of the alternate scenarios that might be seen in the Epic lifecycle, covering Bad Ideas, Small Ideas, Lean-Startup and Exploring Options.

Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation. In this post we’ll explore the Portfolio Kanban that visualises the lifecycle of an Epic and look at some of the decisions that influence the Epic’s progress through its lifecycle.  

Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation. This post explores the Lifecycle of an Epic and the states it progresses through in that Lifecycle.

This article explores the synergy of Scrum and Essence, a domain model of software engineering processes, intending to become a common ground for software development methods, bringing clarity into the composition of methods from individual practices.

What do we mean by Quality? The word Quality is commonly used in software development, but it isn’t always clear what is meant by it. Teams create Definitions of Done, configure thresholds in their CI/CD pipeline, write performance tests and agree service level agreements, but are these sufficient for the level of Quality the customer expects?