Knowledge Sharing Session Agile User Stories and Documentation
A knowledge session organised by the IIBA NL Chapter with ABN AMRO and presented by Kees van Wingerden and Maarten Leune
Article by Dunja Hartman
A mere two hours later, all these people left with the happy feeling of having their expectations met. The talks delivered had been brimming with flow, tools, examples and interaction and were overall entirely too short to touch more than the tip of the iceberg called Agile. But they had been useful to both new and experienced practitioners of Agile Business Analysis. Kees van Wingerden and Maarten Leune had done a wonderful job in informing and engaging the audience.
Now, here I am, with fourteen pages A5 of handwritten notes, faced with the admittedly daunting task of trying to convey parts of the evening. How much atmosphere and how much information should I include? The PowerPoint slides, albeit in Dutch, would be available by request. But many of the things covered are not explicitly stated in the slides. So many insights from the attendees. So much implicit knowledge. Would people benefit from me writing down the talks from memory?
What information should I include or focus on? Should I focus on models where you’d have all process or architectural information captured in one image with a few pages of explanations. I would need to include the personas who represent the end user – the person for who we build the application. By knowing them, we can focus on use case examples and ask ourselves how the user (persona) would react to certain changes. No, maybe I should do something about how the user story format of “as a… I want.. so that…” helps keep in check who your stakeholder is, what the business need you’re covering is and what the requirements are (the last via acceptance criteria). At the same time the stories can be used for test case writing and fulfilling the role of functional documentation. If they’re small enough, that is. So then I’d continue with how you can slice these user stories down to very small pieces of business value that can be tested (maybe even automated so that you’ll always have automated checks for the project). Or maybe how you should have less up front project documentation, but keep the product documentation up to date. Your documentation should be functional and reflecting reality. Living documentation, if you will.
There is explicit knowledge (in writing) and implicit knowledge (in our heads). The explicit documentation is for the high over points, maybe with high risk details mentioned to prevent everything from going down in flames the second a big red button without label is pushed (you see, in the documentation it explains the button is the self-destruct mechanism). The implicit knowledge is fast, flexible and Agile. And you access it by talking. Not writing. Not documenting. Not by sending twenty mails to and fro. Grab a coffee (or a Coke Zero), grab a person and TALK. Talk with your customer, your stakeholder, your team member, your PO, that random attendee at a knowledge session in May. Have a conversation and learn.
So that’s what I’ll do. Record the bare basics here, point you to the slides (you can request them via firstname.lastname@example.org) and invite you, my dear reader, to attend the next knowledge sharing session (check the IIBA NL Chapter site for details). Come attend and mingle. Ask away. The IIBA NL Chapter and its members are looking forward to exchanging knowledge with you.