A Story Isn’t a Feature

Your business doesn’t want to hear about how you “delivered stories.”

Image source: AJC1, Flickr

The business wants you to deliver value, in the form of what they most likely refer to as features.

A story should trigger a conversation around a feature request. Your software product doesn’t contain stories, it contains features that help users accomplish goals.

Wikipedia describes a user story as “one or more sentences” that capture a user’s needs. Those sentences represent a brief description or summary based on the planning and preparation so far, and they are reminders of the conversation that you must continue to have around the feature you will build. The sentences are not the feature. They aren’t even the full story, in most cases, as it often takes the requester several more oral sentences or even paragraphs to say what they really want.

Why Does This Matter?

If you think about stories as a simplified form of a requirements document (“a couple sentences”), you’re constraining agile to be a small tweak to how you did things before, with a trendier name. That diminishes the most important aspect of how agile can help you deliver software successfully: Through continual collaboration and oral communication. Without understanding of the importance of collaboration, stories end up being another waterfall-like hand-off document.

On another front: Too many teams waste time over the wording of a story. It’s a discussion point, not an artifact. The “standard” story template should help you clarify feature requests by asking you to think about who needs them and why. But otherwise spending time on precise word-smithing of a story writeup misses the point. You’re going to discuss it, and you can iron out any ambiguities as you do.

Stories provide only minimal value as an artifact. The ensuing discussion is where the details come out. Unfortunately, most of us can’t fully recall details from a conversation a half year prior, or even a half month prior. Granted, the details end up embodied in the software, but source code more often than not does a poor job of expressing such details concisely and simply. Even programmers must sometimes spend hours to determine just what the code does for the smallest of features.

We need a better artifact than the few sentences that represent a story. Many successful teams have found that the best way to capture system behaviors is in the form of acceptance tests, best derived by use of acceptance test-driven development (ATDD) or BDD. The acceptance tests supplant the nebulous conversation with real meat. A test’s name describes the goal it accomplishes, and its narrative provides an example that quickly relates the details of system behavior. The set of test names describes the complete set of designed system behaviors. The tests capture the important detail behind the discussion triggered by the story.

A story is not a feature, and it should always trigger a conversation.

You Don’t Build Stories

I recently responded to a poster at JavaRanch who was asking about how stories are used in agile. I think a lot of people use the word “story” improperly–they use it in the sense that a story is a feature. “I built 10 stories into the product.” No, a story is a discussion around a feature. A story is also not a card.

While this may seem like a nit that I’m picking, I believe misuse of the word “story” has led to unfortunate insistences, such as rigid formats for cards that capture feature conversations (and I’m going to stop calling these cards “story cards,” which isn’t quite as bad a term, but it does help reinforce the wrong things).

(Most of the rest of this post is taken directly from the exchange on JavaRanch.)

“Story cards” are simply placeholders, or tools. The word “story” is the important thing here. A story is something we tell people; the card is simply a reminder, a summary of that oral storytelling. A card is a convenient medium. I suppose I’m thankful I don’t hear about “story whiteboards.”

Story cards (I tried… it’s not easy!) are not artifacts! Once you complete work on building a feature, the card is meaningless. You might think you could use it to track what had been done in a given iteration, but a 5-word summary of a several-day conversation (between customer and developers and other folks) scribbled on a card will not likely be meaningful to anyone six months down the road.

Instead, we get rid of the conversation piece, and replace it with something that documents how the system behaves once that new feature is in place. The best form for that document is a series of well-designed acceptance tests that anyone can easily read and understand. (See our Agile in a Flash card on Acceptance Test Design Principles for a definition of well-designed.)

Acceptance tests are the closest analogs to use cases (a tool popularized almost 20 years ago now), but with slightly differing granularities. The name of an acceptance test can map to the goal, or name, of a use case; it can also map to a much smaller slice of functionality. This is because features in agile are intended to be very small, taking only a day or so to complete. So someone might tell a story: “allow users to filter sort results by age.” That’s likely not an entire use case, it’s an alternate path on a larger use case.

Otherwise, the focus is the same: Jacobson said you could produce user guides and documentation from well-written use cases. The same can hold true for acceptance tests (with a little assembly work), which have the vastly superior quality of eternal accuracy: As long as all your acceptance tests pass, you know that they describe how the system works.

Stories, on the other hand, are just conversations, and the memory of all conversations eventually fades from memory. The cards act as great tools while the story is in progress–they help us track things and remind us what we were talking about, but other than that, we should just recycle the cards once we deliver the corresponding features.

Complete Stories, Not Iterations. Again.

No matter how hard I try, there’s always a hammer in my life. Sure, I try to use all those other new-fangled tools that are perhaps more appropriate to the problem, but I find that my hammer is a versatile tool that helps me bang my way out of many trouble spots. My recent agile hammer is “complete stories, not iterations.” In other words, collaborate! I’ve made a few blog posts and written at least one article on the topic.

Everything seems to keep coming back to this. A focus on completing stories as a team, and not moving on until the story is “done done,” tends to eliminate many of the questions that otherwise exist.

For example, “Should we create stories for defects?”

The glib answer is of course, “Well, if you’re doing agile properly, you don’t have defects.” But the more satisfying and less annoying answer is, “Well, if you’re collaborating to get stories completed, you don’t have many defects that survive the iteration.” If you can deliver a story every day or two through an iteration, the story can move into preliminary testing, and odds are that you’ll uncover many defects before the iteration completes. That means you can either fix them before the iteration completes, or you haven’t finished the story (it’s not “done done”), and the story is slotted wholesale into a subsequent iteration.

Voila. Concern over whether or not to create defect stories? Poof! (If you still have the question, the answer is “yes,” because they can be estimated, and because they take development effort that adds into team velocity.)

Task Tracking Is an Agile Smell

We’re looking at tools to help manage agile projects. This is a large, globally distributed enterprise, and that’s not going to change, so I suppose some sort of expensive tool is a necessary evil.

Many people are involved with reviewing the tools (which include things like Mingle, ScrumWorks, Agile on Demand, VersionOne, and eXPlainPMT). Everyone comes from a different perspective, of course, and I have nothing against how other people choose to work. But one request keeps coming up that bugs me: the insistence that the tool support the ability to do task tracking.

The desire to manage tasks in an agile process is evidence that a team is not collaborating. They are instead using silo-mode development: 1 story -> 1 developer. In lieu of tracking progress by marking off completed stories, they look at progress in terms of what tasks have been completed. May as well go back to waterfall.

It’s all about delivering the story. If you work in a collaborative mode that promotes this, there’s no need for tracking at the task level. (I’m not even going to mention the ludicrous idea that tasks ever outlive an iteration.)


couldn’t agree with you more. We use scrumworks and you assign a point person to a story/pbi.

Then you add or delete tasks as needed.

we went to a csm class with danube too. the trainer said “are you in the business of keeping people busy or producing product?” I think this is the point of your blog postings.

definitely agree.

Our VersionOne tool met both requirements for us. We could start with task tracking if absolutely necessary and turn off at any point in the future with the click of a single check box. We actually started with task tracking turned off and never looked back.

I don’t agree that task tracking is an evil. For example, we at TargetProcess use tasks as Definition of Done. We have tasks for each user story like Implementation, Create Acceptance Tests, Testing, Code Review, etc.

Definitely tool should make it possible to disable task tracking, but it brings value as well.

Note that I didn’t say “task tracking was evil.” It’s one way of working, and if it works for you, go for it. However, the better way is to structure things so task tracking becomes irrelevant. If you feel like you have to track tasks, your stories are probably taking too long to complete within the iteration.

Spread-out tasks are also a violation of lean principles.

I believe it is okay to make task tracking a requirement for tool selection since it is useful. I also understand where you are coming from that if the whole culture “requires” it, there might be a problem.

We use VersionOne because it handles both. We use task tracking heavily. As we work towards appropriately sized stories, we may need this less… but for now it helps us compensate for some other issues.

Stories and Code Quality

(See also Stories and the Tedium of Iteration Planning Meetings.)

Doling stories out to individual developers not only makes for more boring iteration planning meetings, but it also impacts the system’s overall quality.

One of the most overlooked practices in software development today is review. If you don’t pair, then you really must find a way to consistently review work product. Unfortunately, most companies pay the cost of not doing this: code that is increasingly more difficult to maintain, and solutions that are questionable at best.

Insisting that a team finish a story every couple of days or fewer will often mean that two or more developers must collaborate on a story. In order to collaborate, they must agree on some part of the design and a plan to implement it. The developers will need to continue talking as the implementation progresses. That’s a good thing. Much of the resulting design won’t be one developer’s wonderfully clever or woefully inadequate brainchild.

Such collaboration brings a bunch of siloed developers one step closer to being a true team. Initially, velocity will decrease a bit: developers will have to learn how to talk to each other and coordinate things. Developers will learn more about other parts of the system, increasing their value to the project as well as their personal worth. It’s not quite as good as pairing, but it does go to the heart of agile.

Stories and the Tedium of Iteration Planning Meetings

In “Tools, Iterations, and Stories,” I said you should “focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on.”

Then, in a blog post titled “Stories and the Tedium of Daily Standups,” I talked about how a focus on completing stories, not tasks and iterations, would make daily stand-ups interesting enough to bother with (anew–since many teams that initiate daily stand-ups often find them boring and thus slowly stop doing them).

There’s another important side-effect of organizing an iteration around incrementally completing stories: Iteration planning meetings are more interesting.

Implicitly, to be able to complete stories as an iteration progresses requires team members to actually collaborate on a story. Imagine that. It’s at the heart of the emphasis on continual communication in agile, yet many teams tend to miss this key point. In my next blog posting I’ll talk about the side-effect of improved quality. For now, I’ll restrict my thoughts to the impact of story planning on iteration planning meetings.

If an iteration planning covers four stories to be implemented by a team of four developers, there are two primary ways this meeting could go: 1) The customer details each story by focusing on each individual that will work it, or 2) The customer details all stories, discussing them with all four team members. The downside of option #2 is that it will probably take a little longer to work through all the stories. In fact, if you went with option #1, you really wouldn’t need a team meeting. The customer could just meet individually with each developer.

Effectively, what you have with option #1 is a meeting in which 3 out of 4 developers have little interest in the story discussion at any given point in time. Information about other developers’ stories is mental clutter, and consciously or subconsciously, each developer will tune out to some extent for 75% of the meeting. They will view iteration planning meetings as mostly a waste of time.

In contrast, option #2 requires everyone to be attentive. We all have to understand every story, and we most certainly have to start figuring out how each one breaks up. We probably need to do a little bit of design. People attending these sorts of iteration planning meetings are engaged. They leave the meeting with the impression that it held considerable value for them.

Stories and the Tedium of Daily Standups

In “Tools, Iterations, and Stories,” I talked about how you should “focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on.”

Today I helped deliver training on agile estimation and planning. One topic that arose was the daily stand up. We quickly surmised, no surprise, that this group’s experiences with daily standups were negative. We discussed some of the reasons why these meetings might be so poorly received. As typical, their standup meetings went on much longer than 5-10 minutes. Reasons? Also typical: people didn’t literally stand up, the meetings lacked focus, and people tried to use them to solve problems instead of just identify them. Most people, rightly so, viewed these meetings as very costly.

In response, we talked about why daily standups might be useful. We discussed the importance of getting the entire team to communicate more frequently. Daily should be a bare minimum!

The other part of our discussion was around what should be said during a standup. One of the complaints was that the standups were boring and tedious. The teams were using the typically recommended elements: what did I accomplish, what am I working on, what might I need help with? You know the drill.

Then it struck me: a focus on completing iterations, not stories, was part of the problem, contributing to the tedium.

The classic mistake in an initial stab at doing agile is to treat each iteration as a mini-waterfall. Spend a day discussing requirements, spend a day or two on design, code it, then test it, then integrate it. A team will open most of its stories on day one, and on the last day of the iteration, most of these same stories will still be open. The team will struggle to close them out prior to iteration end. The article I wrote (see link above) talks about a better approach: initiate work on one or two stories, and move on only after these stories are completed. That allows for incremental delivery of business value throughout the iteration, and usually minimizes the amount of work at risk for the iteration.

A team following the first approach, where an iteration is a mini-waterfall, will have very little useful information to say during a daily standup:

  • “What did you work on yesterday?”
  • “The flim flam widget.”
  • “Is it going ok?”
  • “Sure, I guess so.”
  • “What are you doing today?”
  • “Same thing as yesterday. Probably tomorrow, too.”

Zzzz. The daily standup is drudgery, because not much is changing, and none of the information is reliable anyway. When asked where they’re at, a developer uses the old 80/20 rule. Week one in a two-week iteration, they’re probably 20% done, and week two, they’re 80% done. And during week one, most developers have the confidence that they’ll be done in time, even if they’re stumbling. We won’t find out that there are real problems with their commitment until (too) late in week two.

In contrast, here’s how a standup might go in a team that looks to complete stories, not iterations:

  • “What did you work on yesterday?”
  • Joe: “I started on the frizzbang story.”
  • “That’s supposed to be done sometime today, right? Are you on target?”
  • “Well, maybe not, I’m stuck on a strange exception. I could use help from someone who’s worked in this area.”
  • Jane: “OK, well, I helped complete the flim flam widget by finishing the GUI component, so I’m available.”
  • “So the flim flam is ready for testing?”
  • “Yup. Today I’ll go work with Joe, before I start on the festivus tool.”

The more I do agile, the more I find that a primary focus on (really) completing stories is the best path to success.



I found out, that most of the time it happens this way, as people – who drive the stand-ups – create an impression what’s important and those who participate pick it up quickly and react according to the expectation. I have met few project managers, who are focused on delivering a real value, but instead are focused on detailed control.

But today I’ve heard one of the most stupid idea for daily stand-up. It was to divide the story into tasks and each day mark amount of percentage completed, so people could then present between each other their progress on daily stand-ups. This “thing” meant to focus people on completing their work.
Guess what ? The idea came out from the tool that draws the chart based on the amount of percentage completed.


When I was talking about this with a group of people yesterday, one woman asked, “Isn’t this going to make all that task level tracking we do difficult?” Apparently they are putting all the tasks (which to them were “analysis,” “design,” “coding,” … all to be handed off from one person to the next) into their tracking tool.

I suggested that perhaps they wouldn’t feel compelled to track at that level if they could all just work together on a story or two and get them delivered every couple of days or so.

I repeated myself. I’m not positive it sank in even the second time. We’ll see. I could smell some fear in the room.

The more I hear such stories the more I’m convinced there’s little trust in people and the focus is on a tasks/iterations not stories.