Information Density and Project Tracking

May 29, 2008

One complaint that I hear from people who don’t like a given project tracking tool is that there is actually too much information on the screen at once. They find it distracting and it makes it hard to find the really relevant information. In response, usually I nod my head sagely, mumble something obscure, and move on.

But when I give my talk on the pros and cons of using physical vs. electronic project tracking tools I neglect to mention this difference. If I stop for a minute and take a good hard look at the task board our team is using right now, it doesn’t say a whole lot compared to the electronic tools we use. For one thing, the team and I keep a pretty sloppy task board. Stuff gets crossed out, notes are written in the margins, extra stickies are tacked on top of other stickies. We know what it all means, mostly, but I’m not sure that anyone else could easily parse it all out. There’s a lot written between the lines in both a literal and metaphorical sense.

On the other hand if I use my electronic tools, they pretty much force me into a much more orderly state. There is a lot of explicit information displayed – it takes a while to setup. But it’s neat and orderly. If I need to make notes, then I can put something in the “notes” field. Unfortunately the notes field is not normally displayed. I have to “open” a story to view the notes. Information is cleverly hidden. Like I said, it’s neat, it’s tidy, there is lots of information, but some parts are hidden.

Hmmm…Of course there is hidden information in my physical task board too. I have a confession to make: As a team, we’re pretty lazy – and proud of it. We’re firm believers in helping our environment by practicing the conservation of syllables. Why use two words when one will do? Mike Cohn said it best, The user story is a placeholder for a conversation. Amen brother! It’s remarkable how much we can read into so few words!

So both types of tools have their own forms of information density. And they both have different types of data that is “hidden”. Of course, I have more control over the physical taskboard than the electronic one. I’m pretty much forced to display certain data using electronic tools – even if it isn’t necessarily relevant to me. That’s probably where the information density argument comes in. I don’t mind information density if it is exactly the information that I want to see. However, if it’s not relevant to me, then it only serves as a visual impediment.

Something to keep in mind the next time you are tool shopping.

Tom’s Catalog of User Story Smells

December 20, 2007

Here are a few smells I’ve encountered while working with user stories with different customers:

  1. One word stories
  2. Technical stories
  3. Stories missing goal
  4. Stories missing user role
  5. Stories specifying architecture
  6. Customer doesn’t understand stories
  7. Boring stories
  8. Too many stories

For each story there is a symptom and a related discussion of the problem:

One word stories

Symptom: Stories are just single words jotted on a card with no description or explanation associated with them.

Discussion: Although stories are “Intended to be a placeholder for a conversation” it is possible to stretch that notion too far. It’s easy to see how a product owner might think that they have a mutual understanding of the issue with the team – so much so, that they neglect to describe the story sufficiently. However, it’s critical that the story provide some simple context, some simple statement of action. A disciplined team sticks to the format: As a <user> I want to <do something> so that <I can accomplish goal>.

Single word stories can also be an indication that the team is writing the stories for the product owner.

Technical stories

Symptom: The story is written in completely technical terms that have no meaning for the customer or the business domain.

Discussion: This is probably the most common problem with user stories. Technical stories that refer to layers of architecture, or specific technologies are completely opaque to the customer. The customer finds it hard to understand the value of the activities if they are not written in business terms. If you go to a review meeting, ask the customer/PO to accept the story and they say, “I don’t know what that means.” Then you have a technical story.

Technical stories are also an indication of another smell: Customer won’t write and prioritize stories. As a result, the team ends up writing stories that make sense to them – technical stories.

Stories missing goal

Symptom: Stories contain user role and feature, but there is no explanation of why the user would want it.

Discussion: Incomplete stories of this type are quite common. The goal is what can provide context for the rest of the story. Often the goal is an expression of the value the feature has to the user. Often an inexperience product owner will neglect to put the goal in a user story.

Stories missing user role

Symptom: Story contains a description of the desired feature without a reference to the user role.

Discussion: Without knowing who the customer is, it makes it very difficult to understand the value a feature may have – furthermore, it’s almost impossible to assess the fitness of the feature to the user.

Stories specifying architecture

Symptom: The story contains references to architectural design or components.

Discussion: This is simply another version of a technical story. This comes up most often when there is a dedicated architecture team.

Customer doesn’t understand stories

Symptom: Customer/PO doesn’t recognize or understand stories

Discussion: It’s likely they didn’t participate in writing the stories.

Boring stories

Symptom: Stories sound stilted and without passion.

Discussion: This could just be that the stories aren’t well written and need to be refactored a bit. Another problem may be that the goal is not particularly compelling. Is this story prioritized correctly?

Too many stories

Symptom: The total number of stories in the product backlog has grown to literally 200, 300, 400 stories or more.

Discussion: This is waste. The team will very likely never get to those stories. When the backlog gets this large it’s time to prune it down to a more reasonable size.

Passionate User Stories

November 28, 2007

Tired of writing the same old user stories the exact same way every single time? Are you losing a little bit of the agile spring in your step? Recently I found myself feeling just this way. I was reviewing the stories for an upcoming agile project and feeling remarkably unenthusiastic about getting started. What was the matter? The project had clearly written stories. The objectives were reasonably clear. Why wasn’t I excited about taking this project on? I realized it was because there seemed to be no life in the stories themselves. This wasn’t the first time I’d encountered this. The question before me was, “How can I breathe a little passion back into the stories that I work on?”

By now, many of us are familiar with what good user stories are supposed to look like. I learned how to write them from Mike Cohn’s book, “User Stories Applied”. The format he introduced looks something like this:

As a <role>
I want <function>
So that I can <business goal>

I have a confession to make – sometimes writing stories in this format leaves me completely cold. Seeing that same format repeatedly tends to drive me nuts. It can be a lot of extra work to put stories into this format.

Putting a little Passion Back into Your Stories…

Sometimes I get lazy and I just give up and create a one-word story. Here is an example of one of my one-word stories:


OK, so it’s a little opaque. I know what it means. Nobody else will understand this story, but who cares? A story is just a placeholder for a conversation, right? Well, having lived with one-word stories I find that they suffer from the following problems:

  1. I tend to forget what the context was
  2. The verbs are often missing – what am I trying to do?
  3. They don’t really motivate me

Let’s take my example above – mentoring. What did I mean by that? Is it mentoring for me? Mentoring for someone else? Perhaps a mentoring program? Maybe I meant all of the above? Without some sort of context, there is no way to know what this “story” was all about.

I like having an action verb in a story. Anything will do: provide, obtain, receive, implement, create. Put any of these words in front of “Mentoring” and you automatically get a little more context in the story. Obtain a mentor. Provide a mentor. Receive mentorship. Suddenly I have a much clearer picture of what the story is all about. So here we go:

Obtain a mentor

Of course, “obtain a mentor” doesn’t exactly light the fire in my belly. Boring! I feel sort of like, “OK, I’ll do it – if I really have to…”

How do we fix these stories?

We could go ahead and use the format that I was avoiding from the start:

As a project manager
I want
a mentor
So that
I can be more successful on my next project.

That’s not bad – it’s a distinct improvement really. Now I know the context pretty well. I know the who, what, and why. Not too bad at all. Nevertheless, it’s still not setting my shorts on fire.

How about adding some adjectives? Let’s give that a shot and see what happens. We have to ask ourselves a few questions first. Let’s start simple:

What kind of mentor are we looking for? I want a great mentor. OK, let’s crack open the thesaurus and see what we can find…
Great, Inspired, commanding, distinguished, dominant, excellent, enthusiastic – hey! I think we have a winner – enthusiastic. I like the sound of that. I want an enthusiastic mentor! Let’s re-write our story again:

I want an enthusiastic mentor

Who will help me be successful on my next project.

Hmmm… I am definitely starting to like this story. I dropped the “as a” phrase because it was redundant – we’re just talking about me. Furthermore, I changed “so that” to “Who will help”. It just seems to flow more naturally and better convey the meaning of what I am trying to do. Not only do I know that I need a mentor, but now I know what kind of mentor I’m looking for. This story is getting better as we build it up word by word. After all, when we only have a sentence to describe what we want, every word counts.

I wonder if I can improve this story still further? How about a trip back to our friend the thesaurus? Let’s see: successful, flourishing, dominant, leading, noteworthy, smashing, stunning – oooh, there’s a good one!

I want an enthusiastic mentor

Who will help me make my next project a stunning success!

YES! Now that’s a story I can get behind! That lights my fire! That’s a story that I want to deliver. Remember, one of the keys to successful agile development is to have audacious goals. I feel like we miss the opportunity for a little audacity in our lives when we cop out on writing good stories. Stories should be something that the customer is passionate about. They should be something that the team should be able to get passionate about. It’s hard to get passionate about single word stories. Even the standard story form is a bit bleak.

Of course, this story still has a weakness – it’s not testable! I need to define what I mean by a “stunning success”. How am I going to define success? Let’s try this on for size:

I want an enthusiastic mentor

Who will help me make my next project a stunning success

by doubling the project revenue!

Aha! Bring it all back to money! Nice! Now we have a compelling AND testable story. Sign me up!

Now let’s try this technique with another story. Maybe something that feels a bit more like a real customer request. How about this:

Prioritize Tasks

So I have a list of tasks and I want to prioritize them. Let’s play with it and see where we end up:

I want a quick and intuitive way to prioritize tasks

So that I can maximize the productivity of those who use this tool

You’ll notice that I’ve taken some artistic license in interpreting the words that apply to these stories. The simple act of looking for different ways to describe something using a thesaurus brings up all sorts of interesting related ideas. We don’t have to settle for the most spartan explanation possible.

Here is my theory: If we invest some time, and perhaps just a little imagination, we can transform our stories into something that is really worth doing. Take a few adjectives and put the passion back into your work! I guarantee you that the time will be well spent. Be audacious! Be passionate! Have fun!