Single Wiki Pages as a Tool for Effective Requirements Management in Multi-Team Development
How we learnt to effectively track complex requirements in multi-team development using Single Wiki pages to connect the dots
Gousto’s structure is a collaboration of different teams working on one product. Yes, all teams have one goal, and the principle of division of responsibilities is very clear — along domain boundaries and product features. However, the work still remains collaborative, and communication between teams is a very important factor, especially when working on one functionality or product feature for different platforms.
This collaborative work on the same feature can be easily seen when different platforms are run by different teams. A prime example of such cross-team development is our Growth Android squad.
The squad Growth Android was created six months ago and actively joined the process of improving Gousto’s Android application with the remit of all things Growth.
Here’s what we’ve developed over six months:
- 14 epics for Haricots
- 9 epics for Rocket
- 4 epics for Beetroots
- 1 epic for Jalapenos
- Plus several important bug fixes and improvements in the application of Android platform
“Single Wiki Pages” Idea
In the course of this work, a bottleneck was discovered in the storage of documentation and the transfer of knowledge. In part, information about the design of particular functionality, as well as the technical implementation of a feature, is stored only in the heads of those who are involved in the development or in Jira tickets, which are closed and lost somewhere in the tracking system.
This state of affairs increases, at least, the development time. And time is one of the most expensive resources.
At Growth Android, we want to improve team communication by implementing Single Wiki Pages as a Tool for Effective Requirements Management in Multi-Team Development.
Product requirements are now stored in different tools: Wiki, Miro, Figma, Google docs. A change in one place requires updating in other places to keep the development up to date, especially when different teams are working on the functionality. This is a fairly common practice for Gousto.
- The designs are stored in Figma.
- Miro boards reflect the workflows and user journeys of our product’s functionality.
- Google docs help to describe causal relationships, technical aspects of development, as well as the reasons for making changes.
All these tools in a compartment create a general impression of each individual feature and become an integral part of the texted requirements we store in Wiki. But at the same time, they can be difficult to understand: you need to open several tabs, familiarize yourself with everything, and then build a single picture in your head. Undocumented information can become an unpleasant surprise.
Keeping up to date and in sync between products can become a monkey job that takes a lot of time and effort.
Now we offer to everyone and actively implement in our team the usage of Wiki pages for storage and structuring of all the possible information about requirements and development nuances: text, tables, graphs, diagrams, designs, comments — everything can be located in a single repository.
Various plugins and add-ons embed related content (for example, Figma-designs and Miro-boards) into Wiki pages, aggregating everything into a single place, even if different tools were used to create content (so as not to change habits or change them gradually).
The role of Jira is not diminished in any way — it remains an important and the only tool for managing task statuses and collecting metrics. In general, from the very beginning, its purpose was to:
- be a workflow management tool for software development teams who want to organize and track their work,
- track the progress,
- control metrics,
but not to be the requirements storage system.
Wiki and Jira are integrated perfectly to have an inextricable link between the description of the requirements and the status of their implementation.
1. Consistency and synchronization of data is a step towards reducing discussion and knowledge transfer times, and therefore increasing time that can be spent for development.
2. It will be faster to access the info if you don’t need to switch between tabs or tools, and you will see all the up-to-date info on one page.
3. The simple truth of “it is always better to use specialized equipment than multi-tools” works here more than ever. Until a certain point, when the product is compact enough, Jira is perfect for requirements management, but when there are a lot of teams, and the product grows, it is better to choose specialized software for working with functions descriptions.