Agile Recipes: How to write a Story

Courtesy of Pixabay

Not so long ago I published an article about how to write an epic. I mentioned this will one will be the next. I will follow the same structure, but since there are many things quite similar or even the same for both, epic and stories, the overall length of this one will be somewhat shorter.

What is a Story?

I think opinions on this question are much less divided than they are on epics. Therefore I won’t waste too much time and simply write down a version of my own here. I have to emphasize I could have written it in more ways than one:

An Agile Story is a concise and simple description of the smallest defined product behavior that brings an added value to a user.

It could be a longer, more comprehensive definition, but I think this would be superfluous and moreover, this will be part of a more detailed explanation in this article.

Who is it for?

It is:

• the smallest deliverable and switchable feature for a Product Team
• the smallest A/B testable feature for Product Managers
• the largest Unit of Work that fits into the smallest Agile time-box release cycle for developers

Which information should it contain? (DoR)

• WHO is the actor, the user? There can be more than just one persona being targeted by a story, but this should be treated as an exception. If the story would target more personas, this could already be a sign of the story is either too big or even considered an epic.
• WHAT is it supposed to do? Describe the E2E flow as a direct result of the implementation. Make Acceptance Criteria clear to everyone on the team
• WHY? What is the value of the feature that epic delivers with regards to the Initiative it belongs to? Relate it to documented User Feedback. Let it resonate across the team to make it stick to it and team owning it.
• Dependencies, Blockers. Be very clear and expressive with dependencies of any kind. Make sure you note their status in terms of whether they are resolved or not. Unless they are all known and resolved, the story is not ready to go. A rule of thumb: if you have more than 3 dependencies, then you should consider to re-define a story or consider building an epic…
• Links to UX-Flows, UI-Designs, Architecture Specs, and Artefacts of all kinds. Same as it goes for an epic.
• Cross-cutting concerns beyond standard and documented. Same as it goes for an epic.
• Compliance checked and resolved. Same as it goes for an epic.
• Success/Business Metrics. Same as it goes for an epic.
• Any Labels and Classifiers. Same as it goes for an epic.
• Size. This is somewhat similar to an epic. The difference is I would always recommend Fibonacci numbers against T-Shirt sizing, which I will explain later
• Testable Flow. We need to make sure that the outcome is at least part of a testable E2E, meaning, a story delivers a clear user value/scenario.
• Mocks, Stubs. Same as it goes for an epic.
• Eventual Unknowns. Same as it goes for an epic.

Size & Estimation

While the scope of an Epic can be disputable many times, this shouldn’t be the case with the story.

A story’s scope should be defined by the smallest possible change or addition which represents the added value for a user of a product or a service

Size, however, is a different matter. Primarily because of the fact, that complexity of an added value from the user’s perspective can mean something different in terms of its technical complexity.

Imagine an example:

A Team wanted to improve the visibility of a certain copy on the page. They decided to go with framing it. There are 2 possible ways of doing it:

• simple line with rounded edges or…
• … proprietary designed frame, the same one that a company uses in its logo

2 solutions are chasing the same user goal, but the second wants to bring a slightly higher value in the form of design consistency. However, the first one is a simple implementation from the standard SDK, while the second hasn’t been implemented yet, thus needing some platform work for sure if not something more. Anyway: while the technical complexity of the second solution is still not all that high, the effort needed is several folds higher than that of the first one.

Whilst trying to deliver a meaningful increment in value added to our customer, we might easily oversize the story and drag it through two sprints or even more. That’s the trap we need to avoid with the proper understanding of technical content, dependencies, and skills needed.

Here are some general ideas about how to size a story:

• It should deliver one single feature
• It should ideally need only one developer per specific tech stack
• It should never spill over a sprint, ideally, a developer should be able to deliver or be part of the delivery of at least 2 stories per sprint
• Create subtasks to make the work of different devs transparent
• Don’t include any disproportional preparatory work into it. For example: if your product development subtasks take a little effort and the main part is in some platform work to enable it at all, then you should move this work to tech spike epics, flag them as a dependency in your story and move the story back into the backlog if it is not there already

Here are some general ideas about how to estimate a story:

• Estimate complexity (points) and not time (man/days). There might be different people with different skills working on it. If you will try to estimate the time, you will go into too many details and fall into a classic Waterfall trap. Besides: your estimate will usually be wrong because you will never be able to foresee everything or dedicate enough time for estimations.
• Estimate with the Fibonacci sequence, which makes it so easy and natural to see how the complexity progresses incrementally
• Estimate relatively against a baseline number. It doesn’t have to be set in Sprint 0. You can run a sprint or two to get a feeling about what a baseline story complexity could represent in the easiest terms to all members of the team.
• Baseline complexity should be low, but not the lowest. In the Fibonacci sequence, I would suggest the number 2.
• Always estimate according to the DoD (Definition of Done) you have agreed upon. Don’t leave out any tasks needed, including testing and deployments.
• Refine any story that would be estimated too big. Break it up to smaller ones or promote it to epic.

Avoiding blockers and dependencies upfront

The main source for dependencies in stories can already be detected in the epic that the story belongs to. Most of what you have to know about is covered already here in the epic article.

But there is one more difference here: Epic in its lifetime could contain blockers after it has been started through one or more of its stories. In that case, blockers will be resolved by finishing blocking tasks and stories, one after another. However, there’s a golden rule for the stories:

Avoid planning a story with blocker(s) into a sprint. It will make sprint much less predictable and your velocity much less understandable. Unless blockers are trivial and resources in plenty, avoid them at all costs.

How to Write Them?

I guess most on this topic was already said for epics. You can simply apply those findings from there.

Anti-patterns and Common mistakes

Again, most of the things we have already identified with epics can be easily applied to stories as well. I would still mention a few notable additions:

• Include the work which is not directly related to the outcome feature
• Don’t combine ceremonies, like Refinement and Planning. This would mostly end up in time wasted and a shallow understanding of a feature and problem to be solved
• Don’t keep the stories in the Backlog for too long. Their purpose could get outdated. Groom your Backlog often enough.

Summary

As promised at the beginning, this article was shorter than the one about writing epics.

I tried to spot the main differences from general agile recipes, which could be applied to anything that plans a chunk of work, to the ones that are story-specific,

Now you have everything in your hands to start planning your sprints. Take a deep breath, think about what can fit your business model, take some recipes from here and get to work! 😄

Follow me for more Agile recipes soon. I will talk soon about…. the OKRs!