I struggled with some of our new features when looking from an end-to-end workflow view. I was convinced we didn't take into account the unexpressed users’ requirements enough to not just get a user’s job done, but to also get it done quickly.
To find out whether we were right, we prepared a plan.
When the customers were
invited to our offices the very next time - testing our new features - for one time, we didn’t prepare
anymore the typical test case checklist. This time, instead, we
prepared just one simple and realistic end-to-end scenario that combined the
features of the old version with the new features. Don't ge me wrong, I love checklists, they are a perfect tool to guarantee we don't forget anything but for this particular case, we needed to jump out of the standard operation procedure. Instead of ticking off an atomic feature list, this time we took into accocunt its place in a real-life scenario.
We were really surprised about the reaction of the domain experts. This approach revealed the "pilikia". All experts agreed this process requires improvement.
As a result, initially low rated internal tickets became a higher attention and unfortunately had to be implemented as part of late change requests in the middle of the stabilization phase. My bad. The timing was a disaster. It was so bad, it was almost good. These late changes payed off. The implemented improvement was significant and worth it. The customer appreciated the correction and our ability to respond quickly to their concerns.
They probably did because we "shocked" them with what they were getting next. Okay, it worked this time, but I guess we shouldn't do this too often.
