In our ever faster digital world, time to market is an increasingly important factor in any IT project. A shorter time to market is crucial to stay ahead of the competition. However, this is not possible without an agile and qualitative IT environment. This is where Quality Assurance comes into play.
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.
One thing we've learned from the first phase of the iHRM program is that a complete waterfall approach with one delivery moment, followed by an extended user acceptance period is not the silver bullet. For the second phase of the program, the scope is wider and the number of project teams is higher. In this blog post, I'll share some insights on how to effectively manage scope while going for an iterative and incremental development plan.
You've probably already heard of Scrum, the popular agile software development framework. While the basics aren't difficult, a lot of people seem to fail implementing it. In this post I'll sum up 10 things you should do if you want your Scrum project to fail miserably.