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.