Writing Agile Stories, Part 3 – Setting Good Story Goals

Creating a good user story in the backlog is challenging. As I described last week, the first step is writing stories that are small, meaningful, and focused on inputs/outputs.

But that’s not enough. Even if you have experience writing Agile stories, have you been clearly articulating the goal of the story? Do you provide the deeper why behind a story? If not, then I recommend including a goal to make your stories even better.

The Purpose of a Story Goal

I like to set a concise goal at the beginning of every story. The intent is to bring clarity to the story. Why are we pursuing this feature? What’s the motivation behind it?

Knowing the answer to these questions helps set context, opens up the reader’s mind to what could be, and solicits critical feedback.

Some Examples

Let’s start with a counterexample—a poorly written goal.

“Pin all started-but-incomplete tasks to the top of the web page in bold red.”

In my opinion, this is too prescriptive of a solution:

• It prescribes that we’re on a web page.
• It prescribes where on the page the tasks should go.
• It prescribes the visual design of the page.

Going into this level of detail assumes a solution and limits the thinking of a reader.

Now here is an example of a well-authored goal:

“Make started-but-incomplete tasks prominent to encourage users to finish what’s been started.”

I like the second approach because:

• It abstractly describes the need to make started-but-incomplete tasks prominent.
• It gives a reason why we have this–we prefer finishing incomplete tasks before starting new ones.

By providing both the need and the reason behind it, we are implicitly soliciting ideas from the reader. What approaches can you, the reader, think of to meet this need?

Generating more ideas gives us more opportunities to follow through with the one that provides the best return on investment.

Continuing with the example above:

1. Perhaps the author of the story was thinking we’d end up with a list of pinned tasks at the top of the page.
2. A team member on the project reads the goal and thinks of another solution: to send a morning email with a digest of incomplete tasks.
3. Because the software already has mechanisms for sending digest emails, but does not yet have a way to pin sections to the top of the page, the team realizes the digest option is one-fourth the cost of the pinned section.
4. Although the pinned section would provide a nicer experience, the team decides the return on investment is better with the email digest.

Good thing we described the goal and didn’t prescribe a solution. In this case, we got almost the same value at a quarter of the cost!

A Few More Examples

Here are a handful of other examples to consider:

• Poor: User can use a select box to pick a document version.
• Great: A reader may navigate to different document versions.
• Poor: There is a blue button to that starts the stopwatch ticking.
• Great: A user may begin tracking activity.

Conclusion

Authoring a strong goal section is difficult, but rewarding. If we’re too prescriptive, then we don’t get to hear the best ideas. If we’re too abstract, implementors don’t know where to start.

But it’s simply awesome when we hit the Goldilocks zone. Implementors understand what needs to be done and have a chance to discover an alternative path to success, and we optimize our return on investment.

Nice job!

This is the 3rd in a series on writing better Agile stories:

1. Breaking a UI into a Set of Features/Stories
2. Making Stories that Are Small & Meaningful
3. Setting Good Story Goals
4. Decision-Making Guidelines