User stories aren’t a noun, they are a verb.

Two cheetahs sitting opposite each other in a field, appearing like they are having a conversation.
Two cheetahs sitting opposite each other in a field, appearing like they are having a conversation.
Want to hear a good story? It takes time, but we’re in no rush… | Photo by Yolande Conradie on Unsplash

In Part 1 we saw that reductionist User Story Templates of the form “as a user I want some action so that I can receive some benefit” both fails to adequately convey a deep understanding of the customer’s problem, and prematurely jumps to a solution. We proposed a set of long-form questions to ask in order to get a deeper, richer understanding of the underlying problem. We left the article postulating that it must be a lot of work to gather all the information required to answer such questions. (Spoiler: we were right!) Let’s continue…

A User Story is a Process, Not an Object

Such a detailed user story using the long-form questions that we proposed in Part 1 cannot be just created out of thin air — it would be full of assumptions…that are probably wrong! So in order to generate the information required, we need to have several conversations so that we can clarify the story details. …


Have you ever had that problem where someone hands you a terse User Story, and you think “I have no idea what that means?!” (Part 1 of 2)

Cat lying next to story books and yawning.
Cat lying next to story books and yawning.
In the mood for a good story? Photo by Dave Francis on Unsplash

Over the years, I’ve been on the receiving end of many terse User Stories, and I’ve often thought to myself “I have absolutely no idea what this means!” At first I thought that these User Stories were just poorly written. But as I saw more and more of them, I started to get the sense that maybe the User Story Template itself was the problem.

To recap, a typical User Story Template looks like this:

As a <type of user>, I want to <perform some task>, so that I can <achieve some goal>

A few examples might be:

  • “As a guitar player, I want to perform an amazing guitar solo, so that I can achieve fame and fortune.” …


The method you choose may be based more on your experience and skills than anything else.

Two kangaroos dancing in the field. Photo by David Clode on Unsplash
Two kangaroos dancing in the field. Photo by David Clode on Unsplash
Photo by David Clode on Unsplash

The choice between Agile, Lean and Design Thinking can be confusing. There are many articles that dive deep into the weeds of each, describing them in painstaking detail, but not giving much practical advice about which one to choose and when. This is not one of those articles. Instead, I want to look at the bigger picture to help you make a call on this common dilemma. To that end, I will not describe any of the three processes in great depth, but rather direct you to any of the many existing articles freely available.

With that said, let’s get stuck into the comparison. …


Do you ever feel like you’re going through the motions but it’s not actually making much difference?

Image for post
Image for post
Photo by Llanydd Lloyd on Unsplash

Recently, I was talking with my good friend Wil about going through the motions of Agile but not feeling like you’re making tangible progress. He raised the point that a common problem with Agile is that you can easily feel like you’re succeeding when you’re actually not. There’s a term for this: “success theater”…

Vanity Metrics and Success Theater

Vanity metrics are metrics that make you look good to others but do not help you understand your own performance in a way that informs future strategies.

The reason vanity metrics are so decried is that they’re overly simplistic to measure, they skip nuance and context, they are often misleading, and they don’t really help you improve in any meaningful way. …


Though they may sound similar, their differences can be profound

Image for post
Image for post
Sutyagin house, the quintessential Agile example.

In my previous article I wrote about iterations in Agile, and how they can be interpreted in different ways. Specifically, I rejected the frequently used “time-box” definition of iteration in favor of a multiple attempt approach where you iteratively work away at the same problem until you get its solution right:

In response, one of my readers Jessica Knight pointed out:

  1. “Iterative” vs “increment” was a great distinction to make.
  2. They may sound superficially similar but they underlie deep differences.
  3. A series of increments does not actually make you agile.

Actually, I didn’t actually think too deeply about the terms “iterative” and “increment” when I wrote the article, but it was a great insight! The more I thought about it, the more I realized she was…


In Agile, is incremental delivery the only thing that matters?

Image for post
Image for post
“The Thinker” photo by Andrew Horne (Wikimedia Commons)

“All the cool kids are doing Agile these days.” But if I probe a little deeper to ask what that means at a practical level, many people answer “we’re delivering our product in short iterative chunks.” I previously wrote an article about the delivery-focused benefits of this approach, stating that just focusing on delivery only doesn’t by itself guarantee that you will create an effective product that customers actually want to buy and use:

It struck me as odd that many teams rely solely on incremental delivery as their main interpretation of how to build software that customers would want to buy. But when customers don’t buy, or don’t like the product, often teams put up their hands in exasperation and exclaim “but we are following Agile!” Iterative and incremental delivery, either in discrete steps (Scrum) or continuously (Kanban), has become the cornerstone of Agile. For many organizations, it’s the only thing that matters. And this makes me wonder: how did incremental delivery become the defining element of Agile? …


Image for post
Image for post
Photo by Evan Dennis on Unsplash

Love the problem, not your solution

This quote is frequently cited in product management circles. And yet, as software developers we often look at Agile as a magic solution that will save us from all our woes (often without thinking too deeply about what those woes actually are and how Agile will allegedly fix them). Lately I’ve been thinking that if Agile is a solution, what is the problem that it solves? And is that actually our root problem or is it merely a placeholder?

So what are some of the problems that Agile solves? Problems typically associated with Waterfall, and often used to justify Agile…


Image for post
Image for post
Need another reminder of the current Sprint deadline? | Photo by Ahmad Ossayli on Unsplash

In a previous post I alluded to a dislike of fixed-sized sprints. I said that I would cover why in another article, which is what this post is about. But let’s start with what exactly a Sprint is. From the Scrum Guide (p9):

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

But having worked with fixed-length Sprints for a while, I’ve come to find them rigid and at times difficult to work with. …


Image for post
Image for post
Planning Poker anyone? Photo by Brett Jordan on Unsplash

After quite a bit of experience with story points, I’ve come to the conclusion that they’re largely useless. It has taken me quite a while to arrive at this position…

Decision Fatigue

Decision fatigue is a phenomenon where your ability to make high-quality decisions deteriorates after you’ve already made too many other decisions that day. Your ability to make good decisions tires a little bit more after each subsequent decision you make that day takes its toll on your mental capacity. You can read more about it on Wikipedia. …


An Agile board is conspicuous not only for what is on it, but also for what is left off.

Image for post
Image for post
Photo by Patrick Brinksma on Unsplash

Call it an Agile board or a Scrum board or a Kanban board — there’s a near-ubiquity of this grid of columns with tickets moving across them in engineering and development teams throughout the world. This simple table has been credited with “making work visible” and highlighting what the team is working on at any given moment. I call this the “light side” of the board — it serves as a beacon to show the tickets that people are currently attending to.

But let’s take a closer look at that board, more specifically its columns. The two most common board layouts are “To do/Doing/Done” or “To do/Dev/Test/Done”. Sometimes teams add another column for blocked, or one for integration. But the focus of the board is almost entirely things that we are currently building, i.e. …

About

Raj Nagappan

Founder & CEO, PhD, software engineer. Experimenting with new ideas to help craft better products that customers love. Connect at linkedin.com/in/rajnagappan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store