blog.carbonfive.com
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
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?
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.
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).
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
But you have to buy in to XP in order to see the value of User Stores or Tracker.
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.
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. ;)
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.
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.