Skip to content

Commit

Permalink
Update work decomp tags
Browse files Browse the repository at this point in the history
  • Loading branch information
bdfinst committed Dec 15, 2023
1 parent bea9c6f commit 03a5308
Show file tree
Hide file tree
Showing 11 changed files with 58 additions and 68 deletions.
12 changes: 11 additions & 1 deletion content/en/docs/work-decomposition/_index.md
@@ -1,8 +1,18 @@
---
title: "Work Decomposition"
linkTitle: "Work Decomposition"

weight: 3
description: >
Tips for breaking down work to "small enough".
---

Reducing the batch size of delivered work is one of the most important things we can do to drive improved workflow,
quality, and outcomes. Why?

- We have fewer assumptions in the acceptance criteria because we had to define how to test them. The act of defining them as tests brings out questions. "How can we validate that?"
- We are less subject to hope creep. We can tell within a day that we bit off more than we thought and can communicate that.
- When we deliver and discover the story was wrong, we've invested less in money, time, and emotional attachment so we can easily pivot.
- It makes us predictable
- It helps to reset our brains on what "small" is. What many people consider small turns out to be massive once they see what small really is.

The following playbooks have proven useful in helping teams achieve this outcome.
@@ -1,9 +1,12 @@
---
title: Behavior Driven Development

weight: 2
tags:
- testing
- decomposition
- Batch Size
- Teamwork
- Testing
- Planning
- Product Ownership
---

Behavior Driven Development is the collaborative process where we discuss the intent and behaviors of a feature and
Expand Down
43 changes: 0 additions & 43 deletions content/en/docs/work-decomposition/complexity-and-estimation.md

This file was deleted.

@@ -1,7 +1,11 @@
---
title: Contract Driven Development

tags: [testing, architecture]
tags:
- Batch Size
- Testing
- Architecture
- Planning
- Evolutionary Change
---

Contract Driven Development is the process of defining the contract changes
Expand Down
4 changes: 2 additions & 2 deletions content/en/docs/work-decomposition/defining-product-goals.md
@@ -1,7 +1,7 @@
---
title: Defining Product Goals

tags: [product management]
tags:
- Product Ownership
---

## Product Goals
Expand Down
7 changes: 5 additions & 2 deletions content/en/docs/work-decomposition/definition-of-ready.md
@@ -1,7 +1,10 @@
---
title: Definition of Ready

tags: [teamwork, decomposition]
tags:
- Batch Size
- Teamwork
- Planning
- Product Ownership
---

_Is it REALLY Ready?_
Expand Down
8 changes: 7 additions & 1 deletion content/en/docs/work-decomposition/program-to-user.md
@@ -1,6 +1,12 @@
---
title: From Program to User Story

weight: 1
tags:
- Planning
- Prodcut Ownership
- Roadmaps
- Vision
- Goals
---

Aligning priorities across multi-team products can be challenging. However, the process used at the team level to decompose work
Expand Down
15 changes: 9 additions & 6 deletions content/en/docs/work-decomposition/spikes.md
@@ -1,11 +1,13 @@
---
title: Spikes

tags: [teamwork, decomposition]
tags:
- Batch Size
- Continuous Learning
- Planning
---

Spikes are an exploration of potential solutions for work or research items that cannot be estimated. They
should be time-boxed in short increments (2-3 days).
should be time-boxed in short increments (1-3 days).

---

Expand All @@ -19,9 +21,10 @@ valuable, for some iteration in the future.
Spikes should follow a [Definition of Done](/docs/workflow-management/definition-of-done),
with acceptance criteria, that can be demoed at the end of its timebox.

A spike should have a definite timebox, usually within 1-3 days. At the end of
this timebox, the team should be able to decide how, when, and even if the work
can be considered for upcoming iterations.
A spike should have a definite timebox with frequent feedback to the team on what's been learned so far. It can be
tempting to learn everything about the problem and all of the solutions before trying anything, but the best way to
learn is to learn using the problem in front of us right now. Batching learning is worse than batching other kinds of
work because effective learning requires applying the learning immediately or it's lost.

---

Expand Down
5 changes: 3 additions & 2 deletions content/en/docs/work-decomposition/story-slicing.md
@@ -1,7 +1,8 @@
---
title: Story Slicing

tags: [decomposition]
tags:
- Batch Size
- Teamwork
---

Story slicing is the activity of taking large stories and splitting them into
Expand Down
5 changes: 3 additions & 2 deletions content/en/docs/work-decomposition/task-decomposition.md
@@ -1,8 +1,9 @@
---
title: Task Decomposition
weight: 10

tags: [decomposition]
tags:
- Batch Size
- Teamwork
---

## What does a good task look like?
Expand Down
10 changes: 6 additions & 4 deletions content/en/docs/work-decomposition/work-breakdown.md
@@ -1,8 +1,11 @@
---
title: Work Decomposition
weight: 1

tags: [decomposition]
tags:
- Batch Size
- Teamwork
- Planning
- Product Ownership
---

In order to effectively understand and implement the work breakdown flow, the
Expand Down Expand Up @@ -63,8 +66,7 @@ completed in less than two days. Stories are made up of one or more tasks.

Typical problems teams experience with decomposition are:

- [Stories are too big](/docs/work-decomposition/story-slicing)
- [Stories are too complex](/docs/work-decomposition/complexity-and-estimation/)
- [Stories are too big or complex](/docs/work-decomposition/story-slicing)
- [Stories lack testable acceptance criteria](/docs/work-decomposition/behavior-driven-development)
- [Lack of dependency knowledge](/docs/work-decomposition/contract-driven-development)
- [Managing research tasks](/docs/work-decomposition/spikes)
Expand Down

0 comments on commit 03a5308

Please sign in to comment.