L∞P's artefacts

In this section, we are going to take a look at the L∞P Artefacts. We will mention common artefacts from other methodologies, clarify why we will not use them, and introduce some new ones.

🟢 Mission and vision

The product mission and vision should be clearly articulated and documented. The team should not only know what the product aims to be but also what it is not aiming to be.

🔴 Product backlog

We don't use a Product backlog because we use 🟢 Discovery and 🟢 DevOps backlogs instead. We do this to reinforce the idea that experimentation and discovery are fundamental steps replacing estimation and planning.

🔴 Sprint Backlog

We don't use a Sprint Backlog because we don't use time boxes. We use a pull-based system. We use a Work board and Work-in-progress limits to track our current focus.

🔴 Definition of done

We don't use a definition of done (DoD) because it is not a concept open for interpretation. Done means live and used by actual customers.

🔴 Product Increment

We don't use a Product Increment because we don't accept the idea of something being "potentially releasable". We release everything; if we are not going to release it, we don't build it.

🔴 Sprint goal

We don't use a Sprint goal because we don't have time boxes but also because our metrics are already focused on outcomes.

🟢 Explicit work policies

We use Explicit work policies to ensure that nobody corrupts or deviates from our principles.

🟢 User stories

We use User Stories, but we are careful to avoid including specific implementation details or technical requirements (WHAT) to keep the focus on the user's needs and goals (WHO and WHY). Stories should keep the focus on the user, enable collaboration and drive creative solutions