Maybe this sounds familiar to you: To maximize advertising revenues, it is necessary to constantly optimize ad placements, ad layouts and ad formats used on your site. This leads to a flood of really small user stories, which are often written like this:
Please put 3 AFS ads after the first search result, 3 ads in the middle and 5 at the end
Let’s try to ad another link block above and below the search results
Sounds pretty simple, huh? It is. But, you can waste a lot of time if you blindly approach such stories (like I did ;-).
How a Tiny Layout Change Can Take a Big Chunk Of Your Working Day
First, I want to show you how I wasted hours of my time on the two user stories I mentioned above. Maybe you already spotted the issue with the first story? Yes, it only describes the most common case of a page of search results without talking about the border cases – like what happens if only one or two results show up.
As I considered it a trivial change I jumped at it right away, implemented the logic as I found fit, committed and deployed my clean and nice code to the test environment and moved on to my next user story. But it backfired a couple of minutes later: My solution of the border cases did not suite the product owner. According to our common process, they marked the story as rejected in Pivotal Tracker sending me an automated email telling me their concerns. Easy enough, I thought. But, as I had already moved on to some other task, it took me a couple of minutes to wrap up, find the places I had previously changed and apply the changes again. As they were simple enough, I immediately committed and deployed on the test system and moved on to the next task. As you can imagine, we played this game a couple of times throughout the afternoon. All in all, I wasted more than 2 hours on such a trivial change – mainly because we were relying on the tool instead of talking to each other.
That incident taught me a lesson. I knew there had to be a much better way to deal with such trivial changes – I wasn’t ready to accept that such a change took more than 30 minutes. So what did I change? Finding the waste in the story implementation was easy: Undiscussed assumptions and changing requirements based on first sight of the implemented product (“oh no, now that I see it: We can’t do it like this…”) lead to a lot of task switching and multiplied commitment and deployment efforts. All this was easy to see, but interesting to experience as it nevertheless killed my productivity for a day.
Improvements Multiplying Productivity
For doing the next trivial change, I followed this approach:
- Read the story carefully (ok, nothing new here 😉 )
- Analyze the current implementation and the areas to change. Last time I just jumped to implementing the changes right away. That made me miss a few border cases – bad mistake (not that it was a surprise, though…)
- Discuss the story details with the product owner. Doing the analysis revealed some unclear points and missing specifications. Instead of implementing my first guess I spoke directly with the product owner to clarify the points.
- Implement changes on my local box. No, don’t hit that commit button just yet!
- Show changes to product owner. By showing the stuff I did directly on my box, I avoided all the overhead of committing and deploying to the test system. The product owner was able to do a visual sign off before he started detailed acceptance testing on the test system.
- Commit and deploy to the test system. Now its worth putting it on the test system for acceptance testing. All requirements should be covered by now and the product owner should know what to expect.
By following those really trivial steps and involving the product owner much earlier in the process, I was able to finish a comparable feature within the given time frame of 30 minutes easily. Of course, I was lucky to have the product owner in the neighboring office. I’ll make sure to use the above checklist every time I attack such a trivial change. What about you? Have you had similar experiences? Don’t hesitate to let us know in the comments or send a tweet to @webops.