Turn your specifications into living, digital documentation
Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.
Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.
Advertisement
The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.
The basic concept can be illustrated like this:
Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both. I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.
Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.
You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.
Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.
I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:
Start your visual facilitation journey with letters
The icon library: My favorite analogue tool