1 minute read

This is a vacation photo of me (in the middle). You might see us three and Mount Fuji in the background and you might think “nice picture”.

But when I look at this photo what I remember is that we were in Hakone and that it was almost autumn. I remember that we made a gamble on which day we would take this hike because of the weather. I remember that we had to get up really early at 5am to start this long hike and that the reward was so worth it. When we got to the top we were surprised that it was so quiet there and that there were only two other people with us. The fact that they were a bit old impressed us even more because the climb up was quite steep.

Of course, if you look at this picture that would be literally impossible for you to know because you weren’t there. I remember it because I was there.

For better or worse, this is exactly how documents produced in agile teams work as well. They make sense if you were there, and often they make less sense if you weren’t.

These documents created together make a lot of sense for the people that were there at the time of creation. But you will most likely share it with someone that was not there, and then it will make a lot less sense to him. There’s not really a lot that you can do other than getting together and trying to retell the story the same way that I used the photo above to tell you my story.

This blog post is a remix and might contain some literal words of a chapter of User Story mapping by Jeff Patton. I want to share this because I deeply and fundamentally agree with the point that he’s making and I want to link it to the programming paper “Programming As Theory Building (1985)” by Naur at some point.