Last sprint we had a half-point story, which in our world should be about a day of coding and testing, to do some “simple” text content changes on a wizard in our web application. It’s been a year since we had updated this part of the application (it mainly gets used from late January to mid-March). While we were planning our sprint, we didn’t think too hard about how the wizard worked, and how many permutations it involves over the span of time that our end users are using it.
First Try
Our product owner asked me for screenshots of some of the pages, and had his mockups of the changes ready to go in a Word document before the start of the sprint. We wrote test cases on our wiki accordingly.
Second Try
One of the programmers started working on the story and realized the code had a lot of different cases that depended on dates and statuses of various items. He printed out some of the code and went over it with the product owner to get the appropriate text for each of the cases. The original mockups we had were no longer useful.
Third Try
When I started to test the updates, I kept getting confused. There were subtle differences between the different permutations, and several different target and deadline dates involved. I showed the new pages to the product owner, and he got confused himself, and kept making more changes to the text and even to the logic behind what text is displayed when. The programmer patiently updated the code over and over again, but I could tell he was losing the will to live.
I finally cut and pasted paper mockups myself for each possible condition with the text I thought was correct, went over it with the product owner who made his changes, and the programmer worked from the paper mockups. This did the trick, but by now, the half-point story had taken eight days instead of one.
What We Learned
In hindsight, we think that we should have started by researching all the different possible permutations before we started on the story, giving the PO a screen shot for each one, and having him give us paper mockups for each condition. This would certainly helped me test, as I tend to be more visual, rather than being able to mentally interpret what the code should produce.
When we showed this to more of the stakeholders, they asked if anyone besides the PO and us had reviewed the new text. We had been depending on the PO to do this, so we didn’t show it to anyone else until the coding was finished. Next time, we’ll ask the PO if other stakeholders have reviewed his changes.
Sometimes stuff just happens, but if we always remember to get a mockup for each change needed and each case, it might save us time in the future.
News
There’s a lot going on – I have new articles published and lots of tutorials, workshops and other events coming up. Please check out my News page for details.
