Agile Planner

Iteration 48: Better support for Kanban and hashtags

2022-09-03T18:00:00+01:00

The main goal of iteration 48 was to build on the (recently added) tagging features. Planner has also become significantly easy to use for teams that are adopting Kanban's "continuous flow" approach (rather than using sprints or iterations).

Better support for hashtags

Planner lets you use #hashtags to organise your story cards. They're easy to use; to create a tag you just type a "#" character, followed by a word, and save your card. Planner will convert the tag into a link, so you can see all other cards that are using the same tag.

The only problem was remembering which tags you were using, or how you'd spelt them. To deal with this, Planner now suggests tags that are in use on the current board.

The most used tags appear at the top of the list. As you start typing the suggestions are filtered to show those that match what you've typed.

Support for "continuous flow"

Planner is, first and foremost, designed for teams that practice "iterative development". It expects that:

You like working in iterations (or sprints) of 1, 2, 3 or 4 weeks in length.
You'll take stock of how things are going every iteration, review your business's priorities, and choose the most valuable things to work on in your next iteration.

Beyond that, Planner doesn't really have an opinion on how you work. Your process should be for you to change, improve, and experiment with.

Back in the early days of Agile (when Extreme Programming and Scrum became popular) it was common for teams to wait until the end of an iteration before releasing any of the work that they'd completed during the iteration.

Only the stories that made it into the release were considered to be complete, and the corresponding estimates were added up to calculate the velocity for that iteration.

These days many of us are able to release our work continually (as we complete it), rather than in one lump at the end of an iteration. It's also fairly common for stories to be partially developed, or be awaiting review from stakeholders at the end of an iteration, and nobody loses any sleep over it.

At the end of every iteration Planner prompts you to "close" the iteration. You get to make sure that all the cards are in the right columns before the stories that you've finished will be moved to the History page.

The big question is, what should happen to stories thare are still in progress?

Usually, you'll want to finish a partially complete story during the next iteration. But not always.

When choosing which cards belong in your next iteration, Planner has always moved your unfinished cards back to your Backlog, prompting you to drag them into your next iteration.

Having to drag these cards around may seem like a pain (by comparison to automatically moving them to your next iteration), but it prompts you to reconsider whether each card is still a top priority. Priorities can change on a daily basis, so this is usually a useful (and quick) exercise.

However, if you're using Planner to manage a team using "continuous flow", you'll usually have a lot of cards that are unfinished. And you'll still need to close an iteration every week/fortnight, even if you're not really working in iterations (closing an iteration is the only way to move your completed cards over to the History page).

So if you're using Planner with continuous flow, what you really need is a way to move all the completed cards to the history page, while leaving any work that's in progress in the current iteration.

So now you can choose what happens to your unfinished cards. This is what you'll see when you click the "Close" link:

If you're using iterations or sprints, you can choose where to put your unfinished cards. If you're using continuous flow, select "Move them to the next iteration".

Retrospective

This iteration felt good. I got a lot done (including a few small features that I didn't explain above), all of which was in response to customer feedback.

Planner is shaping up nicely. :-)

Add tasks to your story cards

2015-04-22T00:00:00+00:00

Planner now lets you add tasks to your story cards.

Tasks are written as bulleted lists in each card's Notes & Tasks area, by prefixing the text of the bullet with [ ] and [x] (followed by a space). The “x” indicates that the task has been completed.

Clicking a task's checkbox adds the "x" for you and saves the card (as you can see in the animation above).

Because your tasks are written in plain text, you can:

Write them very quickly, editing and refactoring the list as your plan evolves.
Break long lists up into multiple lists, just by inserting a paragraph or heading in the middle of the list.

I often make one list for a story's development tasks, and a separate "deployment checklist" just beneath it.

How this approach came about

When thinking about how to build a new feature, I find that breaking the problem down into tasks is a very useful exercise. Unfortunately it's not something that I usually get right first time, so I like to iterate on my task lists as I write them.

Back in 2002 (when I worked in a team that used real index cards) we'd keep notes about our stories in a Wiki (the notes wouldn't fit on the cards themselves).

We used to keep track of tasks by writing bulleted lists on the story's Wiki page, indicating which ones we'd finished by writing “[DONE]” at the beginning of each bullet. It was basic, but it worked well.

We could edit, delete and re-order tasks quickly (with the keyboard). It made writing detailed task lists a breeze.

If you estimate your stories, you've probably noticed that breaking stories down into tasks helps you make more consistent estimates. Back in 2002, our plans (with estimates based on the tasks we'd captured on our Wiki pages) became very consistent.

When designing Planner I wanted to maintain a Wiki's freeform approach to writing and editing tasks, but realised that people would appreciate being able to mark a task as complete by clicking a checkbox.

I evolved my “[DONE]” indicator into the “[ ]” and “[x]” syntax that you can see above, with the intention of converting them into clickable checkboxes.

I was excited the idea, but at the time I knew I had higher priorities to work on. By the time I came to implement it GitHub had added support for exactly the same syntax. That's always a sign that you're onto a good thing. :-)

So not only is it a great way to work with task lists, you can use the same approach in multiple apps. Better still, if you'd like to add support for this approach to another app, GitHub have released their code as open source.

A new approach to tags

2015-04-07T00:00:00+00:00

For some time now, Planner has allowed you to organise your story cards by tagging them with hashtags.

We chose to use hashtags because they’d help us to keep Planner’s user interface clean and simple, and for the most part they worked well. It’s become clear that hashtags have their limitations, so we’ve replaced them with a more typical tagging interface.

What’s wrong with hashtags?

When tagging your stories with hashtags, they encourage you to include the tags in the description of your story. Here’s an example:

It works very nicely when you first write your card, but what happens when we want to rename a tag? We might have written a story like this:

It’s difficult to understand what the cards in your backlog represent at a glance. Allow people to #filter the cards in the backlog by typing a snippet of text that matches their stories’ title or content.

If we later decided that we wanted to rename the #filter tag to #backlog-management, Planner would need to edit our story text. Unfortunately “Allow project managers to #backlog-management the cards…” doesn’t make any sense!

So you can’t automatically rename hashtags.

The new approach

It’s very simple. There’s a new “Add tags…” link beneath each story card. Click it to add a tag.

Existing tags are shown as labels, each of which has a small button you can click to remove the tag from the card:

Clicking the tag’s name will show you all the cards that use the tag.

That’s it!

Assigning other people to cards

2015-03-19T00:00:00+00:00

When using Planner you can show people which cards you’re working on by adding your avatar to your cards. The intention is to make it easy to see at a glance what people are currently doing.

Here’s an example, taken from a publicly visible board used by one of Planner's beta testers:

When I first added support for avatars, I didn’t think there’d be any need to be able to add or remove other people. Feedback from beta testers has made it very clear that this isn’t the case, so I’ve just released support for adding/removing your teammates.

This quick animation will give you a good feel for how it works:

Note that Planner doesn’t email people when you add them to a card. At first glance sending an email might sound like a good idea, but it’s very easy to abuse a tool that allows it. I’ve worked in plenty of places where managers like to “assign” work to people, without getting their team’s input on who would be most suitable for each task.

Every time I’ve witnessed people being “managed” in this way it’s affected team morale. So if you’d like somebody to work on something, it’s far better to start a conversation and get a consensus. With Planner that means you’ll just have to walk over and have a chat, pick up the phone, or drop into your online chat room instead. Just like you would if you were using a physical card wall…

Suggesting tags as you type

2014-09-03T00:00:00+00:00

Planner lets you keep your stories organised with #hashtags. It can be hard to remember all the tags that your team is using, but Planner can know remind you which tags are in use, suggesting tags as you type.

The easiest way to show you how it works is with a quick demo...

Iteration 47: Reprioritising cards on the Kanban board

2014-08-20T00:00:00+00:00

The development team (me) was a bit light on resource this fortnight, as I've been getting ready to move house!

The vast majority of my time (when I wasn't packing boxes) was spent fixing bugs, but (in response to a customer's request) I did ship one new feature – Planner's Markdown now supports tabular data. You can find out more on the Markdown help page.

Bug fixes

I like to fix bugs quickly, soon after they're discovered. Letting your bugs pile up can:

Give customers the impression that your app isn't a high quality product.
Require you to spend (waste) time explaining to your customers why things didn't quite work as they expected.
Depress your team – nobody likes having a bunch of unfixed bugs filed against their code, or spending the day "bug fixing".

I fixed a few minor bugs this iteration, and one big one.

Planner had been confusing a small number of people for a few weeks, but I hadn't felt able to prioritise the fix.

For reasons that I probably shouldn't go into (it's hard to explain, and not particularly interesting) the only place you could prioritise your cards was on the Planning page.

On the Planning page cards are laid out in a grid, with the highest priority card at the top left, the lowest at the bottom right. By picking a card up and dragging it to a new position in the grid, you could reprioritise it.

When you viewed the same cards on the Current Iteration page (which arranges the cards in columns - "To Do", "In Progress", etc) you could drag them between the columns. It also seemed as though you could re-prioritise cards by dragging them up and down within their columns.

For complicated technical reasons, you couldn't. Worse still, it had never occurred to me that people would actually want to do it (I always re-order my cards on the Planning page). I was blissfully unaware that people expected it to work.

It seems so obvious now, but this is why usability testing is so important. As designers and developers we don't think about our products in quite the same way that our customers do.

Unfortunately, solving it properly (I didn't want to hack something together quickly) was a big job. This meant I had to prioritise it accordingly – fixing it would delay the arrival of some important new features.

This iteration, I set aside the time to fix it.

Retrospective

I didn't deliver that much this fortnight, partly due to my impending house move, and partly due to some unexpected complexity in this bug fix.

My velocity was 1.75. To put that in context, I've had an average velocity of 3 over the three previous iterations.

Iteration 46: Real-time updates and performance improvements

2014-07-23T16:30:00+01:00

One of the benefits of working with a physical card wall is that you know that your wall is an authorative version of your plan, and an accurate reflection of the team's progress.

This isn't necessarily the case if your card wall is on a web page. When somebody moves a card on their screen, anybody who has the same page open will be looking at an outdated plan. You often need to reload the web page to see the latest version.

Some of the teams using Planner have more than ten people working on a single board. With that many people on a board, significant changes can occur every quarter of an hour. Making decisions based on out of date web pages was starting to cause them problems.

The focus of iteration 46 was to fix it.

Notifications explain what's changed

The ideal solution would be to update everybody's boards in real time, replicating drag/drop events across all active browsers. Everybody's card wall would be kept up to date. It would have taken longer to write the code to do that than was available in the iteration, and we realised we could get most of the benefit for half the effort (the credit for spotting this goes to @tekin).

The big problem wasn't that people had to reload a web page; it was that they didn't know when they needed to reload a web page.

Next time you leave your browser open on the Current Iteration page you'll see a message like this one when somebody moves a card:

This is just an example, but it isn't the only message you might see – Planner will also tell you if somebody edits a card while you're looking at it.

In future I expect we'll be moving cards around before your eyes, as your teammates update your board.

Performance improvements

When considering how to implement real-time updates, I had a choice between two competing technologies:

Server Side Events (SSE), an HTML5 technology that allows the server to send data to the browser over the existing HTTP connection, and
Websockets, which support two-way communication between the server and the browser on a separate network port.

After a bit of research I decided to use SSE, as it looked like the simpler of the two options.

In order to be able to use SSE I needed to upgrade Planner to a newer version of Ruby and Rails (the programming language and framework that Planner is written in). I'd been wanting to upgrade for a while, but had prioritised new features instead. This was a perfect opportunity to do it.

Much to my surprise, the Ruby upgrade lead to a three-fold decrease in the time taken to serve its web pages. Requests that had been routinely taking over 300ms were now getting served in less than 100ms.

Retrospective

Shortly after I'd upgraded Ruby and Rails (so I could implement the notifications using SSE) I discovered that Rails isn't well suited to serving SSE at scale.

The Rails developers amongst you may now be saying "WAT?! He's said Rails doesn't scale!" I'll briefly explain what I'm saying. It's specifically about SSE, in Rails, running in a typical server environment. As currently implemented (Rails 4.x), SSE requires a threaded web server, and one active server thread for each user who keeps your app open in their browser. The thread is responsible for pushing data over an HTTP connection, and needs to maintain an open connection to your database.

If you're hosting your app in the cloud, a large number of concurrent database connections can become quite costly. I suspect that to make SSE a sensible approach we'd need threadsafe access to the database (which I expect will arrive in Rails before too long, for this very reason).

If you have a similar need for SSE and are hosting in the cloud, I'd recommend that you just use Websockets, and let Pusher (a hosted Websocket platform) deal with the complicated bits. Pusher turned out to be simpler to integrate into Planner than SSE anyway, as I didn't need to switch to a multi-threaded web server or setup an event bus to broadcast messages between threads.

So as it turned out I upgraded Ruby and Rails so I could use SSE, then switched to Websockets, and needn't have upgraded anything at all. Happily, the unexpected performance improvements alone have made the upgrade worth it.

Though it all turned out well, I dropped the ball here. I should have investigated SSE more thoroughly before committing so much time to the upgrade (which took several days).

I'll have to keep a closer eye on myself. I'm a loose cannon…

Iteration 45: Tagging and searching

2014-07-08T22:00:00+00:00

The main focus this iteration was on tagging and grouping of cards. We've also done some more work on search, and improved the way that discussions are displayed on the card page.

A search results page

Back in iteration 43, Planner gained early support for searching for cards. When you type some words into the search form Planner suggests up to ten cards that match your query. You can select a card with your cursor keys, press enter, and jump to the card.

That's not new, but what if there are more than ten cards that match your query? And what if you want to share the results with somebody else?

If you type a query and press Enter (rather than using the cursor keys to navigate to one of the suggestions) Planner will now show you all the cards that match (sorted by how well each card matches your query).

Tagging your stories

Hashtag support was the main new feature this iteration. I blogged about tags when they went live earlier this week, so I'll just cover them briefly here.

When you click on a hashtag you're taken to the search results page for the tag. When I click the "#API" link on Planner's own board, this is what I get:

There are 38 cards on the board that contain the word "api", but only three of them have been tagged. Had I searched for "API" instead of "#API", all 38 would have matched the search.

Hashtags are a good way to keep control over a group of related cards, an epic, or a list of requirements for a specific customer.

Improvements to the card page

Teams that make heavy use of Planner's discussions have been reporting that there are too many clicks involved in navigating between the card page, and the conversations that they've been having about the card. They've been finding it difficult to keep track.

It's clear that Planner needs notifications to keep people abreast of what's going on, but in the short term there were some obvious improvements to the card page that could help.

Rather than just listing discussions, we now show you the most recent message in each discussion. I've also redesigned the summary of each discussion so that it shows all the files that have been uploaded to a discussion, directly on the card page.

The next step is to allow replies to be sent directly from the card page.

Feedback pointing out the need for improvements like this is just what I need to make Planner better, so please keep it coming.

Retrospective

At the start of the iteration I met up with Neil (who's responsible for the attractive parts of Planner's design) and we chatted through some of the usability issues that people have been reporting recently. Neil has suggested some nice improvements, and has sent through some exciting changes to the design language.

I had hoped to get more development work completed this iteration than I have, but if I take the time I've spent working with Neil into account, it's no surprise that I've seen a drop in velocity this fortnight.

Get organised with hashtags

2014-07-07T12:00:00+00:00

Keeping track of all the ideas and features that belong in your product can be difficult at the best of times, and writing them all down on separate cards doesn't help us to keep track.

Once you've written a handful of cards on a related topic it can be hard to remember:

Which cards you've written.
Which ones are in progress, have been completed, etc.
How cards are related to (or dependent upon) one another.

Today's project management apps could do a lot more to help. Solving this problem is one of the key goals for Planner.

Planner's solution is built on top of a fast and flexible search engine. You can already search for cards by the words on the card and in the notes, and before long you'll be able to filter your backlog using the same search syntax.

You might be wondering what I mean by "filter". Imagine a big wall of cards on which you need to find the stories that represent your new product's API. Wouldn't it be good if you could highight them all just by typing "api"?

Search is great for this, but it's not without limitations. If one of your cards contained the URL https://www.flickr.com/services/api/ that card would also match the "api" filter.

Popularised on Twitter, hashtags allow you to use any word within a sentence as a tag, simply by prefixing words on your stories "#" character. They fit perfectly with Planner's approach of extracting the information that matters from the text written on your stories (you can already write "Related to card 42" to create a link between two cards).

If you'd tagged your API stories you could filter by "#api" instead, removing the false positives.

Here's an example of hashtags in action:

When you click a #hashtag link it uses Planner's search engine to show you a page of all the cards that match the tag.

So in a sense, hashtags are just a way of making search slightly more precise. If you just need to be able to find a card again, write your card in plain text and search will help you find it. If you need a precise group, add a "#".

UPDATE (3 September 2014): We've now got support for suggesting tags as you type.

UPDATE (7 April 2015): Hashtags worked pretty well, but turned out to have a couple of downsides. We've replaced them with a more flexible tagging interface.

Iteration 44: Public boards and UI improvements

2014-06-25T11:00:00+00:00

There were two areas of focus for this iteration. I've had lots of great feedback from customers recently which have lead to some good improvements to the UI. One customer also needed to be able to share their projects with the public, so (while it wasn't a feature I was expecting to be adding to Planner just yet) I'm delighted that we now support public boards!

Public boards

As this was quite a big new feature, I've already written about it in a separate blog post so there's no point in me repeating everything here.

In a nutshell, public boards allow you to share your cards and your project plan with the public, while keeping your discussions and uploaded documents private.

Coloured stickers and CSV export

Last iteration saw the arrival of four coloured stickers (red, green, blue and black) that you can add to your cards to highlight things of interest. You had to remember what each of the colours meant, but we've now added support for labelling each sticker (e.g. "red is for bugs").

The stickers that are attached to each card have also been added to the CSV export. We're also ordering the cards in the CSV by iteration, and then (within each iteration) by their priority.

Simplifying discussions

It's now easier for you to start a new discussion with your team mates. You no longer need to tick a checkbox for each person you'd like to send your message to, but can select them from a pull down menu instead.

More Markdown support

Markdown is a great way to format plain text for the web, but it often surprises people that it doesn't observe a carriage return part way through a paragraph.

This behaviour was causing a few problems for people, so we've modified the Planner's Markdown parser so that line breaks will be observed.

We've also added support for GitHub-style fenced code blocks. See the Markdown help for details.

If there are any other Markdown extensions that you'd like to see, let us know and we'll see what we can do.

How did the iteration go?

More new features than usual were rolled out this fortnight.

I was recently chatting with a friend (another founder) about how productive I feel when working for myself on Planner, by comparison to how much I've got done in the past, working as a freelancer. I said it was normal for me to deliver 3.5 units of estimated work in a fortnight (don't worry about how small that number is – for historical reasons I tend to use some fairly small numbers), but only 2.5 on Planner.

Let's have a look at my typical velocity from Planner's recent iterations. The last time I shared this graph was back in iteration 38, when my velocity looked like this:

We can see that I can reliably expect to deliver cards whose estimates add up to around 2.5 (the dip between iterations 33 and 35 was the effect of Christmas and the New Year). That's only 70% of what I can produce when I'm freelancing .

Where does that other 30% go? I'm using the same approach to estimating, and we can see from the trend that my estimates are consistent enough to be quite reliable.

I think 30% of my time on Planner is spent thinking. Or rather, 25% of it is spent thinking, and 5% on writing blog posts like this one.

My recent velocity is interesting.

That big dip in the middle was down to a couple of week's holiday, and some time spent working on open source projects. What's interesting is that iteration 44 was 30% more productive than normal.

Why? I think the opening paragraph of this blog post explains it; rather than spending a lot of time working out what the right thing to do was and then doing it, the feedback I'd had from customers made it clear what I should do next.

I didn't question it, I just got on with it. :-)