Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Agile: Story Wall – A couple of learnings

  • submit to reddit

I wrote earlier in the week about the benefits of having a physical story wall on a distributed team and in the process of getting one in place on the project we learnt a few things that I'd previously taken for granted.

All the work in one place

We initially started off by having stories on one part of the wall, bugs on another part and any technical tasks stored in Mingle somewhere.

The problem with this approach was that it wasn't easy to glance at the wall from wherever you were sitting and be able to quickly gauge the state of the project at any given time.

We needed to look at one side of the wall to check what stories were being worked on and then check the other side of the wall to see who was working on bugs.

A couple of times we'd forget that the bugs were being tracked on the other side of the wall and two pairs would look at the same bug before realising that it had already been picked up.

We're now in a place where we have stories, bugs to be fixed in this iteration and technical tasks all in the same lane on the wall.

Doing this means that everyone can quickly gain visibility into what can be worked on and then they can easily work out what the next thing to pick up is.


I hadn't realised the value of having upcoming stories visible on the wall in the 'ready for dev' column until I saw it not being done.

The proactivity of the team seemed much less than in previous teams I'd worked on because people were unaware what they could pick up once they'd finished working on a story.

As a result of this there tended to be a lot of time where developers were waiting around looking for something to do.

A bottleneck had been created where they would need to wait for an analyst to tell them what could be picked up.

Now a pair can what the next highest priority thing for them and pick it up or at least work out roughly what they need to do before running through it with an analyst.

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Emma Watson replied on Fri, 2012/03/30 - 5:12am

Why don't you use an agile story tracker like Pivotal . It's free and it does exactly what you've mentioned in this post.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.