Experimenting with our Agile Story Wall

After three and a half years of working by myself at home, it feels truly great to be working in a co-located cross-functional team again. My squad consists of four developers and myself, and I had forgotten how much I love being a paradev. I wear many hats every day in my job, which I love, and one of these hats is managing our iterations of work: our fortnightly sprints.

We follow lightweight agile software development practices but in the spirit of this our squad is empowered to experiment and adjust our techniques to delivery good quality software quickly.

We aim to work on items of work in small chunks and have these features being used by our customers as quickly as possible by releasing software at least daily to production.

Typically we’ve been using a simple physical agile story wall which is good when you’re working on small and fairly independent chunks of functionality, but we’ve found not all work fits into this style of working.

We recently had an initiative that involved lots of small tasks, but there were a lot inter-dependencies between the tasks – as we need to do data creation, migration, back end services migration and new front end development. Our standard agile story wall which looked like this was very bad at showing us what was dependent on what:

Agile Story Wall

As a team we decided to experiment with using our agile story wall to map the dependencies we have between work and also to show when we’re able to release the various pieces of functionality. The two week sprints were less relevant as we release as soon as we can. We still have some pieces of independent work (eg. bug fixes and tech debt) which we kept tracking using the standard Kanban style columns under our main board:

Dependency Wall v1.jpg

This gave us instant benefits: the dependencies were not only very clear but elastic. We used a whiteboard marker to draw lines between tasks which meant as we discovered new or unnecessary dependencies we could quickly remove or re-arrange these lines. But we also quickly realized that in mapping our dependencies out this way we lost one key attribute of our information radiator: we couldn’t see the status of our pieces of work at quick glance which the standard status based wall gave us. Since we’re using a physical wall we can quickly adapt so we added some sticky dots to indicate status of individual cards: blue for in progress, a smaller yellow dot is in-review, and green for done since blue + yellow = green (I’m happy to take the credit for that). We also added red for blocked when we discovered we had our first blocked piece of work, and a legend in case the colours weren’t immediately obvious:

Dependency Wall v2Once our 4 week initiative was over we found the dependency wall was so useful we’ve decided to continue using it for the main focus of each sprint, and continue using the standard status based columns for less critical things. We’ll continue to refine and iterate.

Lessons Learned:

  1. Having an old-fashioned physical agile story wall is powerful is a lot of ways, and one of the most powerful things about it is how easy it is to modify and adapt your wall to whatever suits you best at the time: we couldn’t have achieved what we did if we were using a digital board like JIRA or Trello.
  2. Standard agile story walls are good for showing status of work, but are very weak at showing interdepencies between stories and tasks – the major software solutions suffer from this.
  3. A software team being agile isn’t about just doing sprint planning, standups, a story wall and retrospectives from a textbook. It’s about delivering software rapidly in the best possible way for your team and your context – and continually experimenting and adjusting your ways of working is crucial to this.

Improving your agile flow

I’ve noticed two counterforces to flow on an agile team: rework and human multitasking. It’s common knowledge that rework is wasted effort, and human multitasking should be avoided as it reduces velocity through inefficient human context-switching, and can increase further errors through insufficient attention to tasks at hand.

But luckily there’s two simple things I have found that increase flow and reduce rework and multitasking.

User Story Kickoffs

It is essential that just before development work begins on every user story that a kickoff discussion occurs. This is a casual discussion around a computer between the business analyst, tester and any programmer who is working on the user story.

In my experience this takes about ten minutes standing around someone’s desk where we read aloud the acceptance criteria from Trello and discuss any ambiguities. We ensure that everything that is needed for the story to be considered complete and ready for testing is listed and that it’s not too large nor will take too long to complete.

We have special children’s sticker on our story wall which we put onto a story card that has been properly kicked off.

User story test handovers/shoulder checks

shoulder checks are essential
shoulder checks are essential

It’s also essential that as soon as development is complete that the tester and any programmers who worked on the story gather for a quick ‘shoulder check’ or test handover. This often involves letting the tester ‘play’ with the functionality on the programmer’s machine, and running through the now completed Trello acceptance criteria. Any misunderstandings or bugs can be discussed and resolved before the card becomes ready for testing.

We have special children’s sticker on our story wall which are then added to a story card that has been handed over/shoulder checked. The aim is to have two stickers on every story card in ready for test.

How these two simple activities improve flow

By conducting a user story kickoff every time it means that everyone working on developing the functionality has a common understanding of what is required and therefore there is a lot less chance of developing something that is not needed or misunderstood which requires subsequent rework.

By conducting a story test handover/shoulder check every time it means that obvious bugs and misunderstandings are raised immediately, so they can be fixed quickly before the programmer(s) moves onto working on new user stories. If discovered later these cause the programmer to multitask and context-switch between working on bug fixes and new functionality.

But I’m too busy testing stories…

I used to think that, but now I’ve got a personal rule that regardless of what I am doing or working on, I will drop it to attend a story kickoff or test handover. The benefits of me conducting these activities outweigh any work that I need to resume after these activities are complete.

Bonus Time… is it essential your bugs are fixed?

The great thing about agile software development is that developing something and testing something are a lot closer together… but they’re still apart. It’s more efficient to get someone to fix a bug whilst it’s fresh in their memory, but it’s even more efficient to not fix it at all.

What I am proposing is instead of raising medium/minor bugs against a story to be tested, raise them as bugs in the backlog to be prioritized. Depending on your organization, your business may not consider these important enough to fix, and therefore this saves you both rework and context-switching so you can continue on developing new functionality.