HN Explorer

Generating realistic-looking stories in Pivotal Tracker (blog.carbonfive.com)

20 points by joncooper ↗ HN
A Ruby script to fill a Pivotal Tracker project with some reasonable looking stories.

This is useful for:

- Experimenting with workflows on a tracker other than your production one - Teaching clients how to use tracker without exposing another clients' stories - Learning to use Justin Smestad's pivotal-tracker gem

Cheers, Jon

10 comments

[ 5.1 ms ] story [ 29.0 ms ] thread
nupark2
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?

mwynholds
There's a pretty long answer to that question. User stories are a critical piece of XP (eXtreme Programming), and Tracker is a project management tool targeted directly at XP teams.

But you have to buy in to XP in order to see the value of User Stores or Tracker.

nupark2
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.

wpietri
In XP, every user story (often known as a "card", because XP teams often track them on index cards) is a token for a conversation.

So yes, you shouldn't sit down to write code until you think you know what you're building. But XP stories are generally in the range of a few hours to a couple days. And if you are in a typical XP team room [1], you are near colleagues. You will also likely be writing automated tests that document the change you are making. So a paper trail is rarely necessary; conversation generally suffices.

If you need to sketch or write something out to think about the problem, by all means do that. The XP teams I'm familiar with tend to do that by nabbing a couple of colleagues and working through things on a whiteboard that gets erased when a story is done. Some of them do make more permanent documentation if they're afraid of forgetting something. That might happen in code comments, in test comments, or in a project wiki.

[1] http://www.scissor.com/resources/teamroom/

apolzon
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. ;)

zalambar
I see Tracker as a prioritization tool first and a way to capture stories second. It is highly opinionated about and focused on prioritization but leaves the details of story writing and the conversations apolzon is looking for up to you.

I like this balance and aim for brief story titles with descriptions which include the "As a <role>, I want <goal/desire> so that <benefit>" style requirements, implementation concerns, and other acceptance criteria. I could certainly see a place for a more opinionated story writing tool though. Especially for team who struggle to produce actionable stories.

I also see a Tracker story as a placeholder for a conversation which needs to happen. Not as a good tool for mediating that conversation in the story comments and attachments.

atomical
At the startup I work at developers are either A) given the initiative or B) it's sorted out on the fly with input from different people on the team after the sprint meeting (or during). You might think this is a form of chaos but for a small team with talent it works incredibly well.
joncooper
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.

wpietri
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

apinstein
We used Pivotal Tracker for a long time (18+ months) on several large, internal projects and suffered from those same limitations. However, we kept using it because it has a very quick UX that updates concurrently with other users.

However as our team grew and we trained people on using Pivotal I was reminded of how much I hated the limitations of Tracker and how it's so hard to focus on a single story. It's just a touch too opinionated. From a management perspective it was also very hard to see what was going on across a large project with many sub-modules.

I went through every "web hook" integration in Github and tried every single project management tool, including JIRA. JIRA was so bad (slow and complicated) it was almost comical.

We ended up using Planbox, which is still story-oriented but solves pretty much every complaint I ever had about Tracker. The UX is extremely fast, handles concurrent users, supports per-task assignment, time estimation and tracking, and has single-story views that are much larger and easier to work with.

One of our devs also wrote up a git/CLI integration (https://github.com/ardell/git-planbox) that implements our branch naming scheme and provides a CLI interface to Planbox so that daily workflow can be done nearly entirely from the CLI. If you want it, he had also done a git/pivotal integration in the same vein (https://github.com/ardell/Git-Pivotal).