Skip to main content

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