Using Kanban, User Story Mapping, and Impact Mapping to Visualize and Clarify Requirements

This article is reprinted from the blog of Taiwanese teacher Li Zhi‑hua.

The author has been contemplating this piece for over three weeks, traveling across continents to give talks on applying agile development to lean startup, and decided to translate the material into traditional Chinese to share publicly despite limited local demand.

Tools for Seeing

Kanban Method : Enables us to visualize the workflow and continuously improve and manage the process based on the theory of semi‑finished products.

User Story Mapping : Helps us layer user stories and organize the full picture of requirements, showing where to start to solve problems and implement projects.

Impact Mapping : Connects business goals with product features, allowing customers, analysts, and development teams to see where each feature impacts the business.

This series of articles discusses these three methods as tools to help us see the essence of requirements. The focus is on leveraging visualization to address the challenges of constantly changing project requirements, using a diagram to illustrate the timing for applying each tool.

First Row: Thinking Approach

From “extreme abstraction” to “abstraction,” then to “clarity,” and finally to program code, achieving “extreme clarity” in problem solving. The author’s method involves stepping back to broaden perspective, reducing information noise, and seeing the whole picture before diving into solutions, avoiding the typical “engineer’s tunnel vision.”

Hovering Between Abstraction and Clarity – Continuous Optimization

When faced with constantly changing requirements, the best solution is to pre‑optimize using low‑cost methods like paper prototypes to validate assumptions before coding. The author prefers to linger between abstraction and clarity, preparing PPTs or specifications rather than rushing into code, to avoid costly rework.

Reverse‑Engineering (Start at the End)

Imagine the feature is already completed, then check whether the problem is truly solved. This approach aligns well with Impact Mapping, which the author plans to elaborate on in a future article.

Dealing with Tough Problems

The author often emails himself, using the time delay as a form of self‑feedback and “decide as late as possible” strategy, allowing thoughts to mature before making decisions.

From Clear to Extremely Clear

Step One : Verify that the document specifications are correct. The author prepares sufficient specifications, test cases, or unit tests before starting the main project—an approach similar to TDD but aimed at triggering a second‑thought process. This preparation aims to make coding more enjoyable and the code simpler to debug.

Conclusion

The first row discusses the author’s abstract problem‑solving method, based on Mary Shaw’s abstraction technique. The next article will describe the use of Impact Mapping. The author hopes this segmented description provides a useful reference.

Please follow the WeChat public account devopshub for more information on DevOps and integrated R&D operations.