Recently, I participated in an agile business requirements training given by my colleague Thomas De Vries and Patrick Steyaert. One very interesting technique that they highlighted is story mapping. In this post, I will explain how to apply this technique and highlight the advantages compared to traditional techniques for eliciting requirements.
Business and IT speak a different language. This is a challenge for many organizations as it hinders communication about requirements in IT projects. An often suggested way to deal with this problem is to use the simple and fixed format of user stories to express requirements (as a..., I can... so that ...) and I fully agree on this. However, as a business analyst, I notice a lot of confusion among business people when it comes to the definition of a user story. I often hear that user stories are too technical for them. In this blog post I provide 4 tips to write user stories that express business requirements making sense from a business point of view.
We are creating customer journeys on the fly these days. It is the revelation in process modeling and customer understanding. By combining the outside-in process of the customer with his emotions we are able to steer our organization towards the customer-centric culture, and foster loyal customers. But in our quest for the outside-in enterprise, one must not forget why we are mapping a journey in particular. Forrester states there are 6 possible goals for every customer journey map.