Generating realistic-looking stories in Pivotal Tracker

Sometimes I wonder if I'm the only one that can't stand Pivotal Tracker and agile project management "stories".

Pivotal Tracker de-emphasizes the things I think are most important:

* A clear, long-form description of the problem or requirements

* A long-form description of the likely solution or potential issues around the idea.

* A simple one-at-a-time view of a specific issue. If I'm working on a specific feature or bug, I don't want to see every other feature or bug sitting around.

Pivotal Tracker seems to push these things to the edges, and instead focus your attentoin on extremely small/quick/poorly-considered "story" entries, in a huge list of entries.

In contrast, I'm a huge fan of JIRA and Apple's (internal) Radar. Do I just not understand something critical about the agile project management approach?

Fair enough. Reading this:

http://en.wikipedia.org/wiki/User_story

I'm trying to get my head around "buying into XP". At what point do you describe the thing that you're about to build?

I don't believe huge requirements gathering phases, requirement documents, or any heavy weight processes are required. However, I don't know how an engineer can write code without at least being able to fully understand the problem, and then in english, explain the problem and propose a solution.

Often, I find just writing out the bug (and describing how I'm going to solve it) is enough to clarify in my own mind the correct solution. I could do that in my own head, but putting it on "paper" forces me to not skip any steps, and more importantly, provides a paper trail for future developers (or myself) in trying to understand my choices.

You're definitely not the only one.

I've seen a number of projects in Pivotal Tracker that would have been better off using almost any other form of task / roadmap management. Also, a number of successful projects using anything from "one smart person with it all in their head" to "200 index cards taped to the wall".

The most important thing to realize about tracker is that it isn't a process, it's a tool. You still need to develop and tune a process.

In particular, if your process is crap, or you put garbage into tracker, you will at best not improve the state of your project and at worst make it more annoying, slow and janky.

My concern with process and process tools is limited to optimizing the amount of stuff we get done cumulatively and sustainably over time.

Some tips on how to make tracker work for you:

* Figure out what size story works for your project.

* Write clear, descriptive stories with deterministic criteria to let you know when they're done.

* Encourage, honor and make time for folks to elaborate on stories (with possible solutions, constraints or issues).

* Refuse to estimate or start stories that are garbage.[1]

* Develop conventions around labels; they should have meaning.[2]

* If the team doesn't know enough about the problem to estimate a story, log and start a 1-point research story to figure it out in enough detail to write a story that isn't crap. Then fill in the details and estimate the other story.

Also, re: focus ("focus your attentoin ... in a huge list of entries.") -- that's a huge problem with tracker and the motivation behind the Chrome extension I'm working on. Even simple filtering by tag helps a huge amount.

There's a lot of stuff to say; perhaps I should write another post about this.

Jon

[1], re: "I don't know how an engineer can write code without at least being able to fully understand the problem, and then in english, explain the problem and propose a solution."

I don't either.

And if a story doesn't serve those needs, I don't consider it estimated or executable. If the person writing stories won't write good stories (time constraints, lack of interest, lack of communication skills) it's fine, but someone needs to flesh them out before they get estimated or executed on.

[2], re: story labels: I get a huge amount of leverage out of the following:

* blocked_{eng, ops, qa, art, ux, pm} - Cannot be started until someone from a specific team does something to unblock. Should have a task describing what is required to unblock.

* needs_elaboration - A polite way of saying "this doesn't make any sense and it can't be estimated until it does".

* needs_estimation - This task can be estimated and then started.

Tracker is what's known as an opinionated tool; it's very tuned for a particular way of working. They made the tool for internal/client use, and then opened it to the public.

If you look at a picture of their office [1] or their description of how they work, you can see it's very iterative and very collaborative. In that kind of environment, detailed written descriptions are seen as wasteful. That doesn't mean things are poorly considered, just that they do it in person and in a just-in-time fashion.

[1] http://www.flickr.com/photos/thewoolleyman/2996297029/in/poo... [2] http://pivotallabs.com/how/working_with_us

The piece thats missing for me with tracker is the conversation. As atomical points out, there are times where you want the story to have some vaguer requirements to allow it to breathe and evolve on its own. During times like these, it grows through the conversation and chair-spin between developers, product owners, etc.

On tracker, the comments system is abysmal, so you either end up with a long unreadable conversation (god forbid there be more than 2 people discussing something at once -- thats a nightmare) that noone wants to read, and thus the curated requirements for the story are missing and would take 30-45 minutes to find. OR the comments system is abandoned, and you lose the ability to "track" this part of the process. Epic lose.

Can't wait to see jcooper's work-of-art chrome extension. ;)