Red Green Repeat Adventures of a Spec Driven Junkie

How to Write Better Sprint Stories

I want to share a way I write my sprint stories that have been better for me and my team to deliver in a sprint.

I go through my journey of writing stories naively after a promotion to rethinking the role of sprint stories in the sprint.

You will learn how I structure my sprint stories that has improved how I write them and the team completing their sprint stories.

This article will take you about seven minutes to read.

Altarpiece with Seated Buddha source and more information

Introduction

I originally joined my current company as an individual contributor, so my main responsibilities were to deliver results by working on sprint stories. When the company promoted to lead the team, a new responsibility in the new position is to write stories for the team’s sprint. I (and everyone else) was thinking:

I was a contributor, therefore, I know exactly what to write for a great sprint story because I did the work.

I took that attitude and just started writing stories for the team.

Write Recipe Style Stories

As a code contributor to the project, I understood how to implement solutions to the sprint story.

That’s the approach I use to writing stories, writing how to implement a solution for whoever would be doing the story.

It’s how I would solve the sprint story and it would be the best way for the team to solve problems.

Having sprint stories with how to solve the problem is basically like a cooking recipe where you just have to follow the directions and you’re done.

Easy, right?

Result of Recipe Style Stories

When writing sprint stories as a recipe, it required the story author to know how to solve the problem. Wouldn’t the time in writing the story be better used to solve the problem instead of describing how to solve it?

Requiring exactly knowing how to solve also creates a high requirement to write a story. Researching to the point of a solution may take an unknown amount of time. Making story writing slower, having the team review them later.

With the recipe style story, it would require the sprint story assignee to understand the system at the same level as the story author. Otherwise, opportunities for implementation misunderstanding.

On the converse, when I knew exactly how to solve the problem, I would write very little detail on how to do it, because it obvious as it took no effort for me.

Learning to cook from just cookbook recipes is difficult, I know because it took me until watching FoodNetwork to understand techniques described in those recipes.

This is exactly what happened here. The team got “recipes”, they couldn’t implement it at the same level with and without details.

This frustrated me, the team, and worst of all: the team wasn’t delivering results, which meant I wasn’t delivering!

Rethink Role of Sprint Story

Like cooking, I never took a “how to write a good sprint story course” (if there is, contact me.) I focused on improving my attitude towards stories in these ways:

  • Return on Story Writing
  • Make Sprint Story into Game Plan

Return on Story Writing

I realize that in a sprint, an assignee would spend at least (40 x the sprint weeks) hours on it.

If I put in just one hour into writing the story, that would be a (40 x sprint weeks) multiplier!

I was definitely spending less than an hour on each story and not getting what I want. Putting more time into each story may result in better result.

By spending more time on writing the story, there would be more details, less garbage, more specificity.

It wasn’t just “spend more time” on writing sprint stories, I rethought what the role of a sprint story was in terms of the sprint and the team.

Make Sprint Story into Game Plan

In sports, players are just executing on plans. Players and coaches spend all the time before a game practicing, running drills, building strategies, training, working out, etc.. They are not doing any of these activities during the game, they are just executing on everything done before the game.

What if the sprint story detail had all the information for the sprint story assignee to just execute during the sprint?

What could happen?

Well, they would spend their time just executing, just like in sports.

Combining this with the number of hours invested before the sprint starts could be a good way to write better stories.

The fewer “game time” decisions to make after the sprint starts, the faster everyone can achieve the goal: finishing sprint stories.

So, if I spend an hour on a sprint story that takes out all the decisions, that would be a multiplier in reducing the amount of work an assignee would need to finish the sprint story.

Hence, I focus on having sprint stores with details so the team can just execute when the sprint starts, I don’t include the how. I learned making sprint recipes didn’t work out.

So, what do I include instead?!

The Power of Why

When a person solving the problem understands why they are solving the problem, they would be:

  • more motivated
  • make better decisions to connect their solution with other parts
  • overcome unexpected challenges encountered

This last part is important, as I contributed to the system I feel I do know the system. At the same time, the longer I am not actively working on it, the higher likelihood I know less of the system.

Add to the fact when there are x contributors to the system at once, not knowing the system increases x!.

When the implementer encounters unexpected challenges, knowing why gives them motivation to keep reaching for the goal on their own instead of just giving up and coming for advice.

What do I Expect?

Having that listed down on a story for everyone to see is vital as it creates an objective record of how to complete the story.

When sprint stories have little details and expected to be perfect, that creates a high probability for “bugs”, an implementer making the wrong decision. If they didn’t make a “bug”, they got lucky.

I hate bugs and I don’t want to depend on luck if I can control more of the result.

I can as a sprint story author.

Key Sections

In every sprint story, I always include the following sections:

  • Why
  • Current State
  • Desired State

Even if I have to write a short and/or obvious story, I always include these sections.

Why

This section gives the motivation to do this work, its importance in the bigger picture of the project. How it would fit in other pieces and/or systems.

Current State

In this section, I spend time to review what is the reality of the current system and previous stories. What’s available? Has the system solved a similar problem?

This gives a mind set on possible results that are possible and drive the next section.

Sometimes, there may be nothing and that’s fine. Indicating that is important too.

Desired State

Ultimately, this is the end result I expect:

  • WHAT should the result look like?
  • WHEN user does x THEN y should happen
  • WHAT are the inputs, such as: requests parameters?
  • WHAT is the response payload?

Optional Sections

I also have optional sections where additional details:

  • Engineering Acceptance Criteria
  • Technical Notes
  • Possible Solutions

Engineering Acceptance Criteria

This section is a what section like desired state, focused on in the internals of the system to reduce technical debt.

  • WHAT kind of automated tests I expect
  • WHAT to avoid
  • WHAT changes should happen if taking one solution path

Technical Notes

The technical notes section is optional and intended for any information on how to accomplish the sprint story. It could be initial discovery for a bug, thoughts on how to approach a solution, group discussion conclusion.

What about the HOW??

One expectation of an individual contributor now writing the story is that they know how to solve the problem. Listing the why and what could leave a large gap between why and what.

One way I have resolved this is to have the technical notes section which includes any ideas I or team may have in how to solve the problem.

Another solution I use is to have another meeting with the team where we only discuss how to solve the sprint story. As the sprint story contains the why and what, we can focus on how together.

Result of Game Plan Style Stories

I have constructed all of my recent stories in this game plan style of only focusing on why and what, not how.

Writing sprint stories in this structure keeps key details in the story.

The Why & What structure reduces friction in starting to write the story. Writing a “how” story always requires detailed knowledge before-hand. There’s a good chance I will know why to do this story and what I expect as the result. Hence, I am writing stories faster, which means the team can review them sooner.

Omitting the “how to solve a story” gives the implementer freedom to approach the story as they wish. A newer team member can implement a naive solution while meeting all requirements. A senior can take a sophisticated approach. I found when a sprint story lists how, there’s only one solution allowed, regardless of the sprint story assignee.

When team members review each other’s work, the sprint story becomes a reference which all team members can check against, especially during the code review and QA process.

Conclusion

That’s my current thinking and details on sprint stories, using them as a game plan for the sprint.

I never realized how hard it is to write a good sprint story until being a sprint story author.

My goal for each sprint story now is to have enough detail in the story so the team can just execute on the story itself. I always include the why and what (current and desired) in the story.

As a previous contributor, I work with the team to fill out the how after I have the why and what details.

I enjoy being a sprint author more with this approach as this motivates me to write stories faster, with crucial details, and allows the team to be more independent during the sprint.

Ultimately, their results are my results and this helps them deliver results!