Visible workspace example




Visual workspaces are great for communicating a lot information fast. While Story walls are popular for showing the state of an iteration, don’t let that limit what you show. Create and visualize anything important to you and your team.

Here what we are radiating from the current project I am working on.

Release Schedule



This wall shows all the days of the month and what we plan on releasing when. It’s handy for scheduling releases, showing important dates when doing daily standups, and just giving everyone a quick update on any important release dates. Great for coordinating and getting everyone on the same page.

Inception Deck

The inception deck gives people an overview of the project at a glance. We don’t always start with full teams, and it’s handy to be able to walk someone over to the wall, and give them an overview of the project at a glance.

Delivering Value

This wall may seem a bit defensive, but if you want to show what you and your team have done, create a card for every major milestone or release and make it visible.



Here we are proudly showing that we’ve done a major release every month, while working closely with the support team to crush about x15 bugs per month. Ya!

Track stories not tasks


When tracking the state of an iteration/sprint I generally favor tracking stories (not tasks).

The good of the story

  • accountability (someone takes responsibility for it’s delivery)
  • favors generalism over specialization
  • can see the sprint at a glance
  • less to track

I only mention this because I once saw a team get so bogged down in tracking tasks, that they abandoned the visible workspace (because it there too many tasks to track) and a lot of it was just noise (i.e. a task for development, a task for QA, a task for code review etc).

Once we removed the tasks, and focused more on the story, the clouds parted a lot of stuff cleared up.

I know a lot of advice out there recommends tracking, estimating, and investing time in tasks (and I am not against doing that to help understand what needs to be done).

But generally I prefer to start with the story. See if you can deliver without the overhead of the task, and add it only if you can’t.

%d bloggers like this: