Iteration 32: Pivotal import, mug-shots, and links to related cards

This is the first in a series of fortnightly retrospectives that I'll be writing about building Agile Planner. Each post will compare what I hoped to achieve at the start of an iteration with where I actually managed to get to two weeks later.

I'll also give a brief write up of any new features I've implemented each fortnight, and share any useful lessons that I've learned along the way.

New features

I've shipped more new features during this iteration than in any other iteration this year.

You can now:

• Import projects and stories from Pivotal Tracker.
• Show your mug-shot (avatar) on cards that you "own".
• Create links to other cards that you mention by number
  (e.g. "card 42" or "#42").
• Highlight completed cards on the planning page.

I found time to squeeze in a couple of bug fixes and performance improvements too, incentivised by the import of one of the world's largest publicly visible Pivotal Tracker projects. :-)

On top of all that, I added support for commenting on cards. People clearly need to be able to communicate with each other to discuss the finer points of a story, and they might not all be in the same room when questions arise. It makes sense that conversation can happen online, close to the stories themselves.

If you've had the chance to talk to me about the problems I want to solve with Agile Planner, you'll probably know that I've got reservations about commenting on stories. It bothers me that comments on a story (in apps like Pivotal) often serve as the only record of what really needs to be done. The description of a story (the bit at the top of the page, that should describe why the story exists) sometimes doesn't get enough thought put into it. The team then clarifies the intent in the comments, and fails to go back and update the description.

Developers who later work on the story are left to scan through a long list of comments to try and work out which problem they're really meant to be solving. It's a terrible way to capture requirements and wastes a lot of time. And yet, I'd decided to support commenting on cards so that I could import comments on the Pivotal project I mentioned earlier.

I built a commenting system. It works. It even looks nice. But just before I deployed the code, I changed my mind and decided not to ship it.

Comments feel like the wrong model. I think the problem can largely be solved with better UI - I've had a far better idea which will probably get a mention in next iteration's blog post.

So all in all this iteration was something of a blinder. I'll explain the changes that actually got shipped in a bit more detail...

Importing from Pivotal Tracker

There's nothing flashy to show you here (and no user interface for it) as the import runs in a background job. I will be adding some UI before launch so that you'll be able to import Pivotal projects yourself.

Import doesn't have to be a one-shot thing; we can re-run it regularly (and automatically) to pull your latest changes in Pivotal into Agile Planner.

Showing your face

You might have seen the design for this on the home page. Basically, we show your avatar (retrieved from gravatar.com) in the corner of any cards that you're currently working on.

At the moment avatars only show up on cards that have been imported from Pivotal, as there's no user interface for claiming cards from within Agile Planner. I'll be rectifying this problem shortly...

Linking to other cards

I often find myself referring to several other cards when I'm writing stories, or making notes for future reference. The kind of thing I'll write is "Depends on #248", "See card 32" or even (in the Notes field) "There's an interesting alternative approach to this discussed in card 482...".

When reading notes like that you don't want to go and find the card by hand. Nor should you have to sift through all the text on a card to find out whether or not it links to any other cards. It's far more useful to let Agile Planner tell you which cards link to this one, or which cards refer to the card you're currently reading.

The links are updated automatically (by analysing what you've written) every time you save a card. It's one of my favourite features, and though a small thing that many would argue should have waited until after launch I've been dying to use it since I had the idea.

Highlighting completed cards

When you're looking at the Kanban board it's obvious which cards are finished (they're in the right-most column).

On the planning page (where you can drag cards between the backlog and the current iteration) you can't see the columns, but it's still useful to know which cards have already been done.

I wanted a subtle way of indicating which cards had made it all the way across the Kanban board. Of all the designs I tried, my favourite was this pale "COMPLETE" stamp across the middle of the relevant cards.

The stamps are a great help when setting priorities part-way through the iteration (by re-ordering the cards), and makes moving a card into that final column even more satisfying.

Retrospective

This was one of those iterations where it made sense to throw my plan out of the window three days after I'd made it...

But we're agile, right? We embrace change. ;-)

The original plan

My main focus for the fortnight was to make Agile Planner more useful prior to "launch". I've been happily using Agile Planner to manage my development work for around 18 months now (as have a small band of beta testers), but we're lacking a few features that are important for teams larger than 2-3 people. These features are holding up the launch.

I also felt it was time to start sharing some of the lessons I've learned while bootstrapping a startup. Over the last few years I've collected daily data showing how much time I've spent working on my bootstrapped startup ideas, and on paid freelance work for clients.

I've experimented with both:

• Freelancing part time while my startup is my side project, and
• Contracting full time for a few months, saving up enough cash to pay for a focussed stint on my own products.

The data I've collected should shed light on which approach is most effective. Which works is best for me might not suit everybody, but I'm sure it'll make for interesting reading. So I set some time aside to research and write an in depth article.

The reality

Three days into the iteration, my plan was turned upside down.

I heard on the grapevine that a team that's interested in Agile Planner were considering switching from Pivotal Tracker to Trello. They currently work in iterations, estimate their stories, and keep a weather eye on their velocity.

The last time I met with them they loved the insight into their progress that Agile Planner's Kanban board could give them. I'd love to have them on board, so I agreed to automate the import of their Pivotal project.

The problem was, I hadn't yet written any code to load their data from Pivotal's API. If the team were considering moving to Trello (where they'd lose estimates and velocity tracking), now was clearly the right time to import their data.

I decided to strike while the iron was hot.

I threw out my iteration plan and made a new one, keeping half my cards and making room for a fairly large story. The blog post on dividing time between freelancing and bootstrapping was a big story, and had to go.

Once I'd written the code to import Pivotal's iterations and stories I had an opportunity to see how Agile Planner performs with an enormous project (this team has ploughed through over 3,000 stories, and counting). It held up well, but with around 60 cards in an iteration it made it quite clear how important it is to be able to see who's working on a story.

Adding the avatars to show what people were working on was a quick job, and it looks great. I shuffled my plan around a bit more and made room for it.

Lessons learnt

This iteration has been a great reminder of how much you can get done when under slight (external) pressure to deliver, and you're motivated to achieve it. At the start of the iteration I re-read my post on how working towards a goal can increase productivity, and made a note of this quote from Bruce Upbin:

We shouldn’t be so overwhelmed that we break down and give up, but we also shouldn’t be coasting either. … He kept tuning the difficulty level of the class to stretch but not break us.

Even before I changed the plan I'd set myself a target that I knew would stretch me, but I thought I could do it. Having thrown that plan away I'll never know if I could have made it, but it doesn't matter. I'm very pleased with what I've achieved this iteration, which is very motivating in itself.

I've no idea yet whether the team whose Pivotal stories I imported will decide to try Agile Planner in anger, but they've helped enormously just by considering it.

I was originally going to implement a fairly nuts and bolts approach to putting avatars on cards. I wanted to show multiple avatars on each card (to support pair programming properly), and planned on building the user interface to support it from the outset. It's more complicated to build than the simple one-person-per-card approach, and I hadn't realised that the majority of the benefit is to be had with a single user approach that can be implemented quickly.

If you've previously been clammering to be able to put your avatar on cards that you're working on, watch this space. It's close!

And what of all the time I spent building a commenting system that I'll probably never deploy? I don't feel bad about it at all. I've just read a perfectly timed blog post from 37signals about some advice they received from Jeff Bezos (the founder of Amazon). It contains this quote:

It’s perfectly healthy — encouraged, even — to have an idea tomorrow that contradicted your idea today.

[Jeff Bezos] observed that the smartest people are constantly revising their understanding, reconsidering a problem they thought they’d already solved. They’re open to new points of view, new information, new ideas, contradictions, and challenges to their own way of thinking.

If I hadn't built a commenting system I wouldn't have been so reluctant to deploy it. That reluctance made me dig a little deeper for a better solution, which came to me in a flash of inspiration as my fingers were typing the command to deploy the code. Phew. Bullet dodged.