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 - From Roadmap to User Story
A guide to aligning priorities and breaking down work across multi-team products
Aligning priorities across multi-team products can be challenging. This guide outlines how to effectively break down work from program-level roadmaps to team-level user stories.
Program Roadmap
Key Point
Establishing and understanding goals and priorities is crucial for an effective work breakdown process.
Program Roadmap
Stakeholders and leadership teams must define high-level initiatives and their priorities
Work can then be dispersed among product teams
Leadership teams can be composed of a core group of product owners
Product Roadmap
The program roadmap should break down into the product roadmap, which includes the prioritized list of epics for each product.
Product Vision
The leadership team should define:
Product vision
Roadmap
Dependencies for each product
Team Backlog
The team backlog should comprise the prioritized epics from the product roadmap.
Feature Backlog
Effective Work Breakdown
The core group needed to effectively break down high-level requirements includes:
Product owners
Tech leads
Project managers
Product teams should use processes effective for Work Decomposition to break down epics into:
Smaller epics
Stories
Tasks
2 - Work Decomposition
A guide to effectively breaking down work into manageable, deliverable units
Effective work decomposition is crucial for delivering value faster with less rework. This guide outlines the process and best practices for breaking down work from ideas to tasks.
Prerequisites
Before implementing the work breakdown flow, ensure your team has:
Behavior Driven Development is the collaborative process where we discuss the intent and behaviors of a feature and
document the understanding in a declarative, testable way. These testable acceptance criteria should be the
Definition of Done for a
user story.
BDD is not a technology or automated tool. BDD is the process of defining the behavior. We can then
automate tests for those behaviors.
Example:
Feature: I need to smite a rabbit so that I can find the Holy Grail
Scenario: Use the Holy Hand Grenade of Antioch
Given I have the Holy Hand Grenade of Antioch
When I pull the pin
And I count to 3But I do not count to 5And I lob it towards my foe
And the foe is naughty in my sight
Then my foe should snuff it
Recommended Practices
Gherkin is the domain specific
language that allows acceptance criteria to be expressed in “Arrange, Act, Assert” in a
way that is understandable to all stakeholders.
Example:
Feature: As an hourly associate I want to be able to log my arrival time so that I can be
paid correctly.
Scenario: Clocking in
Given I am not clocked in
When I enter my associate number
Then my arrival time will be logged
And I will be notified of the time
Scenario: Clocking out
Given I am clocked in
When I enter my associate number
And I have been clocked in for more than 5 minutes
Then I will be clocked out
And I will be notified of the time
Scenario: Clocking out too little time
Given I am clocked in
When I enter my associate number
And I have been clocked in for less than 5 minutes
Then I will receive an error
Using Acceptance Criteria to Negotiate and Split
With the above criteria, it may be acceptable to remove the time validation and accelerate the delivery of the time
logging ability. After delivery, we may learn that the range validation
isn’t required. If true, we’ve saved money and time by NOT delivering
unneeded features.
First, we deliver the ability to clock in and see if we really do need the ability
to verify.
Feature: As an hourly associate I want to be able to log my arrival time so that I can be
paid correctly.
Scenario: Clocking in
Given I am not clocked in
When I enter my associate number
Then my arrival time will be logged
And I will be notified of the time
Scenario: Clocking out
Given I am clocked in
When I enter my associate number
And I have been clocked in for more than 5 minutes
Then I will be clocked out
And I will be notified of the time
If, in production, we discover that the sanity check is required to prevent time
clock issues, we can quickly add that behavior.
Feature: As an hourly associate I want to be prevented from clocking out immediately after
clocking in.
Scenario: Clocking out more than 5 minutes after arrival
Given I am clocked in
And I have been clocked in for more than 5 minutes
When I enter my associate number
Then I will be clocked out
And I will be notified of the time
Scenario: Clocking out less than 5 minutes after arrival
Given I am clocked in
And I have been clocked in for less than 5 minutes
When I enter my associate number
Then I will receive an error
Tips
Scenarios should be written from the point of view of the consumer. If the consumer; either a user, UI, or another service.
Scenarios should be focused on a specific function and should not attempt to
describe multiple behaviors.
If a story has more than 6 acceptance criteria, it can probably be split.
No acceptance test should contain more than 10 conditions. In fact, much less
is recommended.
Acceptance tests can be used to describe a full end-to-end user experience. They are also recommended for describing
the behavior of a single component in the flow of the overall behavior.
A development task is the smallest independently deployable change to implement
acceptance criteria.
Recommended Practices
Create tasks that are meaningful and take less than two days to complete.
Given I have data available for Integration Frequency
Then score entry for Integration Frequency will be updated for teams
Task: Create Integration Frequency Feature Flag.
Task: Add Integration Frequency as Score Entry.
Task: Update Score Entry for Integration Frequency.
Use Definition of Done as your
checklist for completing a development task.
Tips
If a task includes integration to another dependency, add a simple contract
mock to the task so that parallel development of the consumer and provider will
result in minimal integration issues.
Decomposing stories into tasks allows teams to swarm stories and deliver value
faster
5 - Contract Driven Development
Contract Driven Development is the process of defining the contract changes
between two dependencies during design and prior to construction. This allows
the provider and consumer to work out how components should interact so that
mocks and fakes can be created that allow the components to be developed and
delivered asynchronously.
Recommended Practices
For services, define the expected behavior changes for the affected verbs along
with the payload. These should be expressed as contract tests, the unit test of
an API, that both provider and consumer can use to validate the integration independently.
For more complicated interaction that require something more than simple canned
responses, a common repository that represents a fake of the new service or tools
like Mountebank or WireMock
can be used to virtualize more complex behavior. It’s important that both
components are testing the same behaviors.
Contract tests should follow Postel’s Law:
"Be conservative in what you do, be liberal in what you accept from others".
Tips
For internal services, define the payload and responses in the developer task
along with the expected functional test for that change.
For external services, use one of the open source tools that allow recording
and replaying responses.
Always create contract tests before implementation of behavior.
6 - Defining Product Goals
Product Goals
Product goals are a way to turn your vision for your product into easy to
understand objectives that can be measured and achieved in a certain amount of time.
Increased transparency into product metrics
Measurable Outcome: Increased traffic to product page
When generating product goals, you need to understand what problem you are
solving, who you are solving it for, and how you measure that you achieved the goals.
Initiatives
Product goals can be broken down into initiatives, that when accomplished,
deliver against the product strategy.
Provide one view for all product KPIs.
Ensure products have appropriate metrics associated with them.
Initiatives can then be broken down into epics, stories, tasks, etc. among
product teams, with high-level requirements associated.
Epics
An epic is a complete business feature with outcomes defined before
stories are written. Epics should never be open ended buckets of work.
I want to be able to review the CI metrics trends of teams who have completed a
DevOps Dojo engagement.
Tips
Product goals need a description and key results needed to achieve
them.
Initiatives need enough information to help the team understand the expected
value, the requirements, measure of success, and the time frame associated to completion.
7 - Definition of Ready
Is it REALLY Ready?
A Definition of Ready is a set of criteria decided by the team that defines when
work is ready to begin. The goal of the Definition of Ready to help the team
decide on the level of uncertainty that they are comfortable with taking on with
respect to their work. Without that guidance, any work is fair game. That is a
recipe for confusion and disaster.
Recommended Practices
When deciding on a Definition of Ready, there are certain minimum criteria that
should always be there. These are:
Description of the value the work provides (Why do we want to do this?)
Testable Acceptance Criteria (When do we know we’ve done what we need to?)
The team has reviewed and agreed the work is ready (Has the team seen it?)
However, the context of a team can make many other criteria applicable. Other
criteria could include:
Wireframes for new UI components
Contracts for APIs/services we depend on
All relevant test types identified for subtasks
Team estimate of the size of the story is no more than 2 days
The Definition of Ready is a living document that should evolve over time as
the team works to make their delivery system more predictable. The most
important thing is to actually enforce the Definition of Ready. If it’s not
enforced, it’s completely useless.
If any work in “Ready to Start” does not meet the Definition of Ready, move
it back to the Backlog until it is refined.
Any work that is planned for a sprint/iteration must meet the Definition of
Ready. Do not accept work that isn’t ready!
If work needs to be expedited, it needs to go through the same process.
(Unless there is immediate production impact, of course)
Definition of Ready is also useful for support tickets or other types of work
that the team can be responsible for. It’s not just for development work!
It’s up to everyone on the team, including the Product Owner, to make sure
that non-ready work is refined appropriately.
The recommended DoR for CD is that any story can be completed, either by the team or a single developer, in 2 days or less
8 - Spikes
Spikes are an exploration of potential solutions for work or research items that cannot be estimated. They
should be time-boxed in short increments (1-3 days).
Recommended Practices
Since all work has some amount of uncertainty and risk, spikes should be used
infrequently when the team has no idea on how to proceed with a work item. They
should result in information that can be used to better refine work into something
valuable, for some iteration in the future.
Spikes should follow a Definition of Done,
with acceptance criteria, that can be demoed at the end of its timebox.
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.
Tips
Use spikes sparingly, only when high uncertainty exists.
Spikes should be focused on discovery and experimentation.
Stay within the parameters of the spike. Anything else is considered a waste.
9 - Story Slicing
Story slicing is the activity of taking large stories and splitting them into
smaller, more predictable deliveries. This allows the team to deliver higher
priority changes more rapidly instead of tying those changes to others that may
be of lower relative value.
Recommended Practices
Stories should be sliced vertically.
That is, the story should be aligned such that it fulfills a consumer request
without requiring another story being deployed. After slicing, they should still
meet the INVEST principle.
Example stories:
As an hourly associate I want to be able to log my arrival time so that I can be
paid correctly.
As a consumer of item data, I want to retrieve item information by color so that
I can find all red items.
Stories should not be sliced along tech stack layer or by activity. If you
need to deploy a UI story and a service story to implement a new behavior, you
have sliced horizontally.
Do not slice by tech stack layer
UI “story”
Service “story”
Database “story”
Do not slice by activity
Coding “story”
Review “story”
Testing “story”
Tips
If you’re unsure if a story can be sliced thinner, look at the acceptance
tests from the BDD activity and see if it
makes sense to defer some of the tests to a later release.
While stories should be sliced vertically, it’s quite possible that multiple
developers can work the story with each developer picking up a task that
represents a layer of the slice.
Minimize hard dependencies in a story. The odds of delivering on time for any
activity are 1 in 2^n where n is the number of hard dependencies.
