Knowledge Acquisition (KA) in Agile Development
The phrase “knowledge acquisition” was originally coined in expert systems to describe the processes and tasks associated with transferring the knowledge of domain experts to software systems. Lately, this phrase is also used in the agile development process. In PubSub+ Cloud, Knowledge Acquisition(KA) is part of our agile development process pipelines. The outcome of a KA is that the high-level feature requirements are understood sufficiently such that the feature can be analyzed and possible solutions proposed.
In PubSub+ Cloud, the part of the pipelines related to KAs looks like this.
The activity that moves a feature from feature backlog to sprint backlog involves breaking the feature (epic) into stories. The prerequisite for such activity is that the scrum team (including product owner) has enough feature relevant technical knowledge and know-how. If the scrum team does not possess enough knowledge, a KA activity will be kickstarted. For incremental features, this activity is usually not needed since the scrum team is likely familiar with the subject matter. This activity is mostly warranted for new features or features which dramatically change functionality. For example, adding a few user interface(UI) pages for the new monitoring feature may very likely require a KA, adding a new field in an existing UI page probably won’t need one.
Fundamentally, in our team, a successful KA helps the scrum team to gain enough technical knowledge to understand the feature and be able to break it up into stories with a good level of precision, i.e. the size of the stories is addressable within the sprint. In PubSub+ Cloud, KAs are usually undertaken by architects. They could also be taken on by members of the scrum team though. The major activities involved in KA are technical study, design discussion (with the scrum team), and prototyping if necessary. KA is not a product development activity, it is not part of sprint schedule. For example, the scrum team could make use of the code developed in prototyping, they could also choose not to.
There is a significant difference between KA and architecture design in the traditional waterfall-based development process. The goal of the architecture design is to achieve the complete and verified system-level design, and produce a “bible” that the development team will follow closely. The goal of KA is to gather enough knowledge so the scrum team can create stories. It is based on the philosophy of iterating and incrementing that is fundamental in the agile process. Probably no one can say this better than Alistair Cockburn:
In any team design activity, we are working with a problem we don’t yet understand, creating a solution we don’t yet understand, and expressing our ideas in languages and technologies we generally don’t yet understand — and all of them keep changing out from under us.
As we work, we learn more about the problem, about the technologies, about the proposed solution…
