When comparing the frequency and granularity of test planning and execution in products developed under Waterfall and Agile methods, we observed that in Agile: we have more tests, in the story level and we have a progressive increment of test coverage all over the product and higher frequency running those tests.
Continue reading “Why Agile test planning makes software quality superior than in Waterfall”
(Munich, Germany) Some time ago, I wrote about the value taken with the execution of Proof of Concepts (POCs), and how important they are to give us confidence for future decisions. I would like to go back to this matter because I believe POCs are an important starting points to scale product complexity. At the same time, there is a task we can handle in order to improve product quality: User acceptance tests (UAT). So if we do it well we can increase product complexity and plan UAT in an incremental process of add/ develop new features and also other non-functional requirements.
Continue reading “Planning User Acceptance Tests in parallel with the product complexity increase”
It’s always annoying when something comes up out of the plan and the team must fix it or manage it inside the sprint. Unfortunately, we must deal with unpredictability. Nevertheless, is always good to analyze why we had to deal with those annoyances.
What can be considered an annoyance? In my opinion, we can consider as critical bugs or unplanned change requests, we receive during the sprint or release and we must integrate or fix it within the sprint. In this post, we will approach, in a generic way some reasons for this and if it happens, who will report it into the backlog and which other measures should we consider to keep the sprint in a normal speed.
Continue reading “Annoyances: How to deal with critical issues, not planned, entering in the middle of the sprint or release”
(Berlin, Memorial to the Murdered Jews of Europe) – Some weeks ago, when I visited the Memorial, the feeling of loneliness and lack of direction invaded me. I think this is the main achievement of the architect (Peter Eisenman)… bring this feeling to the visitors. And from the position in the picture I asked to myself “What have we learned from this horror?”. Inspired by a continuous learning for a continuous improvement, I would like to make the question applied to bugs and change requirements (CR), but particularly in this post: what can we learn from bugs? We should take them all as improvement opportunities.