Does it matter how you write stories if you want to be able to close them? Definitely! The writing and conversation that goes with it reflects on implementation and down the line the ability to close items. It pays off to put effort into this. So how do you write to close? Read on to find out.
It is easy to skim over the writing – and start working on – half baked items. I have seen many examples (and been guilty of a fair amount myself) product backlog items (PBIs) that are only one liners or have unclear acceptance criteria or is not delimited, an open invitation to extra features and scope creep.
First I want to remind you about the central question I wrote about in the previous post:
❱ Will we get this item to done? ❰
Who should be asked (or ask themselves) this question? Of course the team that will develop the item. Getting items ready for implementation is a team effort supported by stakeholders. As the conversation unfolds stakeholders need to be present and at the ready to answer questions and provide insight on expectations and business context.
The outcome from the conversation is documented in connection to the item.
Without further ado here are the steps to write (and guide the conversation) backlog items that you will close.
Step #1: Focus on outcomes
Perhaps unintuitive – a too rigid or too specific item focusing on "what" instead of "why" can lead to increased effort. Focusing on outcomes and what you want to achieve helps the team suggest time effective technically feasible solutions.
To complement focus on outcome, and to get scope boxed in, explicitly describe scope using acceptance criteria:
Step #2: Write acceptance criteria
Acceptance criteria are item specific conditions that should be met for the item in order for it to be considered done. Acceptance criteria can be written in many different ways. One common format is BDD style given-when-then.
Don't state the obvious or simply repeat the Definition of Done (DoD). Make an effort to write acceptance criteria that describe functionality and quality attributes.
To capture all aspects of an item and to find acceptance criteria:
Step #3: Consider the 7 product dimensions
The 7 product dimensions is a great aid to ensure all aspects of item scope are considered.
User - who is interacting with the system
Action - what does the user do
Data - what data is the user acting on
Control - what business rules or other conditions apply
Interface - how does the user interact with the system
Environment - what are the environments (e.g. clients or operating systems)
Quality attributes - what "ility" constraints exists (e.g. performance, reliability, and security)
But only focusing on what to do is usually not enough. You also need a conversation about what is not part of the item, which brings us to:
Step #4: Explicitly state delimitations
Listing delimitations, things that is not part of this particular item, is an excellent way to further box in scope and ensure scope doesn't grow unexpectedly.
Some things are never needed. Other things can be postponed or are part of other items.
Delimitations help to:
Step #5: Make sure the item is small enough
Small items get done faster and offer less surprises.
One way to verify that the item is sized correctly and at the same time make sure everyone is aligned on purpose and scope is to (drum roll) estimate the item together as a team using a relative estimation technique.
Items that are too big needs to be divided into smaller pieces. Acceptance criteria and the product dimensions are good places to start looking for possible splits. Sometimes an "and" in the item summary is a clue as well.
No matter how small an item, it can still grind to a halt if the team depends on something outside the team's control, so do your best to:
Step #6: Minimize dependencies
Dependencies can be divided into internal and external dependencies.
As a general rule, internal dependencies are unavoidable, but luckily also easier to handle. Usually.
External dependencies usually exist as well but should be handled with more care. To the greatest extent possible, avoid starting on items before external dependencies are resolved.
If working in iterations plan a few iterations ahead and coordinate work across teams.
Having followed all the steps so far finally take a few minutes and:
Step #7: Think through Definition of Done (DoD)
Before you answer "yes" on if you can get the item to done, look at your DoD and ensure everything is covered.
The DoD is a manageable (read: can easily be kept in mind and fits on one slide without reverting to 7pt font size) list of things all items must fulfill to be considered "done". While acceptance criteria are item specific the DoD is common for all backlog items.
Example of things you usually find in a DoD are:
Code refactored and peer reviewed
Any needed documentation written
Tests implemented and passing
No known bugs or other technical debt introduced
Now, you could argue that taking shortcuts with the definition of done means you can close items sooner 🤯. Obviously this is a dangerous path to tread that surely leads to damnation. (If damnation is technical debt, missed deadlines and a development organization that slowly but steadily grinds to a halt.)
Final Thoughts
Composing items that are easy to close, still adds value, and allows teams to collaborate on them is an art form in its own right. But "writing to close" is a skill worth honing and it can have a huge impact on organization effectiveness.
Good luck. If you need assistance or a sounding board comment below or contact me directly.
Comments