From 03a5308e0f023be6e4b44114ccf0ce65197ca03c Mon Sep 17 00:00:00 2001 From: Bryan Finster Date: Fri, 15 Dec 2023 07:32:28 -0600 Subject: [PATCH] Update work decomp tags --- content/en/docs/work-decomposition/_index.md | 12 +++++- .../behavior-driven-development.md | 9 ++-- .../complexity-and-estimation.md | 43 ------------------- .../contract-driven-development.md | 8 +++- .../defining-product-goals.md | 4 +- .../work-decomposition/definition-of-ready.md | 7 ++- .../work-decomposition/program-to-user.md | 8 +++- content/en/docs/work-decomposition/spikes.md | 15 ++++--- .../docs/work-decomposition/story-slicing.md | 5 ++- .../work-decomposition/task-decomposition.md | 5 ++- .../docs/work-decomposition/work-breakdown.md | 10 +++-- 11 files changed, 58 insertions(+), 68 deletions(-) delete mode 100644 content/en/docs/work-decomposition/complexity-and-estimation.md diff --git a/content/en/docs/work-decomposition/_index.md b/content/en/docs/work-decomposition/_index.md index a6ec114..4b7e869 100644 --- a/content/en/docs/work-decomposition/_index.md +++ b/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. diff --git a/content/en/docs/work-decomposition/behavior-driven-development.md b/content/en/docs/work-decomposition/behavior-driven-development.md index 5474aee..9c6936a 100644 --- a/content/en/docs/work-decomposition/behavior-driven-development.md +++ b/content/en/docs/work-decomposition/behavior-driven-development.md @@ -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 diff --git a/content/en/docs/work-decomposition/complexity-and-estimation.md b/content/en/docs/work-decomposition/complexity-and-estimation.md deleted file mode 100644 index bf39a3f..0000000 --- a/content/en/docs/work-decomposition/complexity-and-estimation.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Complexity and Estimation - -tags: [estimation] ---- - -When refining work, teams should focus on reducing complexity, minimizing -dependencies, and estimating based on complexity and effort, not time. - -Small things can be estimated more accurately than big things because the margin -of error is lower and dependencies are clear. Eliminating or reducing -[hard dependencies](/docs/glossary/#dependency-hard) is critical because the probability that something will -be delivered late doubles for every hard dependency. Those -could include database changes, coordination with other teams, or changes that are -tightly coupled with another component. - ---- - -## Recommended Practices - -Decompose stories using [Behavior Driven Development](/docs/work-decomposition/behavior-driven-development). -This not only helps with feature discovery and uncovering dependencies but also aids with [story slicing](/docs/work-decomposition/story-slicing) since each acceptance test -is naturally a thin, vertical -slice. - -Before refining, use relative sizing to project order of magnitude estimates -for delivery. However, these should not be used for commitments. Committing to -unrefined deliveries increases team allocation with re-work and "Date Driven -Development", reduces quality, and lowers end-user satisfaction. - -To avoid hard dependencies, first slice stories as small as possible to minimize -the number of possible dependencies. After that, attempt to make any hard -dependencies "soft" with feature flags, API versioning, or other coding -solutions. - -### Tips - -- Use [Cynefin](https://en.wikipedia.org/wiki/Cynefin_framework) to aid in - estimating complexity. -- If the team does not agree with the estimate, refine it further. Avoid "averaging" - the team's estimate. - ---- diff --git a/content/en/docs/work-decomposition/contract-driven-development.md b/content/en/docs/work-decomposition/contract-driven-development.md index 8383469..3b6159d 100644 --- a/content/en/docs/work-decomposition/contract-driven-development.md +++ b/content/en/docs/work-decomposition/contract-driven-development.md @@ -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 diff --git a/content/en/docs/work-decomposition/defining-product-goals.md b/content/en/docs/work-decomposition/defining-product-goals.md index d4db729..aa68848 100644 --- a/content/en/docs/work-decomposition/defining-product-goals.md +++ b/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 diff --git a/content/en/docs/work-decomposition/definition-of-ready.md b/content/en/docs/work-decomposition/definition-of-ready.md index 42de163..d07011a 100644 --- a/content/en/docs/work-decomposition/definition-of-ready.md +++ b/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?_ diff --git a/content/en/docs/work-decomposition/program-to-user.md b/content/en/docs/work-decomposition/program-to-user.md index 0d4d86e..333c224 100644 --- a/content/en/docs/work-decomposition/program-to-user.md +++ b/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 diff --git a/content/en/docs/work-decomposition/spikes.md b/content/en/docs/work-decomposition/spikes.md index 98ee9e3..12b82e3 100644 --- a/content/en/docs/work-decomposition/spikes.md +++ b/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). --- @@ -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. --- diff --git a/content/en/docs/work-decomposition/story-slicing.md b/content/en/docs/work-decomposition/story-slicing.md index f072584..da0b660 100644 --- a/content/en/docs/work-decomposition/story-slicing.md +++ b/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 diff --git a/content/en/docs/work-decomposition/task-decomposition.md b/content/en/docs/work-decomposition/task-decomposition.md index 947a349..d476522 100644 --- a/content/en/docs/work-decomposition/task-decomposition.md +++ b/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? diff --git a/content/en/docs/work-decomposition/work-breakdown.md b/content/en/docs/work-decomposition/work-breakdown.md index 357ec85..81884a9 100644 --- a/content/en/docs/work-decomposition/work-breakdown.md +++ b/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 @@ -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)