Salary Thieves

Yesterday I attended a Waterloo Agile Lean session on Story Mapping presented by Mark Levison. I had heard of Story Mapping but hadn't worked through it before. I liked the hands-on exercises approach Mark took to help us understand the process and benefits of that technique. This blog post is not about Story Mapping.

I love learning and take any opportunity I can to hear different speakers present on topics that I think may be of value. Sometimes I even attend the same talks and workshops when they are done by different speakers so that I can understand differences of style in presentation, stories, and tips/techniques for getting the ideas across to the audience/participants. Once I even attended the same topic by the same speaker 2 days in a row, and I learned something new/different the second time around! (It was a Cem Kaner talk when he was in our area a few years ago.)

Yes, I gained an appreciation of Story Mapping yesterday. More importantly, I learned a new anecdote from the speaker - one that got me thinking. At one point, Mark answered a question about managing a large backlog on a Scrum/Kanban-style (information radiator) board. The problem with really large backlogs of stuff to do (likely anything with more than 100 items in it), is that the items near the bottom become meaningless over time. You will probably never get to them because something more important always comes up.

Radiating Testing Information - Part 1

This topic is one that I have been asked about many times over the years and I am long overdue for a detailed discussion of it. Back in 2006 I presented an Experience Report at the STiFS workshop in New York titled "Low-Tech Testing Dashboard Revisited." The content of that presentation will be in Part 2. To quote "The Do-Re-Mi Song" from the movie The Sound of Music, "Let's start at the very beginning, a very good place to start."

I attended the StarEast conference in 1999 and there was a talk by James Bach titled "A Low Tech Testing Dashboard." This presentation clicked with me as I was managing several test teams at the time and it addressed a problem that I felt was important. I have used this communication tool many times ever since. If you are not familiar with it, I suggest you read through the PDF slides on the Satisfice web site before you continue. Go ahead. I'll wait.

In this review I will cover some of the who, what, where, when, how and why of the Low Tech Testing Dashboard (LTTD) through examples from past projects I have worked on. I expect your context is different, so my hope is that these examples may help you think about how you might apply this communication tool on your project.